Getting "insufficient image data" error when opening common readable TIFF file with G4 compression

[kwon-young]

Prerequisites

• I have written a descriptive issue title
• I have verified that I am using the latest version of ImageMagick
• I have searched open and closed issues to ensure it has not already been reported

Description

This issue is identical to #1375 and #1780, however I have an image that still produce the same exception: IMSLP47958-089-477.tiff.zip IMSLP47958-052-278.tiff.zip

I had to zip the image because github did not accept the tiff file.

I also debugged magick and found that TIFFScanlineSize(tiff) is 642 655 and GetBlobSize(image) is 259, so it throws the exception:

    if ((1.0*TIFFScanlineSize(tiff)) > (2.1*GetBlobSize(image)))
      ThrowTIFFException(CorruptImageError,"InsufficientImageDataInFile");

I know that the shape of this image is very unusual but it was automatically extracted from a scanned pdf, where page images are splitted into horizontal bands.
I would like to use the montage utility to reconstitute the page, but that is when I have hit this issue.

Steps to Reproduce

identify -verbose IMSLP47958-004-011.tiff

System Configuration

• ImageMagick version:

Version: ImageMagick 7.0.10-3 Q16 x86_64 2020-03-28 https://imagemagick.org
Copyright: © 1999-2020 ImageMagick Studio LLC
License: https://imagemagick.org/script/license.php
Features: Cipher DPC HDRI Modules OpenMP(4.5)
Delegates (built-in): bzlib cairo fontconfig freetype heic jbig jng jp2 jpeg lcms lqr ltdl lzma openexr pangocairo png raqm ra
w rsvg tiff webp wmf x xml zlib

• Environment (Operating system, version and so on): Linux edwin 5.5.13-1-MANJARO #1 SMP PREEMPT Wed Mar 25 17:14:28 UTC 2020 x86_64 GNU/Linux

• Additional information:

$ tiffinfo IMSLP47958-004-011.tiff
TIFF Directory at offset 0xc (12)
  Image Width: 5136 Image Length: 2
  Resolution: 204, 196 pixels/inch
  Bits/Sample: 1
  Compression Scheme: CCITT Group 4
  Photometric Interpretation: min-is-white
  FillOrder: msb-to-lsb
  Orientation: row 0 top, col 0 lhs
  Samples/Pixel: 1
  Rows/Strip: (infinite)
  Planar Configuration: single image plane
  Page Number: 0-1
  Software: fax2tiff
  Group 4 Options: (0 = 0x0)

[dlemstra]

Can you reproduce this issue with version 7.0.10-6?

[urban-warrior]

Thanks for the problem report. We can reproduce it and will have a patch to fix it in the GIT master branch @ https://github.com/ImageMagick/ImageMagick later today. The patch will be available in the beta releases of ImageMagick @ https://www.imagemagick.org/download/beta/ by sometime tomorrow.

[kwon-young]

Thank you for your response.

I've looked at your patch and saw that you used: 2.5*GetBlobSize(image).

However, if you look at the image I have linked, 2.5 * 259 = 647.5 which is still larger than 642.

I think you should use at least a factor of 2.53.

[urban-warrior]

This check is a sanity check, to help prevent nefarious TIFF images from being consumed. The 2.5 factor works for your use case, we can now consume your image without throwing the exception you received. Given that, why would we need to increase the factor to 2.53?

[kwon-young]

I'm so sorry, I've linked to the wrong image.
I have updated the image on the original comment and see that it does not work with a factor of 2.5.

I obtained:

TIFFScanlineSize(tiff) = 655
GetBlobSize(image) = 259

Which gives us a minimum factor of 2.528957529

[urban-warrior]

Thanks for the problem report. We can reproduce it and will have a patch to fix it in the GIT master branch @ https://github.com/ImageMagick/ImageMagick later today. The patch will be available in the beta releases of ImageMagick @ https://www.imagemagick.org/download/beta/ by sometime tomorrow.