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


#1

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).


#2

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).


#3

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.


#4

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.


#5

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