Re: [Gimp-user] Cpu usage and speed
Sven Neumann wrote: Hi, Michele Petrazzo [EMAIL PROTECTED] writes: On the same machine with photoshop, a preview of a curves tool spend only 4-5 seconds, but when press the OK button, it spend about the same time of gimp. As you already guessed, the preview of the color manipulation tools in GIMP isn't really a preview. It's the full thing and no attempt is made to for example restrict the effect to the visible area or even render it on a scaled-down version of the image. That's a known problem and should not be too difficult to improve. Just needs a motivated hacker who has some spare time. Do you volunteer? I am not a C/C++ programmer, I know only python, and I'm following the development of three sourceforge projects. I hope that there are other volunteer person that want to help the community. Sven Michele ___ Gimp-user mailing list Gimp-user@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] Adjusting selection
After selecting a region with the box selection tool, is there a way to fine tune the selection? In Photoshop, I use the "Select/Transform Selection" tool, and it gives me transform handles on the edges and corners of the selection.
Re: [Gimp-user] Cpu usage and speed - test results
Dana Sibera wrote: For GIMP - Version 2.2 on OSX, Tile Cache set to 400, 500, 600, 800 and 1400MB - all had the same results within a second or two. Any less than 400MB tile cache with this image and the visible changes in both preview and the final 'OK' would hit a wall part way through the change and slow down drastically, with times for each change doubling or more. Undo levels set to 1 and Maximum undo memory set to 128MB. GIMP shows the image taking 230MB at the bottom of the image window. Adjust curves - 15 seconds to complete 'preview' across the entire image on each every movement of the curve. It takes the same 15 seconds to 'apply' a change across the image if preview is off, after pressing 'OK'. Color Balance - 16 seconds to preview across the entire image on each movement of an RGB/CMY slider. Stretches to 36 seconds on each preview if Preserve Luminosity is turned on. Same 16/37 seconds to complete the whole image if preview is turned off, after pressing 'OK' . Levels - 16 seconds to preview across the entire image on each movement of the black/white/grey points, 16 seconds total to complete the whole image if preview is turned off, after pressing 'OK'. Turning previews off makes things quicker by only requiring one 15ish-second pass over the image - however it also makes each tool effectively useless when trying to adjust by sight. A bit like working around having a dirty windscreen by driving with your eyes closed. -- Photoshop 8.0 - Percent memory used set to 92% of available = 500MB on a fresh boot. Scratch disk is boot disk, and 'cache levels' left at 4. Adjust curves - preview is instant, well under a second across the entire image area on each movement of the curve. After clicking OK takes one second to complete a curves change on the whole image. With preview off, also takes one full second to complete a curves change on the whole image. Color Balance - preview is instant, perhaps 2-3 changes per second are reflected in the preview when moving the slider, and well under a second to complete the color balance after pressing OK. Same sub-second time when preview is off. Levels - preview seems a bit faster than with color balance, almost smooth realtime transitions reflected in the preview. Pressing OK gives an instant change of levels across the image regardless of preview. - I also have an athlon 2600+ (1912MHz) running Debian and GIMP 2.2 that I had a chance to use earlier while it had 512MB RAM in it, and though I didn't get to use this exact test image, I tested with another I was working on at the time and had similar results to the 1GHz G4, just scaled in speed. That is - a color change in gimp that took 30 seconds on the 1GHz G4 would take say 18 seconds in gimp on the Athlon 2GHz. In order to get past any background processing photoshop may have been doing, I also tried adjusting the curve in the curves dialog then quickly hit OK - this came out taking the same time as if I moved the curve and waited 10 seconds before clicking OK. Closing the image immediately afterwards was also instant, so there seemed to be no tricky background processing happening over the whole image area. I hope this helps show the large image size type problems. I wouldn't expect two apps to give identical times for every process, but there's some big inefficiency in GIMP here that's making it more than ten times slower - especially considering that Photoshop on a Powermac 7300/200 (200MHz PPC604e with 140MB RAM) is not much different to GIMP on a 2GHz Athlon with 512MB for these particular operations on images at this particular size. (That's not a glib exaggeration either. Color Balance across the same panorama while I was constructing it on the 604e took about 10 seconds. It is running Photoshop 5.5). I stress these particular operations on images at this particular size because in other areas GIMP's speed is fine, however I'm often working on images at this size or larger. Of course, if there are some memory/cache settings I'm missing out on to get GIMP down to the sub-second adjustments on images of this size, please tell me!. dana I just tried the file on my computer and I didn't find GIMP to be that slow. Color balance was the slowest with you image at ~8 sec for a preview. All others were under 2 sec. I am running Fedora Core 1 with 2gig ram, ATI 7500 graphics card and Intel 2.5G I am wondering if you are having issues with your graphics card and it's refresh on Linux. I was running SETI at home. I had GIMP 1.x and 2.x open at the same time with the same image. There were also other applications opened as well. I would have to try the image on my home computer which is much faster to see if there is any change. I do know that memory makes a big difference as I have just upgraded my memory from 512 to 2gig because of working on large files as well. Processing times have dropped drastically from hours to
RE: [Gimp-user] Adjusting selection
Thanks for that. When manually dragging an edge, is there a way to constrain it on an axis? In Photoshop you hold shift and your cursor motion will be restricted to the initial axis you start moving your mouse on. -Original Message- From: Stuart White [mailto:[EMAIL PROTECTED] Sent: Monday, February 28, 2005 11:13 AM To: Kalle Ounapuu Cc: gimp-user@lists.xcf.berkeley.edu Subject: Re: [Gimp-user] Adjusting selection Select the Scale the layer or selection tool (Shift+T) in the toolbox, then click the Transform Selection button (the pink square) in the tool options. This allows you to scale a selection using handles on the corners of the selection. On Mon, 28 Feb 2005 10:05:10 -0500, Kalle Ounapuu [EMAIL PROTECTED] wrote: After selecting a region with the box selection tool, is there a way to fine tune the selection? In Photoshop, I use the Select/Transform Selection tool, and it gives me transform handles on the edges and corners of the selection. ___ Gimp-user mailing list Gimp-user@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Adjusting selection
When manually dragging an edge, is there a way to constrain it on an axis? In Photoshop you hold shift and your cursor motion will be restricted to the initial axis you start moving your mouse on. A short test reveals: pressing ctrl limits the movement to left-right, pressing alt limits the movement to top-down Andreas ___ Gimp-user mailing list Gimp-user@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Adjusting selection
Kalle Ounapuu wrote: When manually dragging an edge, is there a way to constrain it on an axis? In Photoshop you hold shift and your cursor motion will be restricted to the initial axis you start moving your mouse on. Ctrl keeps the height, Alt the width, and both simultaneously the aspect ratio. This is also available in the scale tool options. HTH, Michael -- The 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-user mailing list Gimp-user@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] Gimp/Graphire 3 Flakiness
I have also been experiencing problems with Gimp 2.2.4 and the Wacom Graphire 3 that match exactly what a previous poster experienced. 1) At a certain point, not long after I start using the tablet in Gimp, the cursor stops changing from, say, the paint cursor to the default pointer and just stays as the paint cursor, even outside the canvas. This means that I cannot access the palettes, the windows, or the rest of the desktop. Using ALT-TAB stops working, too. 2) Once this happens, watching which device is active, I can switch from Stylus to Eraser without a problem, but it won't switch back to the Core Device once I start moving the mouse. The cursor still responds and moves around, but the active device stays locked where it was, either as Stylus or Eraser. 3) If I keep this up for a while, the cursor stops interacting with the canvas completely, so I can no longer paint or do anything. 4) Eventually, the pointer regains its ability to switch back to a default pointer outside the template, and I'm able to quit Gimp. I've tried this in Gimp 2.2.4 and Gimp 2.0, with the same problem reappearing. The thing is, I used to have this working with 2.0, no problems at all. My XFree86 setup is fine, I was once able to do everything without a problem. The only differences I can think of are that: a) I've upgraded to the 2.6.10 kernel. No difference with just the stock drivers or with the linuxwacom drivers added to it. b) I'm using garnome, version 2.8.2.1. I THINK that it was working after I had garnome installed, but I'm not 100%. What I definitely have in common with the previous poster is that I'm using kernel 2.6.10. Has anyone else with a Wacom tablet and 2.6.10 installed run into this issue? I'm going to switch back to 2.6.1 and see what happens. -Mike ___ Gimp-user mailing list Gimp-user@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] Gimp/Graphire 3 Flakiness...Aha!
Okay, I just rebooted into kernel 2.6.1, and the problem is gone! The difference, as far I can tell, is either something strictly with the kernel versions or the fact that the 2.6.1 wacom module I built completely from the linuxwacom sources and the 2.6.10 modules were originally built from the included code from the kernel tarball (though later replaced in 2.6.10 by the linuxwacom modules, to no effect). Anyone have an idea on what might've caused something like that to happen? I'm not even sure what subsystem was acting up there. I assume something when haywire with the kernel modules, but it could easily also have been the X server drivers, too, or some combination thereof. Cazy. -Mike -- ___ Gimp-user mailing list Gimp-user@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
