<div dir="ltr">After further fixes i tested these forms successfully:<br><br><br>#(<br>pal_bk pal rgba8_bk rgba8 rgba16_bk rgba16<br>rgb8_t_bk rgb8_t rgb16_t_bk rgb16_t <br>gray8a_bk gray8a gray16a_bk gray16a<br>gray8b_bk gray8b gray16b_bk gray16b<br>
pal_bk_notrns palb<br>)<br> do: [:e |<br>(ImageReadWriter formFromStream: (&#39;<a href="http://entropymine.com/jason/testbed/pngtrans/">http://entropymine.com/jason/testbed/pngtrans/</a>&#39;,e,&#39;.png&#39;) asUrl retrieveContents contentStream) asMorph openInWorld].<br>
<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-05-10 12:36 GMT+02:00 Nicolas Cellier <span dir="ltr">&lt;<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>&gt;</span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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 &lt;= 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 &lt;= 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">&lt;<a href="mailto:Yoshiki.Ohshima@acm.org" target="_blank">Yoshiki.Ohshima@acm.org</a>&gt;</span>:<div>
<div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Fri, May 9, 2014 at 1:14 AM, Bert Freudenberg &lt;<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>&gt; wrote:<br>


&gt; Do we support any 16 bit-per-channel gifs?<br>
<br>
</div>Not sure what you mean by &quot;gifs&quot; (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><font color="#888888">--<br>
-- Yoshiki<br>
<br>
</font></span></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div>