Michael Schumacher wrote:

we've been approached on the #gimp channel by Marina Zhurakhinskaya from
the GNOME Outreach Program for Women. She has helped GSoC applicants with their applications and is currently looking for a mentor for the following project:

Full version (minus personal data of the student, of course):

http://www.fpaste.org/qLNt/raw/

so I read the whole thing.

OK, it is a gnome project, not a GIMP project, and that is good because I am 80% sure that this kind of functionality is not desirable in GIMP.

This kind of mechanism is part of the nuts and bolts of _database_ type photo management apps like iPhoto, and it works there, because users (in general) do not access the file tree of the repository. So getting an image on another drive or system literally means dragging the image out of the app, not from a directory to somewhere else. This makes it an explicit export out of the app and makes it plausible why those images cannot be reverted to original.

I see this not working for GIMP because it is file system based, it does not mesh well with the GEGL lossless editing metaphor, and because moving GIMP files between systems/users where it gets worked on further (with full modification history) is simply a requirement for us.

what Kamila and I presented years ago in Montreal was that what we need is a _simple_ versioning mechanism inside GIMP files, built on top of GEGL.

that covers (for GIMP) the user needs that this proposal tries to address.

--ps

founder + principal interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

On 4/14/10, Michael Schumacher wrote:

Hi,

we've been approached on the #gimp channel by Marina Zhurakhinskaya from the GNOME Outreach Program for Women. She has helped GSoC applicants with their applications and is currently looking for a mentor for the following project:

Abstract:

"Image editors overwrite originals of an image file with modified versions, causing originals to be lost by default, or clutter up folders with original and modified images. Some make copies of images and organise them in a predefined unalterable manner (e.g. date taken). This causes loss of originals and messy photo collections. The system being proposed would allow the user to modify images in any folder, and allow any modified image to be reverted back to its original unmodified version."

Marina, asked me to reply on the list, so here goes.

The proposal says:

"When editing an image file for the first time in an image editor, a copy of the original unmodified version of the image should be saved in a different location."

I'm afraid that the course taken by the student is completely behind present time.

These days non-destructive editing equals to writing description of changes into database and/or sidecar metadata files like XMP. The sidecar way is especially good , because it makes a photo collection easily portable -- just copy a folder on a flash drive and plug it to a different system. With proposed file system approach one would have to carry all the copies of original image around. So issue #1 is portability.

The portability issue is very much related to the issues #2 -- how much disk space is used. The proposal doesn't seem to make it clear if (or maybe I'm missing it) if intermediate steps would be kept around. When you edit photos, amount of changes, or revisions, can grow to dozens. Surely you don't want several dozens of just one image around. But when only final revision is saved, you lose the sequence of changes. A simple example of changes:

a) crop and/or straighten b) fix white balance
c) denoise and/or sharpen
d) try some effect like sepia or b/w

For point-and-shoot cameras somewhere in the middle there would be red-eye removal as well.

If you revert to original, you need to do a-c again. This is a terrible overhead from usability POV. A lot of people ditched first version of Picasa exactly for that reason. But then Picasa started writing small text files with description of changes on per-directory basis that were replayed by Picasa upon loading photos, and lo and behold -- it's one of the most popular photo management applications on Windows.

Then comes issue #3 -- quality. To keep disk space less occupied one would have to save copies to JPEG or some wavelet file format. Which automatically means quality loss.

What I would suggest is not spend time on creating a cumbersome solution that won't make users life easier, but work on Solang or F-Spot instead. The first one requires C++ skills, the second one -- C#.

Alexandre

From a GIMP perspective: How about saving the undo history with the xcf. I always wished that vi did that.

I can certainly see a few problems, but perhaps it's worth some thought...(if not covered before)

As for the proposal: it strikes me more as a (file) system proposal. Why should it just be for images? leads to version history for all files ... etc...

Cameron

On 04/14/2010 08:54 AM, Alexandre Prokoudine wrote:

On 4/14/10, Michael Schumacher wrote:

Hi,

we've been approached on the #gimp channel by Marina Zhurakhinskaya from the GNOME Outreach Program for Women. She has helped GSoC applicants with their applications and is currently looking for a mentor for the following project:

Abstract:

"Image editors overwrite originals of an image file with modified versions, causing originals to be lost by default, or clutter up folders with original and modified images. Some make copies of images and organise them in a predefined unalterable manner (e.g. date taken). This causes loss of originals and messy photo collections. The system being proposed would allow the user to modify images in any folder, and allow any modified image to be reverted back to its original unmodified version."

Marina, asked me to reply on the list, so here goes.

The proposal says:

"When editing an image file for the first time in an image editor, a copy of the original unmodified version of the image should be saved in a different location."

I'm afraid that the course taken by the student is completely behind present time.

These days non-destructive editing equals to writing description of changes into database and/or sidecar metadata files like XMP. The sidecar way is especially good , because it makes a photo collection easily portable -- just copy a folder on a flash drive and plug it to a different system. With proposed file system approach one would have to carry all the copies of original image around. So issue #1 is portability.

The portability issue is very much related to the issues #2 -- how much disk space is used. The proposal doesn't seem to make it clear if (or maybe I'm missing it) if intermediate steps would be kept around. When you edit photos, amount of changes, or revisions, can grow to dozens. Surely you don't want several dozens of just one image around. But when only final revision is saved, you lose the sequence of changes. A simple example of changes:

a) crop and/or straighten b) fix white balance
c) denoise and/or sharpen
d) try some effect like sepia or b/w

For point-and-shoot cameras somewhere in the middle there would be red-eye removal as well.

If you revert to original, you need to do a-c again. This is a terrible overhead from usability POV. A lot of people ditched first version of Picasa exactly for that reason. But then Picasa started writing small text files with description of changes on per-directory basis that were replayed by Picasa upon loading photos, and lo and behold -- it's one of the most popular photo management applications on Windows.

Then comes issue #3 -- quality. To keep disk space less occupied one would have to save copies to JPEG or some wavelet file format. Which automatically means quality loss.

What I would suggest is not spend time on creating a cumbersome solution that won't make users life easier, but work on Solang or F-Spot instead. The first one requires C++ skills, the second one -- C#.

Alexandre