Hi, DzZero <jnielsen@xxxxxxxxxxxxxxxxx> writes: > I am not sure if it is related at all but GIMP (as much as I hate to > admit it) has some severe memory issues with large files. Or > something gimp uses really I dont know. if you have such problems, you should report them using Bugzilla (http://bugzilla.gnome.org/). > > I regularly deal with 400-800MB images and gimp just chokes on the > big ones. 400-500 I can normally work with for a period of time but > it will ultimately choke. And yes we have the hardware to back it > up. 1.5-2GB of ram and 1GB of swap and using at most 1 undo > level. These are normally greyscale (8bit images). On occasion the > larger files (800MB range) are color. I have also tweaked the tile > cache size in all forms. Sometimes setting it big works sometimes > small. Seems to be no ryme or reason as to why. could you have a look at the size of the swap file when this happens? If it has grown to about 2GB, you are seeing bug #74478. > I have noticed issues related to clipping as well. Under this > situation using a small tile cache seems to work most of the time. I > can have the same memory available. Open a 100MB image. Import a > path. Clip to the path using copy and repaste that into a new > image. At that point I can not save. If I attempt to GIMP again > chokes. please report to Bugzilla. > I would submit an strace of this but the fact is if I do so the > strace alone is going to be MBs of info. Does anyone really want to > rumage through it? straces are rarely useful to debug an application like The GIMP. I suspect that when you say 'choke', you are talking about a segmentation fault. It would be useful to get a stack trace from such a crash. Please don't confuse strace with stack trace, these are two different things. You can get a stack-trace from GIMP by using the command-line option '--enable-stack-trace alyway'. I doubt however that this will work on Windows due to the lack of gdb. Salut, Sven
