JUCE::JPEGFormat.canUnderstand

General JUCE discussion
1

Hi.
In 1.39 this function was changed from

bool JPEGImageFormat::canUnderstand (InputStream& in)
{
    const int bytesNeeded = 10;
    char header [bytesNeeded];

    if (in.read (header, bytesNeeded) == bytesNeeded)
    {
        const String type (header + 6, 4);

        return type.equalsIgnoreCase (T("JFIF"))
                || type.equalsIgnoreCase (T("Exif"));
    }

    return false;
}

to

bool JPEGImageFormat::canUnderstand (InputStream& in)
{
    const int bytesNeeded = 10;
    uint8 header [bytesNeeded];

    if (in.read (header, bytesNeeded) == bytesNeeded)
    {
        return header[0] == 0xff
            && header[1] == 0xd8
            && header[2] == 0xff
            && header[3] == 0xe0;
    }

    return false;
}

My application crashed with new JUCE because I have JPEG image where
header[3] == 0xe1.
As google told me new version JUCE understand JFIF format only.
http://www.obrador.com/essentialjpeg/HeaderInfo.htm
So, I need idea how to resolve it.

2

Your app really shouldn’t have crashed just because an image didn’t load! Very naughty.

As I understood it all jpegs are supposed to start with ff d8 ff e0…? Does the image load correctly if you tweak it to allow header[3] to also be e1?

3

First, sorry for my English. Also, context of my application - viewer of studios photographies and qualitied wallpapers. It’s my closed application. So think about checking for my own photographies didn’t come in my mind. But, you right checking will be welcome.
What about JPEG header, so as I know it starts with 0xFFD8 (Start symbol) and ends with 0xFFD9 (end symbol). Next two bytes after Start have 0xFFE0~0xFFEF and they mark created application. But, more used
0xFFE0 (JFIF) and 0xFFE1 (EXIF).
P.S. Thanks for quick replying and constructive criticism.
With changes to

        return header[0] == 0xff
            && header[1] == 0xd8
            && header[2] == 0xff
            && (header[3] == 0xe0 || header[3] == 0xe1);

Images are loaded correct.

4

Ok, that sounds sensible to me, thanks.