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

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 --

Gimp-developer mailing list

Reply via email to