Re: [Gimp-developer] [Gegl-developer] [GSoC] Mentor Request from GNOME Outreach Program for Women
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@lists.XCF.Berkeley.EDU > https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer > ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Gegl-developer] [GSoC] Mentor Request from GNOME Outreach Program for Women
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
Re: [Gimp-developer] [GSoC] Mentor Request from GNOME Outreach Program for Women
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] [GSoC] Mentor Request from GNOME Outreach Program for Women
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." Full version (minus personal data of the student, of course): http://www.fpaste.org/qLNt/raw/ If you are interested in commenting on or mentoring this application, then please sign up as a mentor with the GNOME organization. But keep in mind that ranking of the proposals is currently underway, so don't wait too long: http://socghop.appspot.com/gsoc/org/apply_mentor/google/gsoc2010 Regards, Michael -- GIMP > http://www.gimp.org | IRC: irc://irc.gimp.org/gimp Wiki > http://wiki.gimp.org | .de: http://gimpforum.de Plug-ins > http://registry.gimp.org | ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] [GSoC] Mentors, rank the proposals
Hi, multiple important deadlines for Google Summer of Code happen on April 21: 0700 UTC : all mentors have to be signed up and assigned to the proposal(s) they want to handle 1700 UTC : ranking has to be finished An IRC meeting to resolve any double accepts for students will follow after that. So it is important that you clearly mark your favorite proposals by giving them a positive score. Regards, Michael -- GIMP > http://www.gimp.org | IRC: irc://irc.gimp.org/gimp Wiki > http://wiki.gimp.org | .de: http://gimpforum.de Plug-ins > http://registry.gimp.org | ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] User Friendly Plug-In Browser
On Mon, 2010-04-12 at 23:20 +0200, Avgoustinos Kadis wrote: > Thanks Sven, very important to know that! > How feasible are these options? > > 1. Randomly pick a value for each parameter. From what you said (that > it depends a lot on the parameters) this wont give us the best results > but at least we will have a preview. > > 2. Modify PDB so it can store default parameters and enter their > values in the plug-ins (maintained in one place only)? The latter is the only reasonable solution and it has been on the TODO for quite a while already. But IMO it goes way beyond the scope of a GSoC project. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Windows snapshot of 2.7 - possible?
On Tue, Apr 13, 2010 at 11:42 AM, Cédric Gémy wrote: >> You can find my build here: >> http://www.mediafire.com/file/hjwqw1kym4g/gimp-win-08-04-2010.7z >> Read the README_FIRST!!!.txt file before using this build (seriously, read >> it!). > > > Installing this one on Linux via Wine result In Text troubles. File Menu > entry is just as big as half of my screen, so that anything can be done. > Did someone get the same ? Why are you installing windows version of gimp on Linux? Sounds slightly stupid, considering its quite simple to build gimp on most versions of Linux. -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Windows snapshot of 2.7 - possible?
> You can find my build here: > http://www.mediafire.com/file/hjwqw1kym4g/gimp-win-08-04-2010.7z > Read the README_FIRST!!!.txt file before using this build (seriously, read > it!). Installing this one on Linux via Wine result In Text troubles. File Menu entry is just as big as half of my screen, so that anything can be done. Did someone get the same ? pygmee ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
