PIL.Image.fromarray fails with uint16 arrays

[dgua]

Sorry if this isn't the right place.

When I try PIL.Image.fromarray with a uint16 array, it fails. Looking at the source code, uint16 is not supported. What would it take to add this data type?

[radarhere]

This is the right place. Welcome to the official home of Pillow, where bug reports and contributions are accepted. In this case, you're asking for an enhancement.

As with many enhancements, it's a question of hoping that someone knowledge takes an interest and is willing to figure out the change. Or if you are so inclined, you are more than welcome to put it together and then create a pull request for review.

Would it be possible for you to provide some sample code? I understand what you're asking, I'd just be interested in having a short program to experiment against. While I'm likely not the right person for this one, I would be keen in checking out the problem at hand.

[dgua]

On Nov 1, 2015, at 4:55:46, Andrew Murray notifications@github.com wrote:

This is the right place. Welcome to the official home of Pillow, where bug reports and contributions are accepted. In this case, you're asking for an enhancement.

As with many enhancements, it's a question of hoping that someone knowledge takes an interest and is willing to figure out the change. Or if you are so inclined, you are more than welcome to put it together and then create a pull request for review.

Would it be possible for you to provide some sample code? I understand what you're asking, I'd just be interested in having a short program to experiment against. While I'm likely not the right person for this one, I would be keen in checking out the problem at hand.

—
Reply to this email directly or view it on GitHub.

OK, here is the code (Python):

from PIL import Image

img_data is a np.array that contains the image (dtype=int16)

im = Image.fromarray(np.flipud(img_data))

This works

im.save('test.tiff’)

Now, ImageJ only supports uint16, not int16. So:

img_data2 = (img_data+32768).astype(dtype=np.uint16)
im2 = Image.fromarray(np.flipud(img_data))

This generates an error

I am using the Anaconda distribution with Python 2.7.

Davide

[mairsbw]

This problem still exists. I'm working with uint16 TIFFs for a remote sensing/GIS application. I can read the uint16 data from an image just fine, but can't write it back. Very unexpected that you can't roundtrip uint16 data with Pillow's Image module.

@radarhere If you could point me in the right direction I can likely code up this missing functionality as I would think it'd be trivial with the rest of the support available in this library.

@dgua I believe matplotlib and pylibtiff can work around this problem for now (see this source)

[mairsbw]

So saving a single-channel uint16 TIFF image doesn't work with matplotlib as it likes to save everything as 4-channel RGBA images.

[mairsbw]

Re: the above, see here

[radarhere]

Are you asking how to contribute, or for a hint as to which files to look at?

If contributing, then have a look at https://github.com/python-pillow/Pillow/blob/master/.github/CONTRIBUTING.md. Click on the Fork button at https://github.com/python-pillow/Pillow, then run git clone https://github.com/mairsbw/Pillow.git on your local machine. Make your changes, commit and push them back to origin. Once done, come back here and make a new pull request - https://github.com/python-pillow/Pillow/pull/new/master

[mairsbw]

Which files to look at. I've actually already contributed to this repo way back in the day and am familiar with that process.

[wiredfool]

It may work if the array is converted into a 32 bit datatype first. While there is support for reading int16 files, there isn't support in pillow for storage of anything but 8 or 32 bpp images.

[radarhere]

In trying to help @mairsbw, I'm having a difficult time determining where the relevant code is, after realising that this thread doesn't actually say what the error is.

That said, I'm guessing that the issue lies at https://github.com/python-pillow/Pillow/blob/master/PIL/Image.py#L2204

[wiredfool]

You're looking in the right place. It looks like it should be supported so we're at the point of looking and seeing what the error is and debugging from there.

[mairsbw]

Sorry about that, @radarhere, I thought this issue explained the error. The relevant error is the TypeError: Cannot handle this data type at Image.py:2168. From adding some debugging output I see that the KeyError raised is (1, 1), '<u2'). This image should be a greyscale (single-channel) TIFF with uint16 data, so that seems correct.

If you modify Image.py to add a mapping for the type found in the Uint16 that I'm using you can get it to support writing back TIFFs, but only as uint8 values, not uint16. So looks like there are necessary changes in the packing functions.

If you dig into Unpack.c you can see where the relevant 16-bit greyscale reading is supported. Pack.c has a similar section.

I have a pending pull request where we can continue the discussion of how to go about it.

[mairsbw]

In case references aren't sent out in notifications, I've added a PR w/ a test that fixes this in #1819.

[wiredfool]

Having gone through this and the numpy tests that we have in Tests/test_numpy.py

1. We're not testing potentially troublesome values that would indicate signed/unsigned errors or potential overflow. All of the values we're testing are small integers.
2. The signed conversions using the unsigned integer unpacking functions make me want to take a better look at them. particularly:

    ((1, 1), "<i2"): ("I", "I;16"),
    ((1, 1), ">i2"): ("I", "I;16B"),

I suspect, but have not tested, that this should actually be:

    ((1, 1), "<u2"): ("I", "I;16"),
    ((1, 1), ">u2"): ("I", "I;16B"),
    ((1, 1), "<i2"): ("I", "I;16S"),
    ((1, 1), ">i2"): ("I", "I;16BS"),

3. Similarly, the 32bit conversions appear to be a mix of signed/unsigned.