<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Aug 2, 2016 at 3:56 PM, marcel.taeumel <span dir="ltr"><<a href="mailto:Marcel.Taeumel@hpi.de" target="_blank">Marcel.Taeumel@hpi.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi, there.<br>
<br>
In Color class >> colorFromPixelValue:depth: we have:<br>
<br>
...<br>
d = 32 ifTrue: [<br>
"eight bits per component; 8 bits of alpha"<br>
r := (p bitShift: -16) bitAnd: 16rFF.<br>
g := (p bitShift: -8) bitAnd: 16rFF.<br>
b := p bitAnd: 16rFF.<br>
alpha := p bitShift: -24.<br>
alpha = 0 ifTrue: [^Color transparent].<br>
(r = 0 and: [g = 0 and: [b = 0]]) ifTrue: [^Color transparent].<br>
alpha < 255<br>
ifTrue: [^ (Color r: r g: g b: b range: 255) alpha: (alpha asFloat /<br>
255.0)]<br>
ifFalse: [^ (Color r: r g: g b: b range: 255)]].<br>
...<br>
<br>
This denotes black to transparent. Is this still right?<br></blockquote><div><br></div><div>It was never "right" but a hack ... Some code treats the pixel value 0 to mean "transparent". In particular (IIRC) 16 bit forms which do not store an alpha value, and 32 bit forms that don't have a proper alpha channel. So they use 0,0,0 to mean "transparent" and "0,0,1" for solid black.</div><div><br></div><div>I don't think there's a good reason for this anymore, since we do have enough memory and computation power to do alpha properly. But since it will break some code I'd suggest starting to fix it only after this release.</div><div><br></div><div>- Bert - </div></div></div></div>