Nothing to handle GIF transparency.
seanparsons opened this issue · comments
My use case is composing a series of images including GIFs, but the issue with this is that JuicyPixels doesn't expose the transparency information that I can see. It would seem like it would've made more sense to have GIF as PixelRGBA8 rather than PixelRGB8.
Do you mean while decompressing?
I can decode it to the series of images, but I don't know for each pixel in each frame what the transparency is. Given the slightly interesting way the GIF format works, it's not even that there would be a single transparency colour.
Ah ok, as the transparency is just a "transparent" color in GIF I didn't bother to make the conversion. I'll put in the todo list.
Do you have an image to share for the test suite?
Is this bit even correct?
https://github.com/Twinside/Juicy.Pixels/blob/master/src/Codec/Picture/Gif.hs#L594-L597
It looks like if the pixel is transparent rather than adding the transparent pixel it looks to the previous frame for what was in that position.
There is no alpha channel in the gif format, it's either fully transparent or fully opaque. For each image, the transparent color is given in its header.
I don't think you read what I said, that code checks if it's outside the bounds and not transparent, if fails either of those checks it falls back to the previous frame. So if I had one full frame with a picture on it and another frame that was the same size and transparent then both frames would contain the picture in them.
That's the intended behavior, it is used by the gif animations to encode only a part of the full image and reuse the background of the previous image, thus saving space in the final image.
I could be misunderstanding the code, so bear with me if I'm wrong I just want to make sure. :)
If a pixel is set to the transparency colour in all cases it will either be the same pixel from the previous image or whatever the background image is at that position.
Yes, that's the idea.
My last commit made some changes to handle gif with transparency by providing a default transparency background, is this working for you? (The change breaks the API, I'll have to bump juicy.pixels to 3.2)
I've rigged it up with add-source, but hilariously in my case it's going for an old version of criterion which is failing to compile. Seems a pain that I can't tell it to ignore the executables.
ah, I usually delete the executable part of the cabal file before releasing, I should put it as a test suite instead.
This looks to work like a treat from what I can tell, cheers for this.