Legacy ImageMagick Discussions Archive

Our customers are throwing some very large TIFF files at our software; in the range of 500MB - 1.2GB. These are crashing in our usage of 32bit Q8 6.8.5 IM (dll) version.
The images also crash convert, identify, and IMDisplay

Version: ImageMagick 6.8.5-5 2013-05-07 Q8 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2013 ImageMagick Studio LLC
We access the dll version through C++;
we use Image to load an image and read properties from the image pointer
pImage = new Magick::Image(lszOrgfilePath.c_str());

We create a conversion string and code like this to convert an image:
InitializeMagick(*argv);
MagickCore::GetExceptionInfo(&exception);
image_info=MagickCore::CloneImageInfo((MagickCore::ImageInfo *) NULL);
status=MagickCore::ConvertImageCommand(image_info,argc,argv,(char **) NULL,&exception);

Our conversion step is used to get a resized preview and thumbnails as jpg.

We cannot move to 64 bit Q16 right away, though that is on our roadmap.

Anyway we can use 32 bit Q8 to handle the opening/processing of these large images?

I am asking our customers for permission to allow you access to the images or facsimiles if needed.

thanks,
Graeme

ImageMagick can handle mega-pixel images so the size of the image should not matter. As always, try the latest release@ 6.8.7-8. Does that fail? If so we'll need to reproduce the problem and generate a stack trace before we can locate / fix the bug.

Hi, I tried with the latest 32bit version, and still fail on the largest files, using the command line tools.
I have permission from the customer to share two of the files with you.
they are at:
ftp.northplains.com
user:publicforum
pwd:543publicforum123
dir: /imagemgick

the tifs are from the customer.
imtest.txt is a capture of command line usage with convert and identify
imconvetCapture.jpg and imidentifyCapture.jpg are screen captures

One of the test is on a 1.2 GB tif, with the same type of failure. I will see if I can get permission to share it, if it helps with the investigation.

I have not tested with our implementation at this version, as the command line results indicate there is no point.

Thanks,
Graeme

Try this command:

• convert -limit area 128MB 14MKX_3_4_low_front_layer.tif -resize 512x512 x.jpg

Does that work? The TIFF delegate library appears to be consuming 1.5GB of memory, perhaps to store a couple of large embedded profiles. If that's the case, you might have better luck with the X86_64 version of ImageMagick.

Hi,
limit does not help. Tried to limit map, area, memory and none of them fixed the issue.
Any other ideas? Moving to 64 bit is problematic at this time.

BTW,
I am curious why your documentation mention GB and GiB, MB and MiB. Is there any difference? It seems inconsistent.
(these are the limits on my Windows machine and seem to be adequate for any size images)

C:\Users\gelliott\Documents\TscopeTestMedia\ts-6765>identify -version
Version: ImageMagick 6.8.7-8 Q8 x86 2013-11-28 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2014 ImageMagick Studio LLC
Features: DPC Modules OpenMP
Delegates: bzlib freetype jbig jng jp2 jpeg lcms lqr pangocairo png ps tiff webp
x xml zlib


C:\Users\gelliott\Documents\TscopeTestMedia\ts-6765>identify -list resource
File Area Memory Map Disk Thread Throttle Time

--------------------------------------------------------------------------------

1536 8.3165GB 3.8727GiB 7.7453GiB unlimited 4 0 unlimited


thanks,
Graeme

1 MB = 1000 * 1000 bytes
1 MiB = 1024 * 1024 bytes
See http://en.wikipedia.org/wiki/Binary_prefix

we had some success with a couple of large files by turning on /largeaddressaware in the linker:system section of the exe build (VS2010).