[squeak-dev] GIFs and the Color black
karlramberg at gmail.com
Sun Aug 9 07:24:42 UTC 2020
I think Color r: 0.0 g: 0.0 b: 0.0 was/is reserved for transparency in
forms with less than 32 bit depth, eg. no alpha channel
On Sun, Aug 9, 2020 at 4:55 AM Eric Gade <eric.gade at gmail.com> wrote:
> Hi all,
> I've noticed that in the current implementation of GIFReadWriter, we
> cannot faithfully reproduce the color black when writing it and reading it
> back in. Quick note: before I rewrote large parts of the GIF stuff in Pharo
> a while back, it had the same implementation as Squeak. But both then and
> now, Pharo does not have the problem that I am describing. This leads me to
> believe that the problem is actually at some low level that I'm not
> equipped to understand.
> I'm hoping that the collective wisdom on this list might have some ideas.
> I'm thinking there's something going on with color mapping and Bitmaps
> (maybe color depths and conversions as well?) which I don't understand very
> well. On the other hand, I do have a good understanding of the GIF format
> since I worked on it. The LZW compression is a real nightmare, and even in
> my Pharo rewrite I had to keep the LZW encoding portions from the original
> The following code, when done in a workspace, will clearly demonstrate the
> blackForm := Form extent: 100 at 100.
> blackForm getCanvas fillColor: Color black.
> "Write to a bytestream"
> out := WriteStream on: ByteArray new.
> writer := GIFReadWriter on: out.
> writer nextPutImage: blackForm.
> writer close.
> "Read from the bytestream"
> in := ReadStream on: out contents.
> reader := GIFReadWriter on: in.
> result := reader nextImage.
> (result colorAt: 50 at 50) inspect.
> The resulting color is not what we expect (Color black). It is (Color r:
> 0.0 g: 0.0 b: 0.004)
> Any ideas what's going on?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev