after a crop and an external edit, SHIFT shows original in cropped dimensions
Submitted by Adam Dingle
Link to original bug (#717204)
Description
---- Reported by adam@yorba.org 2011-01-06 15:28:00 -0800 ----
Original Redmine bug id: 3067
Original URL: http://redmine.yorba.org/issues/3067
Searchable id: yorba-bug-3067
Original author: Adam Dingle
Original description:
To see the problem:
Import a photo into Shotwell.
In Shotwell, select the photo and choose Open in External Editor.
In the external editor (e.g. GIMP), crop the photo so that its aspect ratio changes significantly.
Save the photo in the external editor.
In Shotwell, open the photo in full-window mode and press SHIFT to show the original. The original will be stretched to fit into the cropped photo's dimensions. Instead, the original should display with the original photo dimensions.
This bug was reported on the mailing list (http://lists.yorba.org/pipermail/shotwell/2010-December/001483.html), and the reporter stated that sometimes the original photo will also be badly rotated when displayed using the SHIFT key. (I haven't yet been able to reproduce that.)
Related issues:
- duplicated by shotwell - 3696: aspect ratio wrong after crop and external edit (Duplicate)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-01 11:47:00 -0700 ----
History
Comment 1
Updated by Adam Dingle almost 3 years ago
- Target version set to 0.9
Comment 2
Updated by Adam Dingle almost 3 years ago
- Status changed from Open to Review
- Assignee changed from Anonymous to Eric Gregory
Comment 3
Updated by Adam Dingle over 2 years ago
- Assignee changed from Eric Gregory to Anonymous
Unassigning since I think this isn't as important as some other bugs we have open. Hopefully we can return to this later in the 0.9 cycle.
Comment 4
Updated by Clinton Rogers over 2 years ago
The underlying problem seems to be that [Photo.get_raw_crop](http://trac.yorba .org/browser/shotwell/trunk/src/Photo.vala) only 'knows' about cropping that happens inside Shotwell. If an external editor changes the dimensions, no dimension-altering transformation gets added to the map, and so get_raw_crop() thinks nothing happened and returns early before actually fetching the original dimensions.
The correct solution seems to be that, for any external edit, we should 'lie' and say a crop occurred within the application.
Comment 5
Updated by Adam Dingle over 2 years ago
- Assignee changed from Anonymous to Clinton Rogers
OK, good to know. Assigning to you, Clinton – can you meet with Jim to discuss your proposed solution?
Comment 6
Updated by Clinton Rogers over 2 years ago
Revising my original opinion upon more thorough exploration; the code in get_raw_crop is correct, and the incorrect dimensions and rotation are coming from the backing photo state. Somewhere in there, we need to switch from the editable one to the master when asked to show the original version of a photo, but know enough to switch back when Shift is released in the Photo page…
Comment 7
Updated by Clinton Rogers over 2 years ago
Proposed patch submitted via email.
Comment 8
Updated by Clinton Rogers over 2 years ago
To see the bad rotation problem:
-
Take a portrait-orientation photograph with a camera that can set the orientation in the EXIF data.
-
Import it.
-
Open it in an EXIF-aware external editor (GIMP will work for this), and when GIMP asks if it should rotate the image based on EXIF data, choose 'Yes'.
-
Make some changes to the image and save them.
-
Return to Shotwell and press Shift.
The proposed fix addresses this too.
Comment 9
Updated by Clinton Rogers over 2 years ago
It turns out that, with the patch I submitted, it still breaks if the user disables library monitoring…
Comment 10
Updated by Adam Dingle over 2 years ago
-
Target version deleted (
<strike>
_0.9_</strike>
)
Comment 11
Updated by Adam Dingle over 2 years ago
- Target version set to 0.10
Comment 12
Updated by Adam Dingle over 2 years ago
- Assignee changed from Clinton Rogers to Anonymous
-
Target version deleted (
<strike>
_0.10_</strike>
)
Comment 13
Updated by Adam Dingle over 2 years ago
- Target version set to 0.10
Comment 14
Updated by Adam Dingle over 2 years ago
-
Target version deleted (
<strike>
_0.10_</strike>
)
Comment 15
Updated by Adam Dingle over 2 years ago
- Target version set to 0.11
Comment 16
Updated by Vera Yin over 2 years ago
- Subject changed from after cropping in external editor, SHIFT shows original in cropped dimensions to after a crop and an external edit, SHIFT shows original in cropped dimensions
Comment 17
Updated by Adam Dingle over 2 years ago
- Description updated (diff)
-
Target version deleted (
<strike>
_0.11_</strike>
)
Comment 18
Updated by Clinton Rogers almost 2 years ago
- Description updated (diff)
- Status changed from Open to 5
- Target version set to 0.12
- % Done changed from 0 to 100
- Resolution set to worksforme
Something else along the way repaired this; I am not seeing this behaviour anymore.
Comment 19
Updated by Charles Lindsay 7 months ago
- Status changed from 5 to Invalid
--- Bug imported by chaz@yorba.org 2013-11-25 21:49 UTC ---
This bug was previously known as bug 3067 at http://redmine.yorba.org/show_bug.cgi?id=3067
Unknown Component Using default product and component set in Parameters 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.12
Resolution: RESOLVED INVALID