Added S to list of I;16 formats

[radarhere]

Resolves #1244 - loading of I;16S images

There is a list of I;16 modes - I;16, I;16L, I;16B and I;16N. I presume that I;16S was simply forgotten in that list, rather than being excluded for any particular reason.

[wiredfool]

I wouldn't be surprised if I;16S isn't fully baked. I know that there are no conversions from I;16S to anything else, and I don't think that there are actually any pixel access methods for it. I think basically the only thing that can be done with it is to offload to numpy/scipy.

[wiredfool]

We need to find a distributable I;16S image to test with, I think this might be a GIS image format.

[wiredfool]

I'll look.

Fwiw, the signed modes are a pain because they are not really supported in the backend. Some operations may work, but anything dealing with pixel values is going to be broken. (And broken meaning that the results will be wrong, not that it will crash) There are really three options:

• convert to unsigned for storage, use the signed formats only for reading and writing
• write converters to and from signed so that we can store in signed, but can losslessly convert to do operations on the data.
• push full signed access through.

[wiredfool]

The access part is wrong, as it's returning a uint16, not an int16. Unpack is probably ok, but there's probably some issues related to endianness, either big, little or native. I think that in this case, it's probably going to wind up being native. There are existing unpack methods for all of the I;16*S methods -> I. There are some existing pack methods, but they don't cover all of the permutations.

I'm kind of thinking that the best move might be to make the I;16S modes store as I (aka, I32 or I32S), and leave out the I;16 storage for now.

[homm]

successor: #2577