I tried this and, not surprisingly, the PSD plug-in dies out-of-memory:

 failed to allocate 78643200 bytes

The GIMP core can handle a large image like this but the PSD plug-in
seems to attempt to load the complete image into memory once more and
dies.

There are a few more plug-ins that get a complete copy of the image
instead of working for example tile-based. These are all likely to
fail on large images. I will make a list of these plug-ins.

Such plug-ins should at least make use of g_try_malloc() and quit more
gracefully after informing the user what went wrong

Following plug-ins are likely to fail on large images:

./bmp/bmpwrite.c
./common/animationplay.c
./common/apply_lens.c
./common/gif.c
./common/hot.c
./common/jigsaw.c
./common/papertile.c
./common/pcx.c
./common/psd_save.c
./common/waves.c
./flame/flame.c

From this list only psd_save.c and gif.c have some priority to fix.
It's unlikely that anyone will ever try to save a huge image in bmp
format. For these plug-ins g_try_malloc, like Sven suggests, should be
sufficient.

Wow, I'd forgotten that the GIF plugin slurps an image layer into a
flat array.  That was probably done to make catering for the
interlaced access pattern a no-brainer.  Could still just grab a
line at a time though.

Not scary to fix, just obtrusive and dull.  (Still, GIF is totally
designed for images meant for on-screen viewing on generic consumer
devices, unlike, say, XCF or TIFF.  That is to say that anyone saving
an image which is big enough when non-tiled to upset a desktop system
powerful enough to run GIMP, is going to have interoperability trouble
for that image size anyway.)

Maurits said:
> It's unlikely that anyone will ever try to save a huge image in 
> bmp format.

Actually, someone reported this in the newsgroup recently
(news:comp.graphics.apps.gimp). I asked him to report it here, he
hasn't yet. 

A reference to google groups: 
http://groups.google.fr/groups?dq=&hl=fr&lr=&ie=UTF-8&threadm=slrnblsfkq.4nb.real.addressinthesig%40bolsh.free.fr&prev=/groups%3Fhl%3Dfr%26lr%3D%26ie%3DUTF-8%26group%3Dcomp.graphics.apps.gimp

Funnily enough, this is the same person who recently said he was
prepared to fund certain feature additions to the GIMP. I wrote asking
for more details, and received no reply yet.

Cheers,
Dave.

Two things about the PSD save plug-in:

1) It would probably already help if the data that is allocated
(inside a loop for each channel) would also be freed. This plug-in is
full of mem leaks.

2) It's easy to rewrite the plug-in in such a way that it saves on a
row per row basis. Only catch is that it first calculates the total
size of the compressed data. Based on this size it decides to write
either compressed or raw data. One possible solution is to iterate
over the image data (row per row), calculate it's compressed size, and
iterate once more over the data to write it. Another possible solution
would be to start assuming that data can always be compressed. Based
on this assumption the data is written and the compression table is
written thereafter. In the unlikely case that the image couldn't be
compressed we write it again, this time as raw data.

Another possible solution (my favoured solution, I think) is to write
an imagemagick plug-in, and delegate file loading & saving for a
number of formats to them. They already have routines to load & save
xcfs - so I assume their internal image structures are complete enough
to handle a psd load. They seem to be pretty feature complete in this
department last time I looked.

Of course, it's unlikely this will get in for 2.0, but I would like to
see this done for 2.2

Dave.

I like the idea of using Imagemagick for some file formats, but I'm
not sure this would work for writing psd files. Afaik you can only
write flattened images via the Imagemagick API. You will lose info
about layers, etc. Same problem the other way around: you can use
Imagemagick to import a psd file, but you get a flat image without the
layers. I could be wrong of course, but this is what I remember from
having looked at the API couple of years ago.

We could use this delegation idea for example to export/import WBMP
files or WMF (ImageMagick uses libwmf. This is far superior to the WMF
plug-in we have in Gimp).

Wouldn't it be better to adopt our own WBMP/WMF plug-ins to use libwmf?

The wmf import plug-in that comes with libwmf2 is scheduled for
inclusion before 2.0. Someone just needs to add the configure check
and replace the current plug-in with it.

Of course, something that Works Now is better than nothing (or better
that the existing plug-in). It would be nice to avoid duplication of
effort with ImageMagick for a number of plug-ins, and perhaps get some
closer co-operation between the teams on supporting new formats. 

As I recall, ImageMagick handles loading of layered images, including
layer modes, so perhaps we could get a generic Image to GimpImage
conversion routine, and vice versa, included in either the GIMP or
ImageMagick to allow us to access their internal image structure natively.

Cheers,
Dave.

I disagree: although ImageMagick is nice, I do not install it on most
of the systems that I maintain.  I would not like to be forced to
install yet another set of programs (and their dependencies) in order
to be able to perform some operations that could be done by a
self-contained plug-in.  Code duplication is a bad, but too many
dependencies is also bad.  I would prefer to avoid any dependencies on
ImageMagick.  In fact, I hope that the GUI-less version of the GIMP
would be able to replace it for most common tasks.

It is of course possible to have ImageMagick stuff build optionally. 
It would also be reasonable to keep the older standalone plug-ins 
alive. But if IM is more actively maintained than our plug-ins, and 
of a higher quality to boot, I think that the old plug-ins would 
naturally go away. At the very least, I don't think they will evolve. 

It makes a lot of sense to me to integrate a third party program 
which does parts of what we do, only better.

Cheers,
Dave.

In my opinion IM should be used as a fallback option for loading
images, since it supports more formats (like for example WBMP) than
Gimp does. Of course the important formats will always be supported by
the native gimp plug-ins. As Dave states, the big advantage of IM is
that it's very well maintained. It also comes standard with all
distros, afaik.

I propose to make this (provide an IM loader plug-in) a separate
enhcancement request and concentrate on solving the orinal bug first.

Bumping a bunch of bugs which won't block the 2.0 release to 2.0.1.

Dave.

Doesn't block 2.0.1 either.

Un-CC:ing myself, if anything specific to me turns up then feel free to CC: me
again...

Bumping to milestone 2.2.

Bumping off the 2.2 milestone since noone seems to be working on this.

I just checked a fix for this bug (and 167139) into CVS.  Should it be
backported to the 2.2 stable version?

Back ported to the 2.2 stable branch.  Closing bug.