ANN: PIL 1.1.6 final (december 3, 2006)

Thanks for the information, Fredrik.

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

No problem. I'll try to provide a minimally-invasive patch
to address  
this issue (it's really simple to do -- the code just needs
to pass  
the correct byte order to Unpack.c, so hopefully this will
count as  
'low-hanging fruit').

>> - There is a buffer-overflow problem in 'struct
>> ImagingMemoryInstance'
>> ...
> 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.

Thanks for the info. I'm glad to hear about the upcoming
changes for  
1.2, and would be happy to help with some of that if I
can...

>> - The 'fromarray' command is a bit broken in
Image.py:
>> ...
> that code was contributed by the numpy developers, but
it sure looks
> broken.  hmm.

I'll also try to provide a minimally-invasive patch here
too.

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

Does this count as low-hanging? I'd be happy to send a patch
if it  
would be useful; otherwise I'll just put it into my code
where it  
interfaces with PIL.

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

Great -- I'm looking forward to 1.2!

Thanks again,

Zach
_______________________________________________
Image-SIG maillist  -  Image-SIGpython.org
htt
p://mail.python.org/mailman/listinfo/image-sig

Hello all,

>>> - 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).
>
> No problem. I'll try to provide a minimally-invasive
patch to address
> this issue (it's really simple to do -- the code just
needs to pass
> the correct byte order to Unpack.c, so hopefully this
will count as
> 'low-hanging fruit').


Here is a simple patch to make PIL read TIFFs in big-endian
format  
with multibyte pixels properly.

The changes are that the 'pack' and 'unpack' raw modes are
now keyed  
to the byte order in the TIFF file, which they were not in
the past.  
I also removed attempts to read and write TIFFs with signed
16-bit  
integer pixels into 'I;16S' files, because Unpack.c and
Pack.c don't  
have any way to convert rawmode 'I;16S' files to/from
user-mode 'I; 
16S'. Now these files are properly read in as 'I'-mode
files.

Will this patch make it into a maintenance release 1.1.7?
I'd like to  
know whether I should keep a fork of PIL until 1.2 comes
out, so that  
people in my lab and others can read image from our
microscopes into  
and out of python/numpy.

Zach

_______________________________________________
Image-SIG maillist  -  Image-SIGpython.org
htt
p://mail.python.org/mailman/listinfo/image-sig