---- Reported by adam@yorba.org 2010-04-16 14:01:00 -0700 ----

Original Redmine bug id: 1798
Original URL: http://redmine.yorba.org/issues/1798
Searchable id: yorba-bug-1798
Original author: Adam Dingle
Original description:

At some point I think that Shotwell should keep a full-resolution version of
each image the user has edited. This would have a number of benefits. It would
allow dragging/dropping to other applications (#1563) and make it easier for
us to open photos in an external editor (#1479). It would also improve
performance when browsing through photos and quite possibly when zooming as
well.

I asked on the mailing list where Shotwell should store modified copies of
photos. People didn't want Shotwell to overwrite the originals in place. It
seemed that people leaned toward keeping the modified copies in the same
directories as the originals, though this is still up for discussion.

I think we should consider this for 0.6.

(iPhoto does this, by the way.)

Related issues:
related to shotwell - Feature #1563: allow drag/drop to other applications (Open)
related to shotwell - Feature #1098: Copying and pasting photos (Open)
related to shotwell - Feature #2872: FUSE module (shotwellfs) (Open)
related to shotwell - Feature #6175: Upload to Facebook status message (Open)
related to shotwell - 5583: Twitter publishing support (Open)
related to shotwell - Feature #3451: Suggestion: add a 'copy path to
clipboard' option to the ... (Open)
related to shotwell - 4261: Camera RAW developer wastes disk space by
extracting embe... (Open)
related to shotwell - Feature #6748: Use Fully-Transformed Photos, if
Available, Throughout Sh... (Open)
related to shotwell - Feature #6447: allow send to to access photos in place (Open)
related to shotwell - Feature #6747: Update Preferences Dialog to Enable Users
to Choose to Ha... (Open)
related to shotwell - Feature #6751: Implement a "Save As Original" Menu
Option (Open)
related to shotwell - Feature #6750: Delete Transformed Photos When User
Disables Writing Them (Open)
related to shotwell - Feature #6749: Implement TransformedPhotoWriter (Open)
related to shotwell - Feature #1933: Allow user to save edits to photo file (Open)
duplicated by shotwell - Feature #657: Store modified photos in user-
accessible location (Duplicate)



---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-16 14:33:00 -0700 ----

### History

####

#1

Updated by Adam Dingle over 3 years ago

  * **Status** changed from _Open_ to _Review_
  * **Assignee** changed from _Anonymous_ to _Jim Nelson_

####

#2

Updated by Adam Dingle over 3 years ago

  * **Assignee** changed from _Jim Nelson_ to _Anonymous_
  * **Priority** deleted (<strike>_High_</strike>)

Jim and I discussed this at length. This is now off the table for 0.5.
Dropping to medium.

####

#3

Updated by Jim Nelson over 3 years ago

0.6.

####

#4

Updated by Adam Dingle over 3 years ago

After more feedback from the community, it turns out that some people
**would** like Shotwell to overwrite originals in place so they always appear
up to date in the filesystem. If we did that, Shotwell could move/rename the
original master photo files (perhaps into a subdirectory) before overwriting
so that they would still be available in case the user wants to adjust
transformation parameters or revert to original.

Users seem to be in different camps as to how this should work, and this could
conceivably be a user option.

####

#5

Updated by Adam Dingle over 3 years ago

  * **Priority** set to _High_

####

#6

Updated by Adam Dingle over 3 years ago

  * **Priority** deleted (<strike>_High_</strike>)

####

#7

Updated by Adam Dingle almost 3 years ago

  * **Priority** set to _High_

####

#8

Updated by Anonymous over 2 years ago

I'd like to see this as well. I'm using a script to backup/upload the pictures
in my library, and currently it's not getting the post-edited versions.

Whether you do write-to-copy or overwrite-original is fine with me, as long as
there is a simple/deterministic convention so that my script can tell which
are: originals with no edits (process those), originals that were edited (skip
to avoid duplicates), the edited version of originals (process those).

Keeping the files in the same directory with a simple naming convention like
foo.jpg/foo_mod.jpg (or foo.jpg/foo_orig.jpg) would let me do it this just a
simple file name/existence check.

####

#9

Updated by Adam Dingle almost 2 years ago

  * **Description** updated (diff)
  * **Target version** set to _0.12_

Upping for consideration for 0.12.

####

#10

Updated by Adam Dingle almost 2 years ago

  * **Target version** deleted (<strike>_0.12_</strike>)

####

#11

Updated by Adam Dingle over 1 year ago

  * **Target version** set to _0.13_

This would not be a small change, but would have many benefits. Upping for
consideration for 0.13.

####

#12

Updated by Adam Dingle over 1 year ago

  * **Target version** deleted (<strike>_0.13_</strike>)

####

#13

Updated by Jim Nelson 12 months ago

  * **Target version** set to _0.14.0_

####

#14

Updated by Jim Nelson 11 months ago

  * **Category** set to _library-mode_

####

#15

Updated by Jim Nelson 11 months ago

  * **Target version** changed from _0.14.0_ to _0.15.0_

We'll take a look at this for 0.15.

####

#16

Updated by Jim Nelson 8 months ago

Note that this ticket is now an umbrella ticket for the various components we
need to put into place for this feature: #6747, #6748, #6749, #6750, and
#6751.

####

#17

Updated by Jim Nelson 6 months ago

  * **Target version** deleted (<strike>_0.15.0_</strike>)



--- Bug imported by chaz@yorba.org 2013-11-25 21:45 UTC  ---

This bug was previously known as _bug_ 1798 at http://redmine.yorba.org/show_bug.cgi?id=1798

Unknown version " in product shotwell. 
   Setting version to "!unspecified".
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.
Resolution set on an open status.
   Dropping resolution