Bug with loading PNG images from web input stream (with PIP to reproduce)

I believe I found a bug with PNG image loading.

After switching to JUCE 5.3.2 and testing some of my applications, I noticed that in one of my applications PNG images that were loaded from a web URL were not appearing any longer.
Saving the PNG file to the local disk and loading it from that local file does still work.
I can’t exactly pinpoint a recent specific version of JUCE where it still worked fine, but I know it still worked fine with JUCE 4.2.3 (but that’s already a while ago…)

I created a PIP to reproduce the behavior (with test files).
See the full bug report here for that:

As I only tested on Windows 10 yet, I am posting this here, but it might also happen on macOS (not sure yet).

Try selecting the specifying the image format directly as it can’t be inferred from the extension. Changing line 99 in your PiP to:

Image image2 = PNGImageFormat().decodeImage(*stream);

works for me (on macOS).

Thanks Fabian! I can confirm this workaround works for me on Windows 10 64-bit as well.

Any idea why this stopped working (never had this fail before)?

I would prefer not to build in a hard format: I am getting these images from somewhere else, not under my control, so the type of image file may change/differ…

When I looked through the code, it appeared that it was correctly detected as being a PNG file, but only in a later step, when the actual data was loaded, things fail (at least that’s what I understood).

Of course, I could wrap this myself in some code that first tries to use the code I had first, and only if that fails, check the extension myself and do the switch based on the extension to use the appropriate image loader directly. From a user-developer I just found it very strange that JUCE can load the exact same image from a file but not if it comes from a URL.

When you ask the image format manager to look for a suitable format, it’ll try each one that it knows about, and each time it’ll try to reset the stream. So if you give it a URL stream, that’s not very good at seeking - perhaps when it tries to reset the stream to re-read it, it fails.

This might have seemed to change for you because of something trivial like the order in which it tries the formats - e.g. if in the past the PNG format was first in the list, this would have been fine. Maybe now it’s second or something?

Workarounds: simplest is to just load the whole stream into a memory block and open that. Or probably just wrapping the stream in a BufferedInputStream would give it the ability to seek enough for it to handle this.

1 Like

Thanks Jules. Using the memory block approach worked just fine.