GNOME Bugzilla – Bug 165645
Rotate image when exporting
Last modified: 2006-09-17 07:32:41 UTC
When exporting to CD, the images that have a diferent orientation needs to be rotate so nautilus-cd-burn save the images in the correct orientation.
I'm not sure this is a bug with F-Spot but with other image programs not respecting the orientation EXIF field. I'm not an expert here, so I may be wrong. If you burn photos to a CD from F-Spot and then reimport them, I believe they would be oriented correctly.
We probably need to offer the ability to rotate the actual image data when exporting so that we interoperate with other software/hardware better.
Hmm, if you have an Orientation EXIF field set, does it work in Mozilla, etc.? Yeah, option sounds good.
Maybe lossless formats should always be "physically" rotated. JPEG, should be done by metadata. Is there nothing internal to the JPEG format that lets you rotate the rendered image without re-encoding? As far as I can tell, /NOTHING/ reads the orientation EXIF field. Not Mozilla, nor EOG, nor Nautilus, nor GIMP.
GQview does read the orientation field for example (not by default but the option is available). It is true that most viewers ignore this EXIF field though. The best solution I found so far to avoid this problem is to rotate all new JPEG images with exiftran (exiftran -ai *.jpg). It does lossless rotations like jpegtran and update the EXIF Orientation field (so all images end up being top left...).
*** Bug 325312 has been marked as a duplicate of this bug. ***
Renaming this bug to make it more clear that this issue affects all export operations (and anybody who accesses the photo files via another program, not f-spot).
Given how few apps actually respect the EXIF tag*, and given that jpegs can be rotated losslessly, don't see why this bug shouldn't be 'rotate jpegs on disk and then just export normally.' It really, really reduces f-spot's utility to me if I have to re-rotate every picture when I export to gallery. *even f-spot's support actually is broken, AFAICT, but that's a different bug :)
[I also wouldn't call this an enhancement, since it means that for many export functions, like gallery, f-spot is basically badly broken.]
First, I thought gallery supported autorotation these days? Second, I'm not going to rotate on disk for the normal case Doing so changes the file (which will break the duplicate checking that is about to go in), requires changes to the exif data (many programs fail to update the right fields here), and simply won't work with raw files. More and more cameras write out the orientation so those other programs that aren't handling the orientation will continue to fail do the right thing with more and more images. I don't see how it is better if f-spot hides their problems by altering the image.
(In reply to comment #10) > First, I thought gallery supported autorotation these days? Doesn't in my 2.1 install, at least. > Second, I'm not going to rotate on disk for the normal case Doing so changes > the file (which will break the duplicate checking that is about to go in), Doesn't changing the EXIF data also change the file on disk? > requires changes to the exif data (many programs fail to update the right > fields here), and simply won't work with raw files. More and more cameras > write out the orientation so those other programs that aren't handling the > orientation will continue to fail do the right thing with more and more images. > I don't see how it is better if f-spot hides their problems by altering the > image. When 'working' programs are in the minority (which AFAICT they currently are) are they really working? I mean, I'll file bugs for gallery and xscreensaver and gnome-screensaver (I assume nautilus too, but haven't tested that) to support this properly, but in the meantime, I will find it really hard to use f-spot- I'm absolutely not rotating every picture once in f-spot, once for the benefit of my screensavers, and then a third time in my web gallery. I'll rotate once with gimp or eog and export to gallery the old-fashioned way, and I assume everyone else who is using anything outside of f-spot will do the same.
The gallery remote upload api has an explict boolean argument called autorotate that I know worked with gallery1, if the argument has changed in the gallery2 stuff or is being ignored we need to debug that. As for gnome-screensaver I know for a fact the f-spot screensaver works fine ;) The thing you seem to be missing is that a lot of cameras already write this info in the original file based on the position of the camera when the picture was taken. So unless f-spot changes all those files on import, all those images will still be broken in all those other programs. Or if they use something else to copy those images off the camera they will still be broken in all those other programs. This is not f-spot's fault, all that f-spot is doing is putting you in the same class as all those people with smart cameras. I'm saying that I'm not going to change a file while I copy it off the camera without explicit user request. If you really want an option in the preference that changes how explicit rotation is done we can talk about that (f-spot has code for both methods), but it doesn't change the fact that all those programs will still be broken for a large class and quickly growing larger class of users.
Here is a patch against the today's CVS (2006-04-07) which add a 'rotate' checkbox to the export to gallery dialog. It does NOT rotate the stored picture, it only send a rotated version according to the EXIF. I know that such a fux should not be in f-spot but in gallery2, but apparently they don't care a lot about this. So, as long as gallery2 is not fixed, I think it's a good patch candidate for the CVS... See also the mandatory screenshot.
Created attachment 62947 [details] [review] Rotate pictures for Gallery2 as described in comment #13 of this bug
Created attachment 62948 [details] rotate for Gallery2 as described in comment #13 of this bug
Created attachment 63656 [details] [review] Rotate patch for Gallery2 and Folder export A brand-new patch rotating patch. It rotate images for Gallery2 AND also for regular folder export. And also the regular screenshots http://www.delcroix.org/f-spot/rotate-patch.jpg http://www.delcroix.org/f-spot/FolderExport-rotate-1.jpg http://www.delcroix.org/f-spot/FolderExport-rotate-2.jpg Here is an open question regarding this patch: - Is 'Original' able to read EXIF and rotate photos ? Since the code for exporting to 'Original' is the same as the one for exporting to folder, I rotate also images for 'Original'. Could anybody try this patch with 'Original' ? To definitely solve this bug, I still have to fix the 'Export to CD' thing. Stephane
This patch looks pretty good but the rotation should be done the way RotateCoefficients works in RotateCommand.cs
Larry, you mean using JpegUtils.Transform instead of PixbufUtils.TransformOrientation ?? Of course, if JpegUtils.Transform is lossless (or could be), it's obviously the way to do it.
Created attachment 63828 [details] [review] Autorate patch for Export -- using JpegUtils.Transform As proposed by Larry, the sam patch rewritten using JpegUtils.Transform. It works, bu instead of the almost null time for rotating a picture with PixbufUtils.blah, it takes almost 20sec... Is there a knwn issue with libjpegtran or something like this ? Give it a try and report feedback
About the jpegtran timing issue, see Bug 338997
I've commented on the other bug, lets figure that out and get this in.
*** Bug 344506 has been marked as a duplicate of this bug. ***
(In reply to comment #12) > The gallery remote upload api has an explict boolean argument called autorotate > that I know worked with gallery1, if the argument has changed in the gallery2 > stuff or is being ignored we need to debug that. http://sourceforge.net/tracker/index.php?func=detail&aid=1246596&group_id=7130&atid=357130 claims that it is fixed in Gallery SVN. I just tried using a fresh checkout of the gallery2 trunk from svn, and it exhibits the same behavior (fails to rotate). I'll ping the Gallery devs about this, too.
(In reply to comment #23) > I'll ping the Gallery devs about this, too. Any news for this ? Last time I tried to import picture to gallery2 using the galleryremote applet, it was complaining about jpegtran missing... That's how I see the thing: they fixed the rotation in the import applet, not really in the gallery code...
*** Bug 346078 has been marked as a duplicate of this bug. ***
I just exported a rotated photo to flickr and it showed up unrotated. From the looks of the patch that case isn't handled.
Tommi, nope, the patch do not handle export to Flickr and export to CD
For Flickr export it works if you have autorotation enabled in your Flickr profile and do not strip metadata when uploading (see bug 352117 for fun details)
Created attachment 71531 [details] [review] added support for CDExport This one add the Autorotate to CDExport
Created attachment 71538 [details] [review] Fix a small issue in CDExport this keep the original file name even for rotated images on CDExport
Code looks very nice and clean. Could not see any obvious (or even unobvious) problems. Some comments though. 1) GConf - Preferences Only exporting to Gallery checks the gconf for default value for rotate. Not when exporting to CD, or Folder. 2) tripplecated (?) code for rotate Refactoring? The rotate code is very similar between the different cases. Perhaps worthwhile to put this function in Util.cs or somewhere? 3) Disable rotate if not applicable The Rotate button should only be active if user do not resize the photo. (For Web gallery and Folder) 4) Flickr This functionality should also be in Export to Flickr to make it concistent. (Did not try the CD or Gallery export code)
forgot :) My favorit . No tooltips
1) I'd reiterate what Bengt had to say in #31 1), 2), and 4) 2) Bengt's 3), I almost wonder if this would be better served by radio buttons since this is closer to whats actually going on. * Resize to <size> and rotate where necessary * Rotate where necessary * Leave as is 3) Line 400 in FolderExport.cs PixbufUtils.SaveJpeg (scaled, path, 95, data); Why was it changed from 90 to 95 and does it belong in this patch? No images handy to test with, so currently can't test that it works.
One BUG: The Image itself is rotated, but the Exif Thumbnail is not rotated. Steps to perform: - exif -e ~/Photos/image.jpg display ~/Photos/image.jpg.modified.jpeg # exif thumbnail orientated just like the photo - Rotate in F-Spot and export with "autorotate"-option enabled - display ~/exported/image.jpg # photo is correctly rotated exif -e ~/exported/image.jpg display ~/exported/image.jpg.modified.jpeg # exif thumbnail is not orientated like photo, it's the same as before
we discussed the issues in comment #31, comment #32 and comment #33 on IRC, here's a summary. - prefs in gconf: as export to folder include in fact 3 exporter (mostly unrelated), this exporter do not store any pref in gconf. I filled a new bug for this issue: bug #353539 - 3cated code for rotate: As for a lot of code between all the exporters. Out of the scope of this bug. - Flickr can rotate images by itself - sensible UI: Ben idea or radio button is good. I'll implement it if I find the time. not a showstopper though. - tooltips: ... - jpeg quality. sorry, it's a local change that I diffed with the patch. I'll correct it. As discussed, this patch is almost ready for commit as is. (I need to look at the issue of the comment #34)
Fabian (comment #34): confirmed ! jpegtran is used for rotating image losslessly. apparently, it does not rotate the thumbnail :( I'll try to find a workaround for this
crap ! when trying to find out more on comment #34, I found a bug in the rotate code ! the image is rotated but the metadata are not changed. so you can't reimport in f-spot an image exported with the rotate checked. working on it...
Stephane: if I might beg in an unrelated bug, it would be great if you could also fix the import half of that bug- I have some pictures mangled by gthumb (rotated but metadata not changed) that I can't import to f-spot.
Created attachment 71920 [details] [review] fix This fix the issue I discovered and reported in comment #37. It also restore the original jpeg compression (reported by ben)
Luis (comment #38) no, I can't. I don't have any way to say if an image is well rotated or not. Nevertheless, I have a workaround for you, I send you that by email right now.
I don't expect them to be imported correctly, just imported *at all*- I believe this was reported fixed in bug 340155, so I was surprised to see you say you couldn't import, but maybe I misunderstood. Unfortunately I am not running HEAD and the bug only affects a few dozen out of thousands of my pictures, so I can't test right now. :/
oh, that problem. sorry, misunderstood. this problem was happening with some versions of libexif on 0.1.11. Larry claim that it's fixed in 0.1.12. But you can also upgrade your libexif 0.6.13. This issue was mainly reported on ubuntu, but the latest package is working fine.
re gallery2: I patched gallery 2.1.2 to bring the relevant modules up to svn and it rotates the images correctly on import, without needing to patch f-spot.
(In reply to comment #10) > Second, I'm not going to rotate on disk for the normal case Doing so changes > the file (which will break the duplicate checking that is about to go in), > requires changes to the exif data (many programs fail to update the right > fields here), and simply won't work with raw files. More and more cameras > write out the orientation so those other programs that aren't handling the > orientation will continue to fail do the right thing with more and more images. > I don't see how it is better if f-spot hides their problems by altering the > image. > This makes little sense. As far as 99% of the image manipulation programs out there are concerned, the jpeg files "rotated" in F-Spot remains untouched. Why can't F-Spot do with rotating as it does with every other image manipulation function, namely to create a (Modified) version and physically change _that_ version? Use Case: I imported an image from the camera. The image is stored in 4:3 ratio, and I want to change it to 3:2 ratio and rotate it 90 degrees. I first crop it, then rotate it. This results in a (Modified) version of the original, with the new aspect ratio. However, the image remains unrotated when I reboot to Windows to perform some final adjustments in Photoshop. The fact that virtually every other image manipulation out there ignores the EXIF data is a strong reason to perform a physical rotation of the jpeg file.
stephane, the patch no longer applies cleanly.
Created attachment 72561 [details] [review] refactored version of stephane's patch This is what I committed. everyone please test this in cvs heavily.
I just wanted to note that http://bugzilla.gnome.org/show_bug.cgi?id=165645#c34 is not fixed in current cvs. Can someone look through it again?
Fabian, I opened a new bug (bug #356363) for this particular issue.