GIMP performance
This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
GIMP performance | Andrea Olivotto | 01 Apr 17:27 |
GIMP performance | David Gowers | 02 Apr 01:01 |
49D45F4A.7010206@andreaoliv... | 07 Oct 20:27 | |
GIMP performance | David Gowers | 02 Apr 09:39 |
GIMP performance | Rob Antonishen | 02 Apr 11:48 |
GIMP performance
Hi all,
I'm a photo amateur, and I do like gimp. I posted some time ago some hints to make gimp more useful for photo retouch, and some have been done in 2.6.
At this time, gimp seems to me that need speed. It is far away from Photoshop and other commercial softwares, and things are getting worse using GEGL (as I tried in 2.7 development program): I checked in Windows and in Ubuntu 8.10, AMD 3000+/64 plus 1GB RAM.
When I use curves, preview is redrawed very slowly, I can see the "blocks" under updating.
I know that GIMP is open source, and developers don't want to compete with Photoshop (or Photoshop Express, or Paint Shop PRO, ...), but this is the real world in photo retouching. I just want to be honest, end to emphasize this issue.
Many thanks a lot if you'll do something to increase performances.
GIMP performance
Hello Andrea!
On Thu, Apr 2, 2009 at 1:57 AM, Andrea Olivotto wrote:
Hi all,
I'm a photo amateur, and I do like gimp. I posted some time ago some hints to make gimp more useful for photo retouch, and some have been done in 2.6.
At this time, gimp seems to me that need speed. It is far away from Photoshop and other commercial softwares, and things are getting worse using GEGL (as I tried in 2.7 development program): I checked in Windows and in Ubuntu 8.10, AMD 3000+/64 plus 1GB RAM.
GEGL *is* what we are doing to increase performance. It's true that currently GEGL is much slower, however, the previous GIMP architecture was incapable of the optimizations and storage strategies required for particularly large images, and also was very limited (no support for higher bit depths, no automatic colorspace conversion so that any image can be used as input to any operation). Chances are that GEGL is already better at managing graphics than GIMP ever was. It still needs quite a bit of work, but in my understanding, the slowness is caused by the way GEGL is being used by GIMP. It could be a lot better; and by the time GEGL is really well integrated, we could reasonably expect far better responsiveness and comparable real speed, with the possibility of vast speed increases for certain kinds of filter/plugin.
When I use curves, preview is redrawed very slowly, I can see the "blocks" under updating.
Things like Curves could certainly be done much quicker. A lot of conversion goes on during the calculation; but really, for applying to 8bit and 16-bit pictures, a lookup table should be all that is needed, with only a very little amount of conversion work that happens as soon as the curve is adjusted. This means that currently, GIMP is making GEGL do much more work than it needs to really do. These issues will be settled as GIMP developers learn more about using GEGL, GEGL matures, and as GEGL becomes better integrated in GIMP.
I know that GIMP is open source, and developers don't want to compete with Photoshop (or Photoshop Express, or Paint Shop PRO, ...), but this is the real world in photo retouching. I just want to be honest, end to emphasize this issue.
I hope I've addressed your concerns.
David
GIMP performance
Hello Andrea,
On Thu, Apr 2, 2009 at 5:16 PM, Andrea Olivotto wrote:
David Gowers wrote:
....
I hope I've addressed your concerns.David
Thanks a lot for your fast reply and your answers!
I'm happy to hear that GEGL is going to be the solution for responsiveness.
Another request for you: I'm a firmware programmer, and I know C programming quite well, and some time ago I tried to compile GIMP in Windows enviroment, but I can't find a complete tutorial, relative to 2.6 tree (and now 2.7).
I think it would be very very useful, attracting many more developers than now, where a new programmer have to spend days and days searchinf for incomplete info on Internet and asking to GIMP developers.
Is
http://wiki.gimp.org/gimp/HowToCompileGimp/MicrosoftWindows
Unsatisfactory or incomplete? Is developer.gimp.org missing a link to it? (I haven't checked)
Ind maybe people like me, with some programming skills and with strong photography needs, may improve GIMP, even just asking some new features or tools.
If you have ideas that are related more to UI than technology, I encourage you to submit them to http://gimp-brainstorm.blogspot.com (submission instructions can be found there)
David
GIMP performance
On Thu, Apr 2, 2009 at 3:39 AM, David Gowers wrote:
Hello Andrea,
On Thu, Apr 2, 2009 at 5:16 PM, Andrea Olivotto
Another request for you: I'm a firmware programmer, and I know C programming quite well, and some time ago I tried to compile GIMP in Windows enviroment, but I can't find a complete tutorial, relative to 2.6 tree (and now 2.7).
Is
http://wiki.gimp.org/gimp/HowToCompileGimp/MicrosoftWindows
I just compiled under XP following the wiki last weekend and had to
modify two lines of the
http://wiki.gimp.org/gimp/CompileGimpAtWindowsShellScript file in
order to get it working.
After a quick email with Carl who suggested:
A better option is maybe try to modify a line both within the download_and_zextract function and the download and tbz2extract function, from this:
wget $WGETFLAGS "$PACK_LOCATION/$PACKAGE.zip" 2>&1 | grep -v -i "^sys\(tem_\)\?wgetrc";
to this
wget $WGETFLAGS "$PACK_LOCATION/$PACKAGE.zip"
-Rob A>