Re: Performance of Gimp vs. photoshop for large images
hi, this is linux specific, and wrong. It is very sensible of the kernel to swap out data that is likely not to be used for other apps like gimp. 'top' - thats a command featured in almost all un*x-style OS's Any non-obsolete linux kernel version can be expected to swap out 6-10mb even shortly after a boot, and even if memory is available. ??? I'd like to know what you're doing.this is my report right at this point in time. [me@host 10]# free total used free sharedbuffers cached Mem:128200 100544 27656 21772 39980 21432 -/+ buffers/cache: 39132 89068 Swap: 120452 0 120452 [me@host 11]# uptime 9:18am up 7 days, 18:49, 4 users, load average: 3.00, 3.00, 2.98 Alan
Re: Performance of Gimp vs. photoshop for large images
hi, BTW, Unix "trashing" is rare to find, or at least to heard. When it moves data to disk it does not sound like Windows Machine Gun Swap Routine (TM), ;-) easiest way to see when you're swapping is to go to a shell and type 'free' - you shouldnt see the swap number used at all if you want best performance. Though some apps may require huge chunks but dont continually hit swap alan
Re: Performance of Gimp vs. photoshop for large images
On Tue, Jun 06, 2000 at 09:55:50AM +0100, Alan Buxey [EMAIL PROTECTED] wrote: can I see some references for these values? Seems that number is just climbing all the time. can the human eye distinguish more than 26-bit? Even at 4kx3k, you've only got 12million pixels that can be of different colours. This is "dynamic range" vs. "absolute number of colours". The human perception varies a lot accoridng to the environment, and, while the human eye has difficulties with a large number of different colours, it is very sensible to banding, and different media (film) must support a very large dynamic range. Digital effects filters also eat a lot of resolution. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Performance of Gimp vs. photoshop for large images
On Tue, Jun 06, 2000 at 09:50:08AM +0100, Alan Buxey [EMAIL PROTECTED] wrote: BTW, Unix "trashing" is rare to find, or at least to heard. When it moves data to disk it does not sound like Windows Machine Gun Swap Routine (TM), ;-) easiest way to see when you're swapping is to go to a shell and type 'free' this is linux specific, and wrong. It is very sensible of the kernel to swap out data that is likely not to be used for other apps like gimp. you shouldnt see the swap number used at all if you want best performance. Any non-obsolete linux kernel version can be expected to swap out 6-10mb even shortly after a boot, and even if memory is available. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Performance of Gimp vs. photoshop for large images
thats odd. that size should be fine. i work in film res all the time (4kx3k) at 32bpp (yes, i know film should be done at 48 or 64 bpp to prevent banding, i only work this res for testing) can I see some references for these values? Seems that number is just climbing all the time. can the human eye distinguish more than 26-bit? Even at 4kx3k, you've only got 12million pixels that can be of different colours. It is for retouching purpouses. When you operate with computers, you have quantization problems, if you use 8 bit per channel, in a few steps you will discover that color that were different now are the same, or that due rounding you get the wrong colors. (How do you see a 64bit picture on the monitor? ;-) ) You do not. It is just for internal ops. GSR
Performance of Gimp vs. photoshop for large images
Hello all, I've been a linux user for some 5-6 years or so, and do my best to use linux for everything. However my hobby is photography and digital imaging, which seems to be about to ring the death knell for my desktop linux box due to performance problems. The images I edit are usually around the 3500x2800 or so mark at 30 bits depth. I've recently tried Gimp on such images and have found it to be lacking to put it mildly. It wouldn't even load 30-bit TIFF files, I had to truncate them to 24-bit, so losing three quarters of the range of each colour component, not much of a problem until you start messing around with levels, contrast, and other such things --- 1024 levels gives me much more headroom than 256! Being as the scanner already loses masses of dynamics from a scanned transparency, losing a further quarter is not something I want to do. The second problem is speed. The first thing I do when I scan a photo is to mess with the levels, unfortunately with the preview button turned on, as soon as I take my finger off the mouse button after dragging a marker point I have to wait for many minutes while gimp redraws the image tile by tile, taking 5 or so seconds for each tile. During this redraw the processor is at 100% on the gimp process, the disc is not thrashing, and there is little or no CPU being spent on system processes so it's not a problem with RAM. Preview mode in other similar operations (e.g. gamma curve changes) is similarly slow, while photoshop on the same hardware (PPro200 with 64 megs of RAM) running under winblows is extremely quick, taking less than 5 seconds to do the whole preview. Photoshop then cranks away at the image for about 20 seconds or so once you've finished the preview, but not the 10 minutes or so that gimp takes. I'm trying to find out what's going on here, am I doing something wrong, or is there a fundamental performance problem with the levels tool and other such tools? If there is, does anyone know of any alternative programs that can preview contrast, gamma changes and levels changes on large images in near-realtime? Please don't unhelpfully suggest as someone else in a newsgroup did, that I break out emacs and start to code, I'm no coder, I'm a photographer, and not very good at that either ;-) Thanks for your time.
Re: Performance of Gimp vs. photoshop for large images
What have you set your tile cache size to in gimp perfs? Sounds like a simple misconfiguration. -- Jon Winters http://www.obscurasite.com/ "Everybody loves the GIMP!" http://www.gimp.org/
Re: Performance of Gimp vs. photoshop for large images
It's set to either 15 megs or 10 megs. However the disc is not being thrashed, throughout the redraw all the CPU time is being eaten by gimp, i.e. it's processor-bound, not I/O bound, if it was a cache issue then I'd expect large amounts of disc I/O but I'm not seeing that. Thanks for your help. On Mon, 5 Jun 2000, Jon Winters wrote: What have you set your tile cache size to in gimp perfs? Sounds like a simple misconfiguration. -- Jon Winters http://www.obscurasite.com/ "Everybody loves the GIMP!" http://www.gimp.org/
Re: Performance of Gimp vs. photoshop for large images
It's set to either 15 megs or 10 megs. However the disc is not being Too low, enough to edit a logo, but not for big images. 3500 * 2800 * 3 bytes = 29.4E6 bytes, as you see it is a lot more than 15MB (near two times), so Gimp moves data to disk as soon as you load the image. I have used Gimp with images as big as yours, multiple layers and it was fast, reason? I set the cache size to 128MB or more (the machine had 256), and I hope to fine tune it as soon as I have time to test it more (but I guess that 128 - 192 will be good, after all, my old machines had 64MB in the best case, and I had done medium works with them). thrashed, throughout the redraw all the CPU time is being eaten by gimp, i.e. it's processor-bound, not I/O bound, if it was a cache issue then I'd expect large amounts of disc I/O but I'm not seeing that. How did you meassure the CPU and IO loads? I think your meassurements are not correct. Unix system internals are really strange, I always remember the famous discussion in GNOME list about Shared memory, Resident, etc. It seems most people meassure wrong. BTW, Unix "trashing" is rare to find, or at least to heard. When it moves data to disk it does not sound like Windows Machine Gun Swap Routine (TM), just clickclick. Watch the LED, it should be always ON (or look like it is ON, you know that eyes are not perfect), but the disk may not make loud or rare sounds. At least under normal conditions (a 1GB DB in a 64MB computer is not normal). ;] Conclusion: raise the limit and complain again if Gimp is not fast. GSR
