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
