[Image-SIG] ANN: PIL 1.1.6 final (december 3, 2006)
fredrik at pythonware.com
Sun Dec 3 19:08:13 CET 2006
Zachary Pincus wrote:
> - A week or so ago, I reported that PIL loads multi-byte (e.g. 16-
> and 32-bit raster data) TIFF files incorrectly if the files were
> written as big-endian. (I also and provided a test case and patch.)
I noticed the post, but haven't had time to look at it; given my current
schedule, it's been hard enough to get 1.1.6 out of the door (and in
case you wonder, the 1.1.6 feature set has been frozen for quite some
time; the last beta was basically a release candidate).
> - There is a buffer-overflow problem in 'struct
> ImagingMemoryInstance' defined in 'Imaging.h'. Specifically, this
> struct has a field defined as follows:
> char mode[4+1]; /* Band names ("1", "L", "P", "RGB", "RGBA",
> "CMYK") */
> However, mode strings with more than 4 characters are copied into
> this buffer via strcpy, clobbering other data fields in the struct. I
> will provide a patch that makes the buffer large enough to hold all
> mode strings that might be used, and changes the strcpy calls to a
> strncpy. This patch also I will try to provide in a few hours.
that's a known minor issue, and the struct is intentionally left as is
for compatibility reasons (see the mailing list archives for details).
this will be fixed in 1.2, where the internal storage model.
> - The 'fromarray' command is a bit broken in Image.py:
> Specifically, the following stanza is incorrect --
> if mode is None:
> typestr = arr['typestr']
> if not (typestr == '|' or typestr == _ENDIAN or
> typestr[1:] not in ['u1', 'b1', 'i4', 'f4']):
> raise TypeError("cannot handle data-type")
> typestr = typestr[:2]
> if typestr == 'i4':
> The error is that 'typestr = typestr[:2]' should instead be 'typestr
> = typestr[1:]'
that code was contributed by the numpy developers, but it sure looks
> - Also, the to/from array commands don't handle 16-bit images, though
> it could be accomplished easily. I will provide a patch for this too.
> - I still think that the handling of 16-bit images itself represents
> a major bug (see my previous email to the list, but in short, having
> to deal with big/little endian issues at the high-level API for 16-
> bit images but no other image types is a bug and causes other bugs in
> the code).
as you might have noticed, the I16 support is only documented in the
CHANGES file, where it is labeled as experimental and incomplete; most
of it is based on contributed code from a small number of projects that
rely on "zero copy" access to underlying data.
under PIL 1.2's storage model, all I;16 images will most likely always
look like "I" images for ordinary users; if you need to get at the "raw"
data, you'd need to explicitly specify that when opening/loading the image.
as for the 1.1 branch, we'd like to keep it relatively stable, but
"low-hanging fruit" patches are of course still welcome (and nothing
prevents us from doing a 1.1.7 maintenance release).
More information about the Image-SIG