Response from Shotwell team founder

Posted Jun 17, 2010 23:07 UTC (Thu) by dlang (guest, #313)
In reply to: Response from Shotwell team founder by adamdingle
Parent article: A quick grumpy review of Shotwell

I think that the key thing is that the current model is based on the premise that the user will only use one application to touch their pictures.

the Grumpy Editor (and many of the rest of us) want to be able to use multiple different apps to deal with the pictures.

we may use Shotwell to view and organize the pictures, but gimp to edit them, (or imagemagic to resize them, or dcraw to convert from raw, etc)

we could let Shotwell import them (and copy them) into it's own structure, and then point these tools at the results, but this will fail as soon as any other tool also wants to take complete control of the pictures, so Shotwell is viewed as being anti-social by doing so.

We understand that this is common practice for the propriatary software world (windows and MAC especially), but the unix philosophy is to allow you to use multiple tools, allowing the user to pick best-of-breed solutions for each task. It's nice if there is one GUI that can leverage the specialized work and be a single panel for doing the common work, but if that prevents other tools from being used, that GUI can easily become more of a liability than an asset.

It's not strictly necessary for all the metadata to be stored in the initial files, but it should be stored in some way that makes it possible for other apps (and/or scripts) to find, access, and ideally modify this data. putting it in exif is one way (and probably the easiest cross-application method), but not the only way.

This also isn't saying that copies of the pictures shouldn't be made. In fact if you modify the image (especially if you modify the image in a way that cannot be perfectly undone) you _should_ make a copy of the image in some manner before you do so.

Response from Shotwell team founder

Posted Jun 18, 2010 0:32 UTC (Fri) by jspaleta (subscriber, #50639) [Link] (5 responses)

If they implement an edit in another application feature does this solve the problem of multi-application editting?

I think the key question for me is..
what's is the best way to implement a revision control system for images that works well across multiple applications? I really don't want to have to keep oodles of copies of my photos around when I touch them up for different formats. I want revision control in a _smart_ way.

Shotwell's database is just a mechanism to do for images what git does for source code isn't it?

The problem is, we are building dedicated photo revisioning systems into applications silos. What we need is a common revisioning system that _ALL_ imaging processing applications can use. Even commandline usage..where you checkout specific imagine revision, edit the image,then import that back into the image revision database as a changeset (with tags or other metadata as deemed appropriate)

-jef

Response from Shotwell team founder

Posted Jun 18, 2010 0:42 UTC (Fri) by dlang (guest, #313) [Link] (4 responses)

no, shotwell is like if git was integrated into gedit and you could only access the files through gedit.

git doesn't force you to use a specific tool to manipulate the working copy of the files stored in it.

if shotwell organized the images and left them alone in the filesystem for you to use whatever tool to tweak them, you would not see people raising this objection.

Response from Shotwell team founder

Posted Jun 18, 2010 13:21 UTC (Fri) by paulj (subscriber, #341) [Link] (3 responses)

Insightful comment there.

It follows from what you say that an equivalent model with Shotwell would be if the photos on disk were with modifications applied, with Shotwell keeping data somewhere on how to undo changes (or conversely how to change the original to the current version on disk). ?

Response from Shotwell team founder

Posted Jun 18, 2010 14:51 UTC (Fri) by adamdingle (guest, #67751) [Link] (2 responses)

I agree: it would make sense for Shotwell to store photos on disk with modifications applied, but with the original photo backed up under a separate filename and also storing information about how to change the original to the current version on disk. As some people have observed, it would even be nice if the transformation information could be shared among programs, not specific to one program such as Shotwell. Perhaps we can get there one day. We're interested in modifying Shotwell to use a GEGL pipeline and that might be one step toward a transformation structure that can be shared.

Response from Shotwell team founder

Posted Jun 18, 2010 18:52 UTC (Fri) by dlang (guest, #313) [Link]

that would be good. I don't think it's that necessary for the exact details of how to convert one to another be available cross application (other than as comments/documentation trail/changelog)

but the unmodified original should always be available (or recoverable, with with lossy compression algorithms means a copy), and the currently 'final' result should be accessable without a need to run some export process.

Response from Shotwell team founder

Posted Jun 19, 2010 2:42 UTC (Sat) by spitzak (guest, #4593) [Link]

Editing should just move the original from X/foo.jpg to X/originals/foo.jpg, and it should throw it away if that file is already there (thus you only keep the most recent edit and the original). If other applications followed this rule as well then you could use any editor and still recover the original.

I would very much like to see a photo manager that just leaves the files where they were. You would give it a list of directories and it will act like the set of photos is every photo found in those directorys and any subdirectories. If a file is in a given directory it acts like it has a tag that is the directory name, as well as any tags that are in the EXIF data. Attempting to remove these "directory tags" would, I guess, move the files, perhaps with a warning. Or add a "not actually tagged with this" tag.

For Linux apps this almost is necessary, just so you can cooperate with some of those proprietary apps that insist on moving the files. For instance I would like to use it to at least look at an rsync copy of a iPhoto directory. If we are careful we should be able to at least change the tags and perhaps edit files and those apps will still handle it.

There may be an "import" but it would be for reading off of cameras and SD cards and other removable media, where you have a good reason to want a copy. The user should be able to choose what directory it goes into, and there should be programmable scripts (with some pre-supplied ones) to use dates and other EXIF data to place the files into subdirectories.