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


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
> _______________________________________________
> Gimp-developer mailing list
> Gimp-developer@lists.XCF.Berkeley.EDU
> https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Gimp-developer mailing list

Reply via email to