GraphicsMagick cannot process large BMP images.
Swiss army knife of image processing
Brought to you by:
bfriesen
Menu
▾
▴
#187 GraphicsMagick cannot process large BMP images.
closed-wont-fix
5
2014-11-18
2012-04-21
No
When I tried to process a large (24 bit 41728x17154 pixels, 2GB size) with GraphicsMagick, I received the "gm convert: Memory allocation failed (test.bmp) [Not enough space]." error. The same image in the JPG format processed correctly.
What operating system are you using and is your GraphicsMagick a 32-bit application or is it 64-bits? Can you please add '-debug coder' early in the command options (e.g. right after 'convert') so that there is logging output? This will help us know what BMP options were used.
BMP2 can not support width or height greater than 32767 (file format header restriction), but BMP3 could theoretically support up to 2147483647. It could be possible to support BMP2 width up to 65535, but height is definitely constrained to 32767 due to how the format works.
There may be weaknesses in the GraphicsMagick implementation if RLE compression is used. It seems that RLE would substantially increase the memory allocation requirement due to the implementation.
The OS is WinXP 32bit. The BMP is uncompressed. Adding the "-debug coder'" option produses the following.
18:05:44 0:01 0.010u 4092 constitute.c/ReadImage/1590/Coder:
Invoking "BMP" decoder (Microsoft Windows bitmap image) subimage=0 subrange=0
18:05:44 0:01 0.010u 4092 bmp.c/ReadBMPImage/529/Coder:
enter
18:05:44 0:01 0.020u 4092 bmp.c/ReadBMPImage/565/Coder:
Magick: BM
18:05:44 0:01 0.020u 4092 bmp.c/ReadBMPImage/575/Coder:
BMP size: 40, File size: 2147406390
18:05:44 0:01 0.020u 4092 bmp.c/ReadBMPImage/634/Coder:
Format: MS Windows bitmap
18:05:44 0:01 0.020u 4092 bmp.c/ReadBMPImage/636/Coder:
Geometry: 41728x17154
18:05:44 0:01 0.020u 4092 bmp.c/ReadBMPImage/638/Coder:
Bits per pixel: 24
18:05:44 0:01 0.030u 4092 bmp.c/ReadBMPImage/644/Coder:
Compression: BI_RGB
18:05:44 0:01 0.030u 4092 bmp.c/ReadBMPImage/684/Coder:
Number of colors: 0
18:05:44 0:01 0.030u 4092 constitute.c/ReadImage/1610/Coder:
Returned from "BMP" decoder, returned image is NULL!
It seems that the problem is that the implementation wants to allocate enough memory to contain the whole included image. This made the decoder implementation much easier, but it means that your system would need to be able to allocate 2GB of RAM, which is not likely to work in Windows XP.
Do you know what program wrote this BMP file?
It was MapBuiler, the tool for exporting GoogleEarth cache into an image. Why does it matter? The program is clearly not to blame. Can you rewrite the implementation so that it'll work with images larger than the available RAM? After all, that's exactly what I was looking for when I found GraphicsMagick.
It was MapBuiler, the tool for exporting GoogleEarth cache into an image. Why does it matter? The program is clearly not to blame. Can you rewrite the implementation so that it'll work with images larger than the available RAM? After all, that's exactly what I was looking for when I found GraphicsMagick.
I do see how the BMP support can be re-written to use a whole lot less memory but it is a large task because BMP is a complicated format.
I have verified that ImageMagick's BMP implementation has the same problem.
So, when do you think large BMP images become supported? Being able to work with images larger than available RAM is crucial, not just for me but for many other people, too. When I searched for the solution on the internet, I saw a lot of similar requests. Ironically, most of the tools they've been advised to use can't do that, at least not with BMP or JPG, although some, like VIPS, are specifically claimed to. GraphicsMagick at least was able to work with large JPG images, that's something, but I need other formats, too especially BMP.
GraphicsMagick is an all-volunteer project worked on when there is time and enthusiasm available. As such, it is impossible to forecast when and if the BMP support will be re-written to support large images. Given current volunteers, there are currently other issues which would be worked on first.
VIPS may be using ImageMagick or GraphicsMagick to obtain its BMP support since it uses *Magick to support formats that it does not offer internal support for.
Well, I couldn't care less what VIPS uses, because when it comes to large images it quite simply doesn't work. Not with BMP, not with JPG, not even with PNG.
Now regading GraphicsMagick: can you state in the documentation which formats can be worked on when the image size exceeds available RAM and which can't? This would be of much help for people looking for large image support.
Your point on the documentation is a very good one. Besides helping potential users, it helps GraphicsMagick developers as well. Most of the formats do not allocate a buffer for the whole image.
You should look at PNG, TIFF, and PNM (e.g. PPM) as popular formats which do well at large file sizes. PNG is compressed so it would consume more CPU than the other two.
If it's so good a point, then perhaps you can tell me when is the list with formats that can and cannot be paged by GraphicsMagick going to be on its site?
Please use a 64-bit operating system and a 64-bit build of GraphicsMagick with sufficient RAM and this performance problem (and/or memory allocation failure) will go away like it never existed in the first place.
No, I'll just use (am using now) software, which actually works, rather than this POS made by shitheads for shitheads, full of bugs, which nobody's going to fix. Fuck you very much.