[Image-SIG] ANN: PIL 1.1.6 final (december 3, 2006)

[Zachary Pincus]

> Report bugs to this list.

- 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.)  
Now, I just discovered a minor problem in my patch relating to 32-bit  
images, so I will send a new one in a few hours. This problem has  
been in PIL for some time, and has basically disqualified it for use  
in scientific imaging (which uses 16-bit data all of the time). I'd  
love to get that changed.

- 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.

- 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[0] == '|' or typestr[0] == _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:]'

- 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). I've been working on a patch to fix this, as described in  
that earlier email. Probably this patch is too big a change to apply  
to this release, but I would REALLY like to talk to someone about the  
chances for 1.7 (or whatever) accepting changes that make 16-bit  
image handling less vexing.

Thanks,

Zach Pincus

Program in Biomedical Informatics and Department of Biochemistry
Stanford University School of Medicine