Hi,

"Eric Pierce" writes:

I'm working with a relatively large RGB image (4368 x 3384px / 2MB file size / status bar says 199MB on load). Once I begin editing the image, the memory usage quickly gets up around 600MB and up, and my system comes to a crawl as it goes to the hard disk for memory space.

I'm wondering if my Environment settings are screwed up. Min. number of undo lvl: 25
Max. undo memory: 50 mb
Tile Cache Size: 96 mb
Conservative Mem. usage: checked

I'm running: Windows 2000 392MB ram
1 GHz cpu

You should consider to increase the tile cache size then. Setting it to 256MB would certainly improve things. Getting more RAM and increasing it further will definitely help more.

On PotatoShop (forced to used at gunpoint), there are no problems editing this image or other large images.

Photoshop handles large images better than GIMP. That's a known fact and it's not trivial to improve.

Sven

Hi,

Sven Neumann wrote:

On PotatoShop (forced to used at gunpoint), there are no problems editing this image or other large images.

Photoshop handles large images better than GIMP. That's a known fact and it's not trivial to improve.

How, exactly? I've heard this too, but I have no clear idea how they do so - do they have a similar caching system, and just make better decisions about what to cache and when? Or do they use OS specific features to reduce read times for caching operations?

Or perhaps something completely different?

Adding -devel as a CC, since this is really a developers issue too.

Cheers,
Dave.

On Thursday 22 April 2004 16:42, David Neary wrote:

Hi,

Sven Neumann wrote:

On PotatoShop (forced to used at gunpoint), there are no problems editing this image or other large images.

Photoshop handles large images better than GIMP. That's a known fact and it's not trivial to improve.

How, exactly? I've heard this too, but I have no clear idea how they do so - do they have a similar caching system, and just make better decisions about what to cache and when? Or do they use OS specific features to reduce read times for caching operations?

Or perhaps something completely different?

/me thinks that, not worrying about photoshop, one way to optmize is to paint on the scaled down image in real time, and perform the real operation on the full size image in the background.

If not the paint-tools (that would take a significant amount of code change to implement), at least the preview for the color-manipulation tools (curves, HSV, etc) , should do something of the kind.

Adding -devel as a CC, since this is really a developers issue too.

Cheers,
Dave.

dneary@free.fr (2004-04-22 at 2142.26 +0200):

On PotatoShop (forced to used at gunpoint), there are no problems editing this image or other large images.

Photoshop handles large images better than GIMP. That's a known fact and it's not trivial to improve.

How, exactly? I've heard this too, but I have no clear idea how they do so - do they have a similar caching system, and just make better decisions about what to cache and when? Or do they use OS specific features to reduce read times for caching operations? Or perhaps something completely different?

One thing that GIMP could do is top to bottom composing, if the blend modes allow it. It will mean that calculations will never be worthless and that only contributing tiles will have to be accessed. That should speed up things and reduce memory usage in some cases.

GSR

Photoshop handles large images better than GIMP. That's a known fact and it's not trivial to improve.

Ummm, well that known fact isn't completely true. In actual fact, Photoshop will *not* handle many of the large images that we work with at all, whereas the GIMP will do so with no problem. Photoshop has an inherent 32K maximum pixel limitation in both height and width that the GIMP is not saddled with.

Photoshop may process reasonably large images somewhat faster than the GIMP can, but the GIMP can handle huge images that make even the latest versions of Photoshop roll over and croak.

s/KAM

Kevin Myers (WHMyers@cableone.net) wrote:

Photoshop handles large images better than GIMP. That's a known fact and it's not trivial to improve.

Ummm, well that known fact isn't completely true. In actual fact, Photoshop will *not* handle many of the large images that we work with at all, whereas the GIMP will do so with no problem.

Will the wonders never cease?

Thanks, it is great to hear that :-)

Bye, Simon

Kevin Myers wrote:

Ummm, well that known fact isn't completely true. In actual fact, Photoshop will *not* handle many of the large images that we work with at all, whereas the GIMP will do so with no problem. Photoshop has an inherent 32K maximum pixel limitation in both height and width that the GIMP is not saddled with.

Photoshop may process reasonably large images somewhat faster than the GIMP can, but the GIMP can handle huge images that make even the latest versions of Photoshop roll over and croak.

How huge is huge, Kevin?

Over the past two days, I have edited two TIFF images, 12500 x 7800 pixels, greyscale, using Photoshop 8. It was business as usual (meaning, fast and stable as usual). Loading and saving took as long as I expected for a file of this size (95MB).

Prompted by this thread, I tired one of these files in Gimp 2. What a looooong wait for even the simplest tasks, such as zooming in and out. I then tried my trusty old Gimp 1.2. It was somewhat better than 2, but very, very slow. Pulling menu's down took tens of seconds. No, using Gimp, on Win 2k, for a file this size, is just not practical. I expect it will go better on my Linux box at home, but even if it was two times faster, it would still be unpractical.

Which is why I would like to know how huge huge is, on what hardware, running which OS, which version(s) of Gimp, and processing what tasks.

rgds Jaco

On Thu, Apr 22, 2004 at 07:11:21PM +0200, Sven Neumann wrote:

Photoshop handles large images better than GIMP. That's a known fact and it's not trivial to improve.

it depends on what you count.

you can run TheGIMP on machines that you could not even dream of running photoshop on.

i swear. i am on a 450MHz or whatever right now. this machine could barely keep up with my 486 whatever. especially big images.

carol

How huge is huge, Kevin?

Over the past two days, I have edited two TIFF images, 12500 x 7800 pixels, greyscale, using Photoshop 8. It was business as usual (meaning, fast and stable as usual). Loading and saving took as long as I expected for a file of this size (95MB).

Prompted by this thread, I tired one of these files in Gimp 2. What a looooong wait for even the simplest tasks, such as zooming in and out. I then tried my trusty old Gimp 1.2. It was somewhat better than 2, but very, very slow. Pulling menu's down took tens of seconds. No, using Gimp, on Win 2k, for a file this size, is just not practical. I expect it will go better on my Linux box at home, but even if it was two times faster, it would still be unpractical.

Which is why I would like to know how huge huge is, on what hardware, running which OS, which version(s) of Gimp, and processing what tasks.

Hi Jaco,

As mentioned in my previous message, Photoshop's limit is 32K maximum pixels in either dimension. Your image did not exceed this limit in either dimension. We typically work with images that are up to several hundred thousand pixels in one dimension, by 2 or 3 thousand pixels in the other dimension. Thus we almost always exceed the Photoshop limit.

I presently run GIMP 1.2.4 on a 2.4 GHz P4 based system under Windows 2000, with 3GB of RAM installed (only 2GB of which can be used by the GIMP). We usually work with 8 bit grayscale images, and as described above our typical image sizes are on the order of 200 megapixels. As you mentioned, your image was only 98 megapixels. On my system, I have no problems with menu delays at all (far less than one second response), and initial image loading speed is reasonable, typically on the order of 5 or ten seconds.

Based on your description, I suspect that either Photoshop's memory usage may be somewhat more efficient than the GIMP, or possibly your Tile Cache Size is set too small. Either of those issues could result in extensive page thrashing of portions of the GIMP and your image to and from disk. On my system, the tile cache size is set to 1280MB. How much physical RAM do you have, and what is your Tile Cache Size set to?

s/KAM

I presently run GIMP 1.2.4 on a 2.4 GHz P4 based system under Windows

2000,

with 3GB of RAM installed (only 2GB of which can be used by the GIMP). We usually work with 8 bit grayscale images, and as described above our

typical

image sizes are on the order of 200 megapixels. As you mentioned, your image was only 98 megapixels. On my system, I have no problems with menu delays at all (far less than one second response), and initial image

loading

speed is reasonable, typically on the order of 5 or ten seconds.

I should also mention that zooming in/out on our multi-hundred megapixel images is very fast, almost instantaneous. Some of the more complex full image manipulations take a while, but that is to be expected, and the speeds are still not unreasonable in most cases.

s/KAM

Based on your description, I suspect that either Photoshop's memory usage may be somewhat more efficient than the GIMP, or possibly your Tile Cache Size is set too small. Either of those issues could result in extensive page thrashing of portions of the GIMP and your image to and from disk.

On

my system, the tile cache size is set to 1280MB. How much physical RAM do you have, and what is your Tile Cache Size set to?

Also, what other memory hog applications do you have running at the same time? For example, you didn't have the same image already open in Photoshop while you were testing the GIMP on it did you? If so, that could have easily pushed the required memory beyond your installed RAM size, forcing extensive page swapping to/from disk.

s/KAM

Kevin Myers wrote:

As mentioned in my previous message, Photoshop's limit is 32K maximum pixels in either dimension. Your image did not exceed this limit in either dimension. We typically work with images that are up to several hundred thousand pixels in one dimension, by 2 or 3 thousand pixels in the other dimension. Thus we almost always exceed the Photoshop limit.

I presently run GIMP 1.2.4 on a 2.4 GHz P4 based system under Windows 2000, with 3GB of RAM installed (only 2GB of which can be used by the GIMP). We usually work with 8 bit grayscale images, and as described above our typical image sizes are on the order of 200 megapixels. As you mentioned, your image was only 98 megapixels. On my system, I have no problems with menu delays at all (far less than one second response), and initial image loading speed is reasonable, typically on the order of 5 or ten seconds.

Strictly speaking PS 8 (CS) can go larger in pixel dimensions (if you use the new .PSB file format) but there are other operational issues that still make this awkward.

But for me it's not the pixel dimensions that define a large image. As a photographer I work with full RGB images, not piddly little greyscale files ;-).

I have two systems here. Apples aren't quite apples, but it's a vaguely interesting comparison anyway:

System A is a 1.6GHz P4 with 512MB RAM, running Gimp 1.2 on FreeBSD. Working with large files (e.g. only 6400x9600 24-bit pixels) can be painful, especially if I decide to add layers. I've done an A0-sized poster on this machine and it was ridiculous. I got the job done eventually, but it was VERY painful.

System B is a PowerMac G4/450 with 1GB RAM. This machine is old and slow by Apple standards. It's running Photoshop CS on MacOS X 1.3. It's a pleasure to use in comparison to System A. The speed difference (and a few other advantages) has made it worthwhile to get used to the different (Photoshop) interface. I regularly work with 48-bit image files, at large print sizes, and with at least 5 or 6 layers. The filesize when saved as a layered uncompressed TIFF is often larger than will fit on a CD. As the files get bigger the processing time increases, but it feels like a simple geometric progression based on the CPU/megapixel relationship, not an exponential/whatever progression based on RAM shortfalls.

Sure the Mac has more RAM, but I've tuned Photoshop's RAM allocation back to 256MB as an experiment and it was still faster than the Gimp. I normally have 576MB allocated to PS.

In the Gimp there seems to be no upper bound to its RAM use. No matter what size you set the tile cache to (right nowe I have it set at 320M) and the number of undo levels, its memory footprint seems to keep increasing, and when it gets painful it's typically paging (i.e. it's not managing its own scratch space like Photoshop does - the OS is paging it in and out). Shutting down other applications does improve things for a short while, but very soon that extra memory is chewed up and performance goes down the tube again. It seems that often the Gimp's active memory footprint is very large, and information is being paged out that was only just paged in.

When the Gimp's performance drops off it's saturating the disks with VM paging, and the whole machine is painful to use. When Photoshop's performance drops off it's mainly just hogging CPU and the rest of the machine is vaguely usable.

I would say that on machines with equivalent RAM sizes Photoshop is a better performer (on the images I deal with at least) but I should load Gimp 2 onto the Mac for a better comparison.

Using Photoshop 7 on my wife's XP machine which is a 1.8GHz version of my System A seems OK, but I haven't done a lot of work with it as she keeps wanting to use it...
__
David

Hi Kevin

Kevin Myers wrote:

As mentioned in my previous message, Photoshop's limit is 32K maximum pixels in either dimension. Your image did not exceed this limit in either dimension. We typically work with images that are up to several hundred thousand pixels in one dimension, by 2 or 3 thousand pixels in the other dimension. Thus we almost always exceed the Photoshop limit.

