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