Is the sanity check (line 427 in exif.cpp) on proper end marker of the jpeg-file necessary?

[jonolafur]

First up: Thanks for this project!

Tried the demo on a few of my own images from my phone and it chocked on the third one I tried. The reason was the end marker sanity check (line 427 in exif.cpp). I checked the image file in a hex editor and the last 100 kB or so are zero (as you indicate in your comments), but the zero padding does indeed not start with the (required?) 0xFFD9. The image can be viewed on the phone as well as when clicking on it in dolphin. So, I think I have an image file, which is somehow corrupt or at least not formally correct, but somehow seems to work.

I removed the sanity check and my images are now correctly parsed. I also successfully executed your tests without the sanity check.

Since we are in principle only interested in the metadata-part, do we real care about the image itself?

[csjune]

@jonolafur I think this is a bug of easyexif. A section between EOI and EOF can be filled with any values except 0xFFD9. But here https://github.com/mayanklahiri/easyexif/blob/master/exif.cpp#L428, easyexif only checks 0x00 and 0xFF.

[sfuchs79]

I made the same experience with Subsurface which is a tool using exif.cpp. I also had images where exif.cpp failed to read the Exif data only because the sanity check for EOI complained about my files not being JPG. After removing the EOI check everything works perfectly.

I also think about disabling the sanity check for EOI and just keep the check for SOI.

What are your ideas meanwhile?
Simply remove the check or change it to be more tolerant?

[mturkia]

Looks like some cameras add a trailer to the end of JPG images. This should be taken into account. E.g. ExifTool has implemented parsing/identification of the trailer:

https://github.com/alchemy-fr/exiftool/blob/master/lib/Image/ExifTool.pm#LC5098