Why does Magick++ use 800+ MB of memory for this?

[bean]

Code: Select all

size_t sizeXY = 8192;
Magick::Image canvas(Magick::Geometry(sizeXY, sizeXY), Magick::Color(0, 0, 0));

So basically I'm looking for a library that I can use to stitch together 16² tiles (512px² each) and draw some basic shapes (dots/color filled circles) on the resulting canvas. ImageMagick/Magick++ has way, way more features than I needed, nonetheless I looked into it, because it seems to me like the de-facto standard when it comes to working with images cross platform. I did expect my application to get bloated a by the unused capabilities of this behemoth of a library, but not nearly as much as this...


The exact same program using CImg instead...

...which is even less than what I've naively calculated myself.

So why does ImageMagick/Magick++ need more than four times the memory? Can I do anything to get it down to something reasonable?

Thanks


PS: I've tested this with versions 6.9.2-4-Q8 and 7.0.0-0~beta20151020 (Q8) on Windows 10 x64.

[snibgo]

IM v6 Q8 needs 4 bytes/pixel in memory. When you have read the input images and are making the output, you have 16x16 images each of 512x512 pixels, plus the same again for the output. This is 537 MB (plus some overhead per image).

[bean]

IM v6 Q8 needs 4 bytes/pixel in memory. When you have read the input images and are making the output, you have 16x16 images each of 512x512 pixels, plus the same again for the output. This is 537 MB (plus some overhead per image).

Please note that the 800+ MB are originating from the single line of code I quoted, hence the question "why does Magick++ use 800+ MB of memory for this", "this" referring to the code I posted only. With the text that follows the code, I was just giving some background information about what I intend(ed) to use Magick++ for. I'm sorry if this has confused you and wasted your time.

The whole program would have looked like:

Code: Select all

#include <Magick++.h>
int main(int argc, char *argv[]) {
    size_t sizeXY = 8192;
    Magick::Image canvas(Magick::Geometry(sizeXY, sizeXY), Magick::Color(0, 0, 0)); // breakpoints here ...
    return 0; // ... and here
}

> If this is as mind boggling to you as it is to me, here's some proof.

By the information you've provided me with (thanks!) my math was correct and the program ought to use a bit more than 256 MB of RAM (8192²x4 B) not 864 MB as it does. This is why I said CImg used less than I expected.


Edit: And if you're thinking it's due to the debug information in this debug build, apparently it is not.

[snibgo]

Sorry, I misunderstood. Yes, for 8192x8192 pixels in Q8, I would expect 268 MB or so.

Some operations can work with palette images that are just 1 byte/pixel, but I don't know how to program that.

[bean]

Sorry, I misunderstood. Yes, for 8192x8192 pixels in Q8, I would expect 268 MB or so.

Some operations can work with palette images that are just 1 byte/pixel, but I don't know how to program that.

So no idea why this isn't the case on my system?



PS: Yeah... oups... I've grown up with Windows, so when I talk about MB I mean MiB. 8192²x4 B are ~268,44 MB or 256 MiB exactly, sorry again.

[snibgo]

I don't know why you seem to need so much more memory. Just for fun, you might try creating two images of that size. Does the memory footprint double? Ten images takes ten times as much?

I use MagickCore, rather than Magick++. Maybe the ++ does something I wouldn't expect. I don't have instrumentation to measure memory useage, beyond the standard Windows tools. Hmm... I might write a process module that says "Paused -- press any key to continue."

[dlemstra]

It looks like your version of ImageMagick has HDRI enabled and then each pixel will require 32 bits (sizeof(float)) per channel. Did you build from source or did you use one of the Windows installers?

[bean]

It looks like your version of ImageMagick has HDRI enabled and then each pixel will require 32 bits (sizeof(float)) per channel. Did you build from source or did you use one of the Windows installers?

Thanks, that was indeed the culprit.

32 bits (sizeof(float)) per channel

Wait what? Are you serious? That's 79 octillion colors... what lunatic came up with this idea? And what genius thought that the vast majority of IM users need more than 16.7 million colors to justify making this the default in v7?!

[snibgo]

The smallest number of bytes per floating-point generally available from compilers seems to be 4, the "float" type. HDRI takes 4, 8 or 16 bytes/channel/pixel. Both Q8 and Q16 take 4 bytes in HDRI. See http://im.snibgo.com/compim.htm#varieties

If you don't need HDRI, integer HDRI takes 1, 2, 4 or 8 bytes/channel/pixel. I do sometimes need the precision that comes from 4 B/ch/pix.

(I would love Q8, Q16, Q32, Q64 and HDRI or not-HDRI to be run-time options, not compile-time options. There are many things I'd love, but can't have.)