Displaying animated GIFs in JUCE- issue with CoreImage?

General JUCE discussion
1

So I want to be able to add looping animated GIFs in a JUCE GUI. I saw online that someone else had created a JUCE component to display GIFs so I used a slightly adapted version of this code. In the Projucer, JUCE_USE_COREIMAGE_LOADER is set to ‘Disabled’. On Windows everything works as expected but on macOS I run into some strange issues. The .gif image file loads and shows up but the alpha channel is flipped such that the parts of the image that should be transparent have colored pixels and the parts that should be visible are transparent.
Is there something I’m overlooking in decoding each frame of the animation to a juce::Image object? Is there some special color consideration for macOS that I’m not aware of? Any help is much appreciated!

2

It seems to me, @Mrugalla 's code doesn’t deal with endianness.

When you build the palette, here you would need to diversify:

#if JUCE_BIG_ENDIAN
    palette[i].setARGB(0xff, rgb[0], rgb[1], rgb[2]);
#else
    palette[i].setARGB(rgb[2], rgb[1], rgb[0], 0xff);
#endif

I haven’t tried it, but it might do the trick

1 Like
3

Thanks for the reply, I tried changing readPalette like so (the premultiply parameter is always true):

            bool readPalette (const int numCols, bool premultiply)
            {
                for (int i = 0; i < numCols; ++i)
                {
                    juce::uint8 rgb[4];
                    input.read (rgb, 3);
#if JUCE_BIG_ENDIAN
                    palette[i].setARGB (0xff, rgb[0], rgb[1], rgb[2]);
#else
                    palette[i].setARGB (rgb[2], rgb[1], rgb[0], 0xff);
#endif
                    
                    if (premultiply)
                        palette[i].premultiply();
                }
                return true;
            }

Now the pixels all have a light blue tint and the image is semi-transparent, but the same issue with visible parts being transparent remains. Could it be an issue with colors getting saved to the wrong indeces in the palette?

4

Ok, I double checked the setARGB method and what I did wouldn’t work, because internally this method is already different depending of the Pixel type.

So the fix is needed in loadImage, where the palette is looked up, but casted to a quadruple.

I think here the components of the colour are in the wrong order.
From a performance standpoint it would be nice to find a fix for the palette to hold the colours already in the right order. But the quicker test might be to reverse the colours in that line.

Good luck

1 Like
5

Thanks for the tip, I tried all 24 permutations of the four bytes and no luck. This is the GIF I’ve been trying to use for context.
default_animated
It renders with a big gap in the center that grows alongside the outer edge, here’s a screenshot of it

broken-gif
broken-gif564×586 4.37 KB

Could there be some other problem with decoding the LZW compression? I’m reading up on it now but I don’t see what could cause this type of issue.

6

I downloaded the repo and added your gif, except the white background it worked out of the box…
Running M1 and Ventura 13.2.1

1 Like
7

Hm strange, I’m running Intel and Monterey 12.5.1. Well, it was about time to update to Ventura anyway I guess I’ll try that

8

I updated to Ventura (13.3) and I’m on JUCE 7.0.4, still get the same issue. According to a brief Google search Intel and Apple silicon both use little-endian. Gonna just read more about LZW and the GIF format, but if anyone has experience with this issue or can see a mistake I’m making please let me know.