Skip to content

cannot identify image file #1602

Description

@playnet

and it's me again :)
a35e6972-f868-42e4-86ac-42a6162c9c3e.tiff.tif.zip
unzip and load

    $ python
    Python 2.6.6 (r266:84292, Jul 23 2015, 15:22:56) 
    [GCC 4.4.7 20120313 (Red Hat 4.4.7-11)] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> from PIL import Image
    >>> img = Image.open("/tmp/a35e6972-f868-42e4-86ac-42a6162c9c3e.tiff.tif")
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/opt/API/fsapi/venv/lib/python2.6/site-packages/PIL/Image.py", line 2286, in open
        % (filename if filename else fp))
    IOError: cannot identify image file '/tmp/a35e6972-f868-42e4-86ac-42a6162c9c3e.tiff.tif'

But
    tiffinfo /tmp/a35e6972-f868-42e4-86ac-42a6162c9c3e.tiff.tif
    TIFF Directory at offset 0x1e9400 (2003968)
      Image Width: 595 Image Length: 842
      Resolution: 72, 72 (unitless)
      Bits/Sample: 16
      Compression Scheme: None
      Photometric Interpretation: min-is-black
      Extra Samples: 1<unassoc-alpha>
      FillOrder: msb-to-lsb
      Orientation: row 0 top, col 0 lhs
      Samples/Pixel: 2
      Rows/Strip: 3
      Planar Configuration: single image plane
      Page Number: 0-1
      DocumentName: 

AND
    >>> from wand.image import Image as wima
    >>> img7 = wima(filename="../a35e6972-f868-42e4-86ac-42a6162c9c3e.tiff.tif")
    >>> img7
    <wand.image.Image: 3d45d69 'TIFF' (595x842)>
    >>> img7.format
    'TIFF'

And viewers show this file without problems. Not segfault, but bug. Nasty bug.

Activity

  1. radarhere commented on Dec 18, 2015

    @radarhere
    Member

    The currently supported TIFF prefixes are MM\000\052, II\052\000, and II\xBC\000

    This TIFF has a prefix of II*\x00

  2. playnet commented on Dec 18, 2015

    @playnet
    Author

    that is, we move on wand?

  3. wiredfool commented on Dec 18, 2015

    @wiredfool
    Member

    It's an invalid image. It's tagged as little-endian, but with a big-endian magic number.

    (Where the magic number is 42, as an int16)

    http://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf

    Bytes 0-1: The byte order used within the file. Legal values are:
    “II” (4949.H)
    “MM” (4D4D.H)
    In the “II” format, byte order is always from the least significant byte to the most
    significant byte, for both 16-bit and 32-bit integers This is called little-endian byte
    order. In the “MM” format, byte order is always from most significant to least
    significant, for both 16-bit and 32-bit integers. This is called big-endian byte
    order.
    Bytes 2-3 An arbitrary but carefully chosen number (42) that further identifies the file as a
    TIFF file.
    The byte order depends on the value of Bytes 0-1.
    
  4. cgohlke commented on Dec 19, 2015

    @cgohlke
    Contributor

    It's an invalid image.

    I don't think II*\x00 is invalid for TIFF:

    struct.unpack('<H', b'*\x00')[0] == 42
  5. wiredfool commented on Dec 21, 2015

    @wiredfool
    Member

    That should teach me to comment quickly before leaving for the weekend.

    This one is returning a format key of:

    format key: ('II', 1, (1,), 1, (16, 16), (2,))
    

    Which is not one that we support. Specifically, multiband images with bit depth > 8 bit are not supported anywhere in the code.

  6. terramars commented on May 23, 2016

    @terramars

    Having the same problem with single-channel paletted TIFF, created by GDAL, tiffinfo as follows:

    TIFFReadDirectory: Warning, Unknown field with tag 33550 (0x830e) encountered.
    TIFFReadDirectory: Warning, Unknown field with tag 33922 (0x8482) encountered.
    TIFFReadDirectory: Warning, Unknown field with tag 34735 (0x87af) encountered.
    TIFFReadDirectory: Warning, Unknown field with tag 34737 (0x87b1) encountered.
    TIFFReadDirectory: Warning, Unknown field with tag 42113 (0xa481) encountered.
    TIFF Directory at offset 0x34293c6 (54694854)
    Image Width: 10774 Image Length: 12577
    Bits/Sample: 16
    Sample Format: unsigned integer
    Compression Scheme: LZW
    Photometric Interpretation: palette color (RGB from colormap)
    Samples/Pixel: 1
    Rows/Strip: 1
    Planar Configuration: single image plane
    Color Map: (present)
    Tag 33550: 4.999617,4.999789,0.000000
    Tag 33922: 0.000000,0.000000,0.000000,679006.067110,9955209.915048,0.000000
    Tag 34735: 1,1,0,7,1024,0,1,1,1025,0,1,1,1026,34737,22,0,2049,34737,7,22,2054,0,1,9102,3072,0,1,32736,3076,0,1,9001
    Tag 34737: WGS 84 / UTM zone 36S|WGS 84|
    Tag 42113: 0
    Predictor: horizontal differencing 2 (0x2)

  7. wiredfool commented on May 24, 2016

    @wiredfool
    Member

    That's actually a different issue, as it's a single channel image. (Though, palette, which may add wrinkles for support). Can you post the image?

  8. terramars commented on May 24, 2016

    @terramars

    Yea I'll make a sample. Will get it to you next week.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions