Nothing to handle GIF transparency. about juicy.pixels HOT 13 CLOSED

Do you mean while decompressing?

from juicy.pixels.

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.

from juicy.pixels.

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.

from juicy.pixels.

Do you have an image to share for the test suite?

from juicy.pixels.

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.

from juicy.pixels.

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.

from juicy.pixels.

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.

from juicy.pixels.

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.

from juicy.pixels.

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.

from juicy.pixels.

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)

from juicy.pixels.

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.

from juicy.pixels.

ah, I usually delete the executable part of the cabal file before releasing, I should put it as a test suite instead.

from juicy.pixels.

This looks to work like a treat from what I can tell, cheers for this.

from juicy.pixels.