GNOME Bugzilla – Bug 344488
Proper rotating
Last modified: 2018-07-01 09:05:35 UTC
In trying to get flickr to auto-rotate images from f-spot I found that it didn't make any changes no matter which way the images had been rotated in f-spot. I also noted that if I rotated the image within my camera that flickr handled them proper even if I uploaded them through f-spot. Figuring there was a problem with the exif orientation tags I ran exif on both images. When I ran exif on an image I had rotated using f-spot and compared it to one from the camera, I found that the camera-rotated-image had these entries for Orientation: dberg@dale:~/Photos/2006/6/10$ exif DSC02341.JPG | grep Orientation Orientation |right - top Orientation |right - top Where as the image rotated in f-spot had these entries: dberg@dale:~/Photos/2006/6/10$ exif DSC02342.JPG | grep Orientation Orientation |right - top Orientation |top - left Apparently flickr looks at both or just the second and is either confused by the mismatched info or decides it doesn't need to be rotated.
can you attach this photo? It sounds like perhaps the thumbnail has an orientation specified, and flickr is doing something to simplistic when searching for the orientation (like using the last tag found).
Created attachment 67206 [details] Improperly rotated photo Just took this photo, imported it into f-spot, rotated it, then exported to flickr. The attached image is taken directly off the camera. The image on flickr is public and located here: http://www.flickr.com/photos/bergs/165862514/. --Dave
Created attachment 67207 [details] Test photo from Photos directory Not sure why I pulled the image off the camera and not from the photo location. This image is pulled from ~/Photos. --Dave
Definitely looks like a flickr bug. It is using the thumbnail orientation as the overall orientation and ignoring the setting it should be using.
I concluded that as well, but I don't understand why F-Spot wouldn't change the thumbnail orientation as well. How often does one end up with a photo where the thumbnail is oriented properly but the image isn't? I'll file a bug with Flickr, but I would expect that most other managers/cameras rotate both orientation fields. If they didn't I would expect that flickr would have remidied the problem. Thats not to say that F-Spot should do it because every one else does it. I guess I would just hope that there was a good reason for F-Spot not to do something that other clients do. --Dave
The reason is that f-spot isn't currently changing it is that this is the first image I've ever seen with an orientation specified on the thumbnail. Changing the orientation on the thumbnail if the tag exists is definitely something that should be fixed, but it doesn't make flickr any less broken in how they are reading the exif data. Fixing it would just mean that the thumbnail in the metadata dialog would show up with the right orientation.
How can I create a patch to fix this? I spend quite a bit of time rotating photos twice and would rather direct it towards programming. I'm familiar with C++, but not C# or f-spot's code base. Is it easy enough to fix for a rusty old programmer?
The most recent complaint came because I was re-uploading all my photos to flickr. Now that the newest photos are being uploaded I'm finding that they are correct. Is there a way to have f-spot go through and correct the old images? Thanks for fixing this.
Latest F-Spot with TagLib crashes importing this photo. See https://bugzilla.gnome.org/show_bug.cgi?id=625367
f-spot is not under active development anymore, has not seen code changes for five years, and saw its last tarball release in the year 2010. Its codebase has been archived: https://gitlab.gnome.org/Archive/f-spot/commits/master Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active development again.