multi-page tiff: excessive memory usage

[cbecker]

Hello, I am experiencing a weird issue (or I am misreading what I am getting).

There is a sample multi-page tiff you can download here (~4MB) http://www.nightprogrammer.org/wp-uploa ... xample.tif

Now, I tried the following:

Code: Select all

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <wand/magick_wand.h>

int main()
{
	MagickWand *wand;
	wand = NewMagickWand();

	printf("Before\n");
	getchar();

	MagickReadImage(wand, "multipage_tif_example.tif");

	printf("After\n");
	getchar();

	return 0;
}

Memory usage in After increases 270MB wrt Before. This gets worse with bigger tif files, for example it allocated 1GB when fed with a 68MB tif file.
Is there any reason for such large memory allocation? I am using archlinux, imagemagick 6.8.9-0

Thank you.

[snibgo]

The compressed size (JPEG in this case) isn't relevant.

The memory for Q16 is generally 8 bytes/pixel. So you need 1903*899*8*10 = 137 MB. True, this is half what you say, and I don't know why that is.

[cbecker]

Thanks, I noticed I have the Q16 version on my system.

I guess where the remaining memory is coming from. I am not sure if this was happening in previous magick versions.

[cbecker]

I think it is easier to see it with a gray-level 8-bit TIFF file.

For example, this one https://documents.epfl.ch/groups/c/cv/c ... aining.tif

That file is 124 MB (no compression), but imagemagick uses 1.8 _GB_ when opening it. That is a factor of 14, which is way over a factor of 2 to account for 16-bit pixel type.

Any insights? this is pretty weird.

[snibgo]

What is weird? The memory for Q16 is generally 8 bytes/pixel. This roughly corresponds to your observed 14-times 1 byte/pixel in the file. IM always creates at least 3 channels in memory, for RGB, even for greyscale images. I suppose the other 2 bytes are for alpha.

training.tif needs 1.03 GB, by the general rule of thumb.

If you only want 8-bit processing, Q8 will you save 50% of memory. V7 will, we are told, use just one channel in memory for greyscale, but won't be released for a while.

[timholy]

If it's using 16-bit for each value, then you'd expect 8 bytes per pixel if it opens an R, G, B, and A channel for each image. That's quite different from 14.