Point taken :-)

I presently run GIMP 1.2.4 on a 2.4 GHz P4 based system under Windows 2000, with 3GB of RAM installed (only 2GB of which can be used by the GIMP). We usually work with 8 bit grayscale images, and as described above our typical image sizes are on the order of 200 megapixels. As you mentioned, your image was only 98 megapixels. On my system, I have no problems with menu delays at all (far less than one second response), and initial image loading speed is reasonable, typically on the order of 5 or ten seconds.

Hm, mine is Gimp 1.2.5 on a 1.8GHz P4, W2K, but just 256M RAM. The Tile Cache is set to 128M. In the case I described, I did have PS open at first, but no images loaded. After that, I closed PS and Framemaker and tried again - dead slow.

Based on your description, I suspect that either Photoshop's memory usage may be somewhat more efficient than the GIMP, or possibly your Tile Cache Size is set too small. Either of those issues could result in extensive page thrashing of portions of the GIMP and your image to and from disk. On my system, the tile cache size is set to 1280MB. How much physical RAM do you have, and what is your Tile Cache Size set to?

I would think that a 128M tile would be about right for PC... but I'll try suggestions :-) Having read David's posting as well, I suspect that The Gimp's memory management could be fine-tuned somewhat - at least as far as Windows is concerned. I will repeat today's experiment on my Linux box tonight.

rgds
J

Kevin Myers wrote:

As mentioned in my previous message, Photoshop's limit is 32K maximum

pixels

in either dimension. Your image did not exceed this limit in either dimension. We typically work with images that are up to several hundred thousand pixels in one dimension, by 2 or 3 thousand pixels in the other dimension. Thus we almost always exceed the Photoshop limit.

I presently run GIMP 1.2.4 on a 2.4 GHz P4 based system under Windows

2000,

with 3GB of RAM installed (only 2GB of which can be used by the GIMP).

We

usually work with 8 bit grayscale images, and as described above our

typical

image sizes are on the order of 200 megapixels. As you mentioned, your image was only 98 megapixels. On my system, I have no problems with

menu

delays at all (far less than one second response), and initial image

loading

speed is reasonable, typically on the order of 5 or ten seconds.

Strictly speaking PS 8 (CS) can go larger in pixel dimensions (if you use the new .PSB file format) but there are other operational issues that still make this awkward.

Perhaps that is true, however I got it straight from PS tech support (who supposedly passed it on from PS development) that PS 8 still has the underlying 32K pixel per dimension limit. Of course it might not be the first time that tech support was wrong about something...

But for me it's not the pixel dimensions that define a large image. As a photographer I work with full RGB images, not piddly little greyscale files ;-).

Right, which of course multiplies your memory usage by a factor of 3 to 5 (I don't remember right now exactly how many bytes of memory the GIMP uses for a RGB image, probably 4, one each for red, green, blue, and alpha channels).

I have two systems here. Apples aren't quite apples, but it's a vaguely interesting comparison anyway:

System A is a 1.6GHz P4 with 512MB RAM, running Gimp 1.2 on FreeBSD. Working with large files (e.g. only 6400x9600 24-bit pixels) can be painful, especially if I decide to add layers.

In which case your GIMP memory usage might be multiplied times the number of layers. So, your 60 megapixel image starts out using 240 megabytes of RAM, then you add another 240 MB layer and including OS RAM utilization, you've probably now exceeded the 512MB of RAM installed on your machine, hence page thrashing...

I can't say if PS does a better job of managing image memory utilization than the GIMP. All I do know is that we often work with E size and larger RGB images at 300 dpi (13200 x 10200 = 135 megapixels) in addition to the grayscale images that I mentioned previously, and those seem to work fine for us using GIMP 1.2.4 under Win 2K with a 1280MB tile cache. However, most of our image manipulations are fairly simple (scaling, rotation, normalizing, sharpening, brightness, contrast, color reduction, etc.). We don't do much work with more than two layers.

s/KAM

On Fri, Apr 23, 2004 at 11:23:32AM +1000, David Burren wrote:

Kevin Myers wrote:

Using Photoshop 7 on my wife's XP machine which is a 1.8GHz version of my System A seems OK, but I haven't done a lot of work with it as she keeps wanting to use it...

i am curious. do you think that if the adobe geniuses could make their software compile on linux, if it would slow it down.

i am not sure where gimp is losing this "race" of yours but the fact that i can run gimp on linux and can not run photoshop (any flavor or version) to compare gives photoshop some weird edge.

is the very fact that the linux community shared with YOU part of what slows gimp down?

carol

Hi,

David Neary writes:

Photoshop handles large images better than GIMP. That's a known fact and it's not trivial to improve.

How, exactly? I've heard this too, but I have no clear idea how they do so - do they have a similar caching system, and just make better decisions about what to cache and when? Or do they use OS specific features to reduce read times for caching operations?

AFAIK they don't load the full image into memory. If you open a large image, only the preview is loaded and if you zoom in, then only the necessary parts are pulled into memory. Of course this doesn't work with all file formats.

Sven

On Fri, Apr 23, 2004 at 02:26:17PM +1200, Jaco Swart wrote:

Hm, mine is Gimp 1.2.5 on a 1.8GHz P4, W2K, but just 256M RAM. The Tile Cache is set to 128M. In the case I described, I did have PS open at first, but no images loaded. After that, I closed PS and Framemaker and tried again - dead slow.

Do you have any variant of Microsoft SQL Server on that machine? SQL Server loads as a service (i.e. when the machine starts up) and will grab as much memory as it can. If so, stop the SQL services and try working with the GIMP again. Might make a difference.

On Thu, 22 Apr 2004, Joao S. O. Bueno wrote:

Date: Thu, 22 Apr 2004 16:54:59 -0300 From: Joao S. O. Bueno
To: gimp-user@lists.xcf.berkeley.edu Subject: Re: [Gimp-user] Environment settings & big images

On Thursday 22 April 2004 16:42, David Neary wrote:

Hi,

Sven Neumann wrote:

On PotatoShop (forced to used at gunpoint), there are no problems editing this image or other large images.

Photoshop handles large images better than GIMP. That's a known fact and it's not trivial to improve.

How, exactly? I've heard this too, but I have no clear idea how they do so - do they have a similar caching system, and just make better decisions about what to cache and when? Or do they use OS specific features to reduce read times for caching operations?

Or perhaps something completely different?

/me thinks that, not worrying about photoshop, one way to optmize is to paint on the scaled down image in real time, and perform the real operation on the full size image in the background.

I believe this is called 'Image proxies'

I did a quick search and found this description http://www.deneba.com/cvhelp/command/image_proxies.html

Did lots more searching of the mailing list archives and if I'm reading this correctly proxies are already being used for things like thumbnails and previews.
http://lists.xcf.berkeley.edu/lists/gimp-developer/2002-April/006814.html

Dave CC'ed the developer mailing list so anyone who is interested should read the responses there too.
http://www.mail-archive.com/gimp-developer%40lists.xcf.berkeley.edu/msg06802.html

Sincerely

Alan Horkan http://advogato.org/person/AlanHorkan/

On 23 Apr 2004, Sven Neumann wrote:

Hi,

David Neary writes:

Photoshop handles large images better than GIMP. That's a known fact and it's not trivial to improve.

How, exactly?

AFAIK they don't load the full image into memory. If you open a large image, only the preview is loaded and if you zoom in, then only the necessary parts are pulled into memory. Of course this doesn't work with all file formats.

There are already bugzilla entries about this -- most prominantly #107246. I have a feeling to do this right it would have to be a fairly sophisticated GEGL node. Why aren't I on gegl-developer again? :)

Rockwalrus

Steve Crane wrote:

Do you have any variant of Microsoft SQL Server on that machine? SQL Server loads as a service (i.e. when the machine starts up) and will grab as much memory as it can. If so, stop the SQL services and try working with the GIMP again. Might make a difference.

No... not.