Rotation confusion when another app has rotated and resaved
Submitted by an unknown user
Assigned to cli..@..ba.org
Link to original bug (#716172)
Description
---- Reported by shotwell-maint@gnome.bugs 2010-05-17 13:21:00 -0700 ----
Original Redmine bug id: 1938
Original URL: http://redmine.yorba.org/issues/1938
Searchable id: yorba-bug-1938
Original author: Neil Emms
Original description:
Because Shotwell is non-destructive the rotations are not carried through to other image editing applications.
If I wish to make edits in those apps (using features not available in Shotwell) and I also rotate in that app and resave, Shotwell gets very confused (doing a bizarre internal over-rotation).
The only way to fix it is to remove and re-import.
It should be able to handle this in some way – even with manual intervention, which doesn't currently work
Related issues:
- related to shotwell - 4262: Camera (Embedded) RAW developer fails to show correct pho... (Fixed)
- related to shotwell - 6430: Rotating, externally editing with certain editors, then r... (Fixed)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-01 11:40:00 -0700 ----
History
Comment 1
Updated by Adam Dingle over 3 years ago
Right. To some degree, this is an instance of a more general problem: changes in Shotwell (e.g. a rotation) aren't currently visible when you edit the photo file in another application, so if you make changes in another application then Shotwell's changes are applied on top of those, which is particularly confusing when you have rotated in both places.
Two possible solutions:
-
We're adding the ability to invoke an external editor (such as GIMP) on a photo from within Shotwell (#1479 (closed)). When you do so, Shotwell will write the photo including its changes to a file and invoke the editor on that file. So you'll see Shotwell's changes in the external editor and won't be tempted to add an additional rotation there, for example.
-
Perhaps we should consider writing Shotwell rotations out to original photo files' EXIF data. If we did so, that would solve this problem directly. We're currently debating when (if ever) Shotwell should write metadata to photo files on the fly (this may end up a user option), and rotation is one of the kinds of metadata we should consider.
Comment 2
Updated by Neil Emms over 3 years ago
Another solution would be to remember the undo history for each picture. That way any Shotwell edits can be undone at any time.
I don't necessarily want to mention Picasa here, but this has the same rotation problem (though it exhibits differently, in that the picture is rotated twice rather than displayed horizontally in a vertical picture, as Shotwell does) but it remembers the edit history each picture, allowing you to undo any actions you may have performed on it.
Both of your suggestions are just fine, and I like both of them but a full undo history is also useful. After all, if I am unable to undo my Shotwell changes (after Shotwell has been closed and reopened) then it's not non- destructive anymore, so you kind of get the worst of both worlds – Shotwell changes are not actually in the file, but I'm unable to remove them in Shotwell.
Comment 3
Updated by Paolo Milani about 3 years ago
I was also affected by this bug (running shotwell 0.7.2 on ubuntu maverick), and can confirm that deleting an affected photo from the shotwell library and re-importing solves the issue.
I would much prefer solution number 2: especially since writing a rotation in the EXIF data loses no image quality, I see no reason for not saving it in the file. I do not think solution 1 would solve the problem, since the user might not go through this shotwell interface to open the file and instead open the file directly on the file system.
More generally, as a user I prefer all metadata (such as tags) and changes I apply inside a media management program to be reflected in the files in the file system: this way I am not locked into any particular program (I have already migrated away from f-spot and am now using bits and pieces of both shotwell and picasa). If the changes are lossy, I think creating a backup is a better solution than not applying the changes to the file system.
Hope this little rant is not too much out of place in trac, and thanks all for developing this neat software.
Comment 4
Updated by Jim Nelson about 3 years ago
It's not out of place, feydrutha. This is a great place to voice concerns and opinions, as it helps us make decisions about how best to proceed. Thanks!
As far as tags and other metadata being stored in files, know that this is planned for 0.8. More information at #1290.
Comment 5
Updated by Jim Nelson 11 months ago
- Target version set to 0.14.0
Comment 6
Updated by Jim Nelson 11 months ago
- Category set to library-mode
Comment 7
Updated by Jim Nelson 11 months ago
- Description updated (diff)
- Priority changed from Low to High
This problem is partially fixed due to a combination of features: runtime monitoring and edit with external editor. If I edit color in GIMP, for example, Shotwell re-imports the file when it's saved.
However, there is still a rotation bug, at least with GIMP. If I rotate the image and save it, Shotwell will reimport but not rotate the thumbnail (or the dimensions), creating a stretched-out image. If I open an image with non-TOP LEFT orientation and tell GIMP to rotate it, then rotate manually and save, Shotwell will work fine. If I rotate in GIMP and save again, I get another stretched photo.
This is a regression, as this used to work. We should fix this.
Comment 8
Updated by Jim Nelson 9 months ago
- Assignee set to Clinton Rogers
Comment 9
Updated by Clinton Rogers 9 months ago
100% repro case:
- Import an image that was taken with the camera held in portrait position.
- Set GIMP as the external editor.
- Choose to externally edit the image from step one.
- When GIMP asks if it should rotate the image to standard orientation, choose yes.
- Modify and save the image.
- In Shotwell, revert the image, choosing yes when it asks if it should discard external edits.
Notice that the reverted image is now in the wrong orientation.
note: this was broken out into its own bug; please see #6430
Comment 10
Updated by Clinton Rogers 9 months ago
I've noticed that after an image has been edited in GIMP, the orientation always comes out as top-left; this may be the source of Shotwell's woes...
Comment 11
Updated by Clinton Rogers 9 months ago
- Status changed from Open to Review
- % Done changed from 0 to 60
Comment 12
Updated by Clinton Rogers 9 months ago
Please look at the branch [bug/1938-salvation-from-rotation-concatenation- frustration, SHA 1f39a8f97c05a18ec196e95dc5034694b9c82076](http://redmine.yorb a.org/projects/shotwell/repository/revisions/1f39a8f97c05a18ec196e95dc5034694b 9c82076) for this.
Comment 13
Updated by Lucas Beeler 9 months ago
Review: approve. Commit!
Comment 14
Updated by Clinton Rogers 9 months ago
- Status changed from Review to 5
Applied in changeset 2c2bdfd9.
Comment 15
Updated by Clinton Rogers 9 months ago
- % Done changed from 60 to 100
- Resolution set to fixed
Comment 16
Updated by Charles Lindsay 7 months ago
- Status changed from 5 to Fixed
--- Bug imported by chaz@yorba.org 2013-11-25 21:44 UTC ---
This bug was previously known as bug 1938 at http://redmine.yorba.org/show_bug.cgi?id=1938
Unknown milestone "unknown in product shotwell. Setting to default milestone for this product, "---". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one.
Version: 0.14.0
Resolution: RESOLVED FIXED