<div dir="ltr"><div><div>I just committed a fix.<br><br>The PNGReadWriter currenlty has a hack to support 16 bits per channel gray scale (with a slow bit poker loop), but not with transparency...<br>- transparency is handled with a palette<br>
- ColorForm only supports depth <= 8<br></div><div>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.<br>
</div></div><div><br>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.<br><br></div><div>It also seems to me that the inversion 255-pixelValue is wrong in the 16 bitsPerChannel bitPoker loop , I did change it.<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-05-09 19:36 GMT+02:00 Yoshiki Ohshima <span dir="ltr"><<a href="mailto:Yoshiki.Ohshima@acm.org" target="_blank">Yoshiki.Ohshima@acm.org</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Fri, May 9, 2014 at 1:14 AM, Bert Freudenberg <<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>> wrote:<br>
> Do we support any 16 bit-per-channel gifs?<br>
<br>
</div>Not sure what you mean by "gifs" (I am specifically talking about<br>
PNGs), but sure, I think Squeak should be able to read a PNG file, as<br>
long as it is a valid one. If it is 16 bits per channel, it should<br>
downscale the depth to 8 and create a 32 bpp Forms. This does happen<br>
in most of the cases, but when the PNG file specifies the transparent<br>
pixel (it is also in 16 bit value), it causes an error.<br>
<span class="HOEnZb"><font color="#888888">--<br>
-- Yoshiki<br>
<br>
</font></span></blockquote></div><br></div></div>