Update image file with editing operations (store backups elsewhere)

It's debatable whether this feature request is desirable in this form. On the Shotwell mailing list, I posted a few weeks back asking where Shotwell should store modified copies:

http://lists.yorba.org/pipermail/shotwell/2010-April/000283.html

A couple of users responsed and said that they did *not* want Shotwell to touch their original files.

Currently, as you may know, Shotwell does not store modified copies of photos anywhere (it simply applies any user edits to the master photo on the fly each time it needs to display a photo). We are considering storing modified copies somewhere, however - this is http://trac.yorba.org/ticket/1798 (which will probably not make 0.6, however). One compromise is to store modified copies in the same directory as the original files with a suffix such as "(modified)". This is what F-Spot does. Would this be acceptable to you?

Mailing list discussion:
http://lists.yorba.org/pipermail/shotwell/2010-April/000283.html

Heh, mid air collision :)

This point was the most discussed in the UDS sessions. It seemed people were divided into two camps:

A. Behaving as a photo *library*. In this case photos are imported (probably copied) into the library and originals are left untouched. The supporters said this was best for professional users (don't mess with my files) and users "who didn't want to know where their files were". iPhoto was frequently used as an example.

B. Behaving as a photo *viewer*. In this case the application provided a better way to browse and modify your photos than a file manager. An example of why this is desired was when you needed to use a photo in a way that the application didn't support. Also commented on was user frustration "where are my photos?", perhaps by users who are more familiar with file interfaces. This was considered old-fashioned by some people.

It was also agreed that we should check with the Shotwell developers to see what metaphor they considered most appropriate - we certainly don't want to demand anything to be a certain way.

My personal feeling is B is the better case. While we all know the file system is outdated it still is a major part of the desktop. If a user sees a photo in the file browser and the same photo in the photo application they will justifiably consider them the same object. Any modifications to that object should be reflected in both the photo application and the file browser.

So to cut a long story short, yes, your solutions sounds good to me:
+1 It follows an existing convention
+1 It means the files can be used elsewhere
+0 It does mean that you see duplicates when browsing other applications

I'll ask around for some more opinions.

Another factor to consider is that starting with version 0.6, Shotwell will allow the user to import RAW files from cameras. If the user edits a RAW photo in Shotwell, we cannot update the RAW file with those changes; only cameras can write RAW data. So even if we go with approach (B) above, for every RAW master file all changes would need to be written to a separate JPEG photo file, presumably in the same directory as the RAW master.

Personally I prefer the leave my files, save an alternate copy if I want it, perhaps with an alternate location. This sort of follows things like Light Room, F-Spot and Picasa which I suspect are managers most people come from.

From our use we like to have an original shared resource that is unchanged and save out to our own library our modified files versions. That means we can have links to a common image and our own changes are consistent and preserved.

As more and more photos are kept by individuals, families and businesses on external drives, NAS or servers I think something that works in this sort of way in a distributed multi-device, multi-user environment would be best. Just my 2 pence(cents) worth ;-)

After reading this thread, I realized hours of organizing my photos taken on vacation in Shotwell, they were simply not synchronized to my cloud drive. I'll go back to F-spot then.