Large 1bit Tiffs take forever

[snibgo]

For one build method, see Compiling IM with Cygwin. Once you have the Cygwin tools and IM source, building IM needs just five commands. For Q8, use "--with-quantum-depth=8" in the ./configure command.

[DustinYoder]

So I compiled the beta version with cygwin and it does run, but seems to be ignoring the command line -limit parameters I'm passing in. The normal precomiled binary honors the -limit settings I put in the command line, but the beta that I compiled has reverted to running with some preset limits. Is this something I need to change when compiling or can I edit the default limits somewhere? Is there a debug or something I can do when running the full command to show the actual settings used during processing?
my current command is
magick convert TEST.TIF -limit memory 28GiB -limit map 28GiB -limit width 100GP -limit height 100GP -depth 1 -rotate 270 OUT.TIF
This is allowing the memory usage to go higher than the limit and actually use up all the memory and then start using disk cache. I'd like to compile this beta version in the same way the distro binary was compiled. Just to make sure it works like that one did. Thanks again.

[fmw42]

For ImageMagick 7, use magick, not magick convert. You should change your policy.xml file rather than setting -limit ... I believe they only restrict and do not allow you to increase values.

[snibgo]

Is there a debug or something I can do when running the full command to show the actual settings used during processing?

Insert "-list resource" to find the settings at that point in the command, eg before or after your "-limit" settings.

As Fred says, "-limit" can only apply extra restrictions. It can't relax restrictions made in policy.xml.

[DustinYoder]

Great info! Ill give it a shot.

[DustinYoder]

I am compiling with the following configure prior to make. It seems as though I'm getting the 32 bit quantum depth version because the cache is looking for 31.5GB instead of the 8GB it had been looking for with the downloaded binary (8 bit version). Is the --with-quantum-depth=8 the only thing I need to do to build the 8 bit quantum depth version? Also, can I do 1 bit quantum depth? Thanks.

$ ./configure --prefix=/home/prinect/iminst --with-quantum-depth=8 --enable-shared=no --enable-static=yes --with-rsvg=yes --with-windows-font-dir=/cygdrive/c/Windows/Fonts --disable-dependency-tracking

[DustinYoder]

Ok, I found that magick -version shows the quantum number after the version number. Mine is actually Q8 so I'm not sure why it's still wanting to trigger the disk cache. Is there a way to tell which limit is causing the disk cache to happen by looking at the debug log?

[snibgo]

Is there a way to tell which limit is causing the disk cache to happen by looking at the debug log?

Yes. Search the log for "Disk" and look at the previous entry. For example:

Code: Select all

magick -debug resource -limit area 0 toes.png -blur 0x1 NULL: 2>x.txt

Two entries in the log are:

Code: Select all

2019-10-05T15:42:20+00:00 0:00.023 0.016u 7.0.8 Resource magick[4744]: resource.c/AcquireMagickResource/385/Resource
  Area: 62211B/0B/0B

2019-10-05T15:42:20+00:00 0:00.023 0.016u 7.0.8 Resource magick[4744]: resource.c/AcquireMagickResource/385/Resource
  Disk: 746532B/746532B/8EiB

In each tag, the first number is the size IM wants and the last number is how much is available from the policy.xml and limit settings. (I forget what the middle number means.) So IM wants 62211 bytes for an area but no space is available. Then it wants 746532 bytes on disk, and there is effectively no limit.

[DustinYoder]

So I have everything recompiled using the beta version code, but I am now getting the same error with the output file that I was with before using the normal windows binary. The output tiff is invalid and does not open even in photoshop. I've put the input file and output file in a zip which can be downloaded at https://www.carlisleprinting.com/sites/ ... _issue.zip
The command I'm using is
>magic convert TEST.TIF -limit memory 28GiB - limit map 28GiB -limit width 100GP -limit height 100GP -limit file 1536 -depth 1 -rotate 270 TESTOUT.TIF
I've also tried without the -depth 1. Just a side note, I couldn't process this file till I changed the 'file' limit to 1536, it kept writing to disk cache before that. So if anyone can tell why the TEST_OUTPUT.TIF isn't a valid tiff, and what I can do to make imagemagick output a valid tiff, I'd be very grateful. T hanks.

[DustinYoder]

Both files have 'identify' output that shows the same settings but with a rotation applied. (They are now both TIFF format instead of the output being in TIFF64 like the normal windows binary was doing)
INPUT.TIF = TIFF 104500x78499 104500x78499+0+0 1-bit Bilevel Gray 1.6e+02MiB 0.000u 0:00.003
OUTPUT.TIF = TIFF 78499x104500 78499x104500+0+0 1-bit Bilevel Gray 1.6e+02MiB 0.000u 0:00.003
So I think there may still be a bug in the code. Photoshop complains that there isn't enough memory to open the file. I have 32GB so it should be fine.

[DustinYoder]

I think there is a problem still with the TIFF output from the command I posted above with the same tiff I included. Anyone that programs imagemagick maybe have a chance to take a look at this?

[fmw42]

try using magick only and not magic convert