#256 TIFF coder errors with bad colormap in grayscale image

v1.0_(example)
closed-wont-fix
None
5
2014-09-30
2013-12-19
Carnë Draug
No

I have some TIFF grayscale images with useless values for ColorMap. The images are grayscale since the value for PhotometricInterpretation is 1 and they have a BitsPerSample value. Pallete images, the only ones that require a ColorMap field, must have a PhotometricInterpretation of 3.

Libtiff is able to read the file, and simply issues a warning about it:

TIFFReadDirectory: Incorrect count for "ColorMap"; tag ignored.

However, GraphicsMagick promotes this warning to an error of the class ErrorCoder which can be caught with GraphicsMagick++:

Magick++ exception: Magick: Incorrect count for "ColorMap"; tag ignored. (TIFFReadDirectory) reported by coders/tiff.c:652 (TIFFErrors)

Even though the error is caught, no image is read. I don't know why the file has a ColorMap since it's not required for this type of image but may be used by specialized software since there's also two private tags in the file (317 and 34362).

This bug can be reproduced with the attached image but not using GraphicsMagick built with quantum depth of 8 (I'm using quantum depth 32), which I'm guessing is because the image has a bitdepth of 16, and the small ColorMap would be enough for it. If that's the case, it would suggest that the ColorMap may be being used incorrectly for non-pallete images.

1 Attachments

Discussion

  • Libtiff 4.0.2 is throwing an error (i.e. more than a warning) in TIFFReadDirectory. In spite of this error being thrown, GraphicsMagick is successfully decoding the image data internally and returning an image but then code in ReadImage() around line 1626 of constitute.c is intentionally discarding the image because an error was reported. This code in constitute.c was intended to defend against poorly-written coders which might return somewhat corrupted images to the user.

    Even if I remove the code which intentionally discards the image, Magick++ will still throw an exception. If you use the read() method and catch the exception right away, then the Image should still be usable even if there is no way to know for sure if the image data is good. You would not be able to read the image via the Image constructor because an image thrown from the constructor does not result in an object.

    It seems that libtiff 3.9.4 does not throw this error.

    A useful fix to libtiff 4.0.X would be to throw a warning rather than an error if the photometric does not require a colormap to decode the image.

     
    • status: open --> closed-wont-fix
    • assigned_to: Bob Friesenhahn
     
  • This problem is with the program which wrote this TIFF as well as how libtiff 4 responds to it. It is not reasonable for GraphicsMagick to second-guess libtiff's error reporting and try to ignore certain reported errors.

     
  • Carnë Draug
    Carnë Draug
    2014-03-03

    It is weird that libtiff is causing an error. Its message Incorrect count for "ColorMap"; tag ignored suggests a warning, not an error. I tried with libtiff 3.9.6 and 4.0.2 (libtiff4 and libtiff 5 in Debian).

    You are correct that second-guessing the libraries is not the right fix. I will report this bug to libtiff then.

     
    • On Mon, 3 Mar 2014, "Carnë Draug" wrote:

      It is weird that libtiff is causing an error. Its message Incorrect count for "ColorMap"; tag ignored suggests a warning, not
      an error. I tried with libtiff 3.9.6 and 4.0.2 (libtiff4 and libtiff 5 in Debian).

      You are correct that second-guessing the libraries is not the right fix. I will report this bug to libtiff then.

      I do agree that libtiff should be more helpful here. Libtiff 4 seems
      to be more picky than older versions.

      Please do post a bug report in the libtiff bug tracker and attach your
      image file there.

      I am also a libtiff maintainer. :-)

      Bob

       
  • Carnë Draug
    Carnë Draug
    2014-03-03

    I have already done so. Thank you for your work