#772 pict file fails with gm 1.3.47

[Matthias Kiefer]

When trying to open the following pict file with gm 1.3.47, I get an error. With previous versions it worked as expected. Source: https://toolsfairy.com/image-test/sample-pict-files

1.3.46:

gm identify sample-pict-files-sample_640x426.pict 
sample-pict-files-sample_640x426.pict PICT 640x426+0+0 DirectClass 8-bit 787.0Ki 0.000u 0m:0.000132s

1.3.47:

gm identify sample-pict-files-sample_640x426.pict 
gm identify: Unable to uncompress image (sample-pict-files-sample_640x426.pict).
gm identify: Request did not return an image.

[Bob Friesenhahn]

I am able to reproduce this. This error is produced:

08:16:40 0:0.017347 0.110u 894297 pict.c/DecodeImage/1022/Coder:
Scanline length 1 < 2!
08:16:40 0:0.017387 0.110u 894297 pict.c/DecodeImage/1024/CorruptImage:
Unable to uncompress image (sample-pict-files-sample_1280x853.pict)

It seems that a security check which was added is causing the decode to fail.

[Bob Friesenhahn]

It seems that the algorithm I used in changeset 17840:6532b3985f0b to attempt to read files written by older ImageMagick/GraphicsMagick with PixMap rowBytes=[201..250] is faulty. With 3840 bytes per line, the first byte read will be zero because the binary value is "0b1111 00000000". This triggers wrong behavior. I can't think of a way to cause old faulty files to be read.

Existing broken code can be manually fixed by editing coders/pict.c, searching for "Brutal implementation" and then changing the "#if 0" above it to "#if 1".

The problem is fixed by changeset 18087:177023a5eda3 "coders/pict.c (DecodeImage): Do not attempt to intuit byteCount must be a word because the approach used does not work." The fix is in the 1.4.020260529 development snapshot.