I just committed a fix.

The PNGReadWriter currenlty has a hack to support 16 bits per channel gray
scale (with a slow bit poker loop), but not with transparency...
- transparency is handled with a palette
- ColorForm only supports depth <= 8
Since the Form is forced to depth 8, and since we must choose an entry in
the palette for transparency,  I forced the transparency to be stored at
1st palette entry (value 0) in case of 16 bitsPerChannel.

It seems to me that there was another bug even for bitsPerPixel <= 8: the
palette is 1-based indexed so transparent color index was one off.

It also seems to me that the inversion 255-pixelValue is wrong in the 16
bitsPerChannel bitPoker loop , I did change it.


2014-05-09 19:36 GMT+02:00 Yoshiki Ohshima <Yoshiki.Ohshima at acm.org>:

> On Fri, May 9, 2014 at 1:14 AM, Bert Freudenberg <bert at freudenbergs.de>
> wrote:
> > Do we support any 16 bit-per-channel gifs?
>
> Not sure what you mean by "gifs" (I am specifically talking about
> PNGs), but sure, I think Squeak should be able to read a PNG file, as
> long as it is a valid one.  If it is 16 bits per channel, it should
> downscale the depth to 8 and create a 32 bpp Forms.  This does happen
> in most of the cases, but when the PNG file specifies the transparent
> pixel (it is also in 16 bit value), it causes an error.
> --
> -- Yoshiki
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140510/86eb184d/attachment.htm