Parsing multiple images from a blob of data

I’m trying to see how to use the juce::ImageFileFormat functions to create multiple juce::Image objects from one blob of data in memory.

As background, I’m trying to load cover art from tags in an aac file. The covr atom can hold multiple images.

I’m currently calling juce::ImageFileFormat::loadFrom with the data blob and its entire size. I know there are multiple images inside, but I don’t know where the first one ends and the next one begins (or I could call juce::ImageFileFormat::loadFrom again with the appropriate offset and size).

If I can somehow learn the size of the image (in raw bytes from the original memory blob) that loadFrom found, I’d have enough info to call it again.

I’m not sure whether adding accessors to juce::Image for that makes sense, or there’s some way to get loadFrom to construct multiple objects.

Is this a new problem? Anyone else have any strategies for solving this?



You might be able to do it with a MemoryInputStream… That’s assuming the image loaders leave the stream positioned at the end of the data which they actually used (although that might not necessarily be the way all the format readers work).

Doesn’t seem to work. After reading the first image, the stream is positioned at the end. The reason seems to be in juce_JPEGLoader.cpp:

Image* juce_loadJPEGImageFromStream (InputStream& in) throw() { MemoryBlock mb; in.readIntoMemoryBlock (mb);
This reads the whole stream into a memory block.

Any idea how to reposition the stream properly in juce_loadJPEGImageFromStream?

Thanks for your help.


Just reposition the stream before you load from it.

Sure, but to where? Seems like the code in juce_JPEGLoader.cpp knows where. Is there a way to determine many bytes of compressed data are in the image from info in the Image object?

The JPEG stream size isn’t written in the JPEG stream.
You’ll have to find the start marker (“0xFF 0xD8”) or the end marker (“0xFF 0xD9”) in the stream for what you need.

I think it’s slightly easier than that. Turns out the data I was trying to parse only has one image in it, but the addition of:

after the jpeg_finish_decompress call seems to do the right thing.

Ok, I don’t mind adding that to the code.