On Tue, Oct 16, 2018 at 3:17 PM Bert Freudenberg <bert at freudenbergs.de>
wrote:

> On Tue, Oct 16, 2018 at 10:29 AM <patrick.rein at hpi.uni-potsdam.de> wrote:
>
>> Hi all,
>>
>> the change is reverted now but I would like to document our findings and
>> our insights for future changes.
>>
>> From Berts mail I gathered that the 255-0-0-0 to be transparent is
>> required for 16bit -> 32bit conversion to work. As this has been around for
>> quite some time some code relies on it. At the same time this regularly
>> leads to problems when working with images loaded from external sources.
>> For example, loading a PNG and using collectColor: to recolor it does not
>> work if the PNG includes pure rgb black pixels. For this to work we would
>> have to map pure black to Squeak Form black on loading and reconvert it on
>> storing. This would however destroy information as we can not distinguish
>> between 0-0-1 and 0-0-0 anymore. The other way to go would be to change the
>> 16bit -> 32bit conversion to set alpha explicitly, but I do not know
>> whether that is actually possible efficiently.
>>
>> Are there other aspects which I am missing? Is it likely for external
>> packages to heavily rely on this functionality?
>>
>
> I didn't say you need to revert this change ;)
>
> I was only explaining where the odd convention comes from.
>
> Now, early in the dev cycle is a good time to try this. There are
> certainly other places that need clean up (e.g. isTransparent).
>
> If we can limit the odd color treatment to the 16 bpp case (and only do it
> when between 16 and 32) I'd be pretty happy.
>

+1.  Why don't we reinstitute the change in trunk and fix as required?

- Bert -
>

_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20181016/c1331bbf/attachment.html>