GNOME Bugzilla – Bug 121810
auto-rotate JPEGs when EXIF says so
Last modified: 2006-05-20 22:55:03 UTC
If the EXIF data in a JPEG says "Orientation: rotate 90", how about rotating the image when loading it, so that I don't have to do it by hand? Several of the digital cameras I've used can tell the orientation in which they were held when the picture was taken, and write this info to the EXIF data. (I don't understand why they don't just write the JPEG data rotated in the first place, but that's what they do.)
Created attachment 19819 [details] example of an EXIF-rotated image (scaled down and saved with gimp)
Actually you don't want to use GIMP to rotate such an image. You want to use jpegtran, a tool that can rotate JPEG images w/o having to decompress and compress the data again. There are scripts available that you can run on a directory full of images and have all rotated according to their EXIF tags.
I think that what jwz would like to have is an automatic adjustment of the orientation of the image when the JPEG plug-in opens it before viewing or editing it. So this request is not really about converting the image, but about loading it correctly (according to the EXIF information).
I don't think the JPEG plug-in has a chance to do the right thing w/o user interaction. The EXIF data only describes how the picture was taken, it doesn't tell the plug-in if the image data needs to be rotated or if this happened already.
I think autorotation would be useful. If something rotates the image, it should either modify the EXIF info accordingly, or get rid of it. We should trust the info. In the same vein, GIMP should throw out the EXIF Orientation tag upon loading and rotation. Maybe at some future point we can track image mods and update accordingly.
I wouldn't want GIMP to change the EXIF info. It is information on how the image was taken and modifying it would be just plain wrong. Would you want GIMP to change the exposure time when you modify the image's brightness? Maybe I am biased here since GIMP would start to load all my portrait images wrong and I would have to patch my JPEG plug-in to have it behave correctly.
> I wouldn't want GIMP to change the EXIF info. It is information on how > the image was taken and modifying it would be just plain wrong. Would > you want GIMP to change the exposure time when you modify the image's > brightness? No, not brightness, but I think changing the rotation field would be reasonable. And what about thumbnails? I think that if you're writing a file that has EXIF data in it, you *have* to update the EXIF thumbnail to match the current image (bug 118262 and 118384.) So there's already at least one case where you must modify EXIF when saving. There might as well be two...
Other parts of the EXIF data that may have to be modified include the user comment tag, the software tag, the YCbCr subsampling tag (because the file may be saved with different parameters by the JPEG plug-in) and maybe others.
*** Bug 142133 has been marked as a duplicate of this bug. ***
this is a dupe of 118202.
er, 120839.
nevermind, that's for gthumb. sorry for the idiotic spam.
Since this bug report has been pinged, let me add a note: the EXIF specifications clearly explain which fields should be modified when an image is edited and which should be left alone: there are about a dozen that should be modified, including the thumbnail, modification date and time (but not creation date and time), rotation state, dimensions, etc. Unfortunately, libexif 0.6.9 has introduced a basic incompatibility at the API level (a function that used to take two arguments now takes four arguments) that makes it considerably more difficult to handle this in the jpeg plug-in than it otherwise would have been.
Just a note that I have added to cvs a summary of how the exif specs say that each field should be handled, as plug-ins/jpeg/exif-handling.txt.
Okay, the version of the jpeg plug-in in HEAD now checks the orientation specified by the exif, and if it is not "top-left", asks the user whether to rotate the image accordingly. (If the file is opened non-interactively, there is no rotation.) This may or may be an adequate solution, but I will leave this bug report open because there is widespread disagreement about what kind of ui would be best.
IMO this should be closed as FIXED.
IMO this bug should only be closed once the rotation is unconditional and happens non-interactive mode as well as interactive mode. If EXIF says that the image data has to be rotated, then there is no reason to ask the user if that should be done or not.
Closing as FIXED. This will of course not prevent us from arguing about whether the plugin is doing the right thing, or from changing what it does.