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 implementation.
The following code, when done in a workspace, will clearly demonstrate the issue: ``` blackForm := Form extent: 100@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@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?
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
Best, Karl
On Sun, Aug 9, 2020 at 4:55 AM Eric Gade eric.gade@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 implementation.
The following code, when done in a workspace, will clearly demonstrate the issue:
blackForm := Form extent: 100@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@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?
-- Eric
On Sun, Aug 9, 2020 at 3:25 AM karl ramberg karlramberg@gmail.com wrote:
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
Best, Karl
Hi Karl,
Any idea how to find "where" this is set or happens? If I can track it down, I can compare to Pharo (which doesn't seem to have the issue I'm describing) and see how they deal with it.
For anyone else interested in the problem / example I posted, I can supply a changeset that really breaks out the LZW/GIF compression and decompression stuff so that it's somewhat easier to step through. This is part of the work I did refactoring the current implementation, which is hard to follow.
On 2020-08-09, at 12:24 AM, karl ramberg karlramberg@gmail.com wrote:
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
Yup. It was done that way a loooooooooong time ago for what seemed like good reasons at the time. Digging through the maillist archives probably more than 20 years would find the discussions.
I suppose the question is whether it is really still a good idea, and if not, could we fix it?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim If you don't pay the exorcist do you get repossessed?
Hi, See this thread: http://forum.world.st/Color-black-vs-Color-transparent-td4909167.html
Best, Karl
On Sun, Aug 9, 2020 at 6:47 PM tim Rowledge tim@rowledge.org wrote:
On 2020-08-09, at 12:24 AM, karl ramberg karlramberg@gmail.com wrote:
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
Yup. It was done that way a loooooooooong time ago for what seemed like good reasons at the time. Digging through the maillist archives probably more than 20 years would find the discussions.
I suppose the question is whether it is really still a good idea, and if not, could we fix it?
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim If you don't pay the exorcist do you get repossessed?
squeak-dev@lists.squeakfoundation.org