Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
1.4
-
None
-
None
-
None
Description
Unfortunately, I cannot share the two JPEG images that trigger this bug report but JPEGFile from the image loaded framework is too strict about the record structure for some JPEGs. Two cases:
1. One JPEG simply has multiple 0xFF pad bytes before the actual record marker. These are legal and just need to be skipped.
2. I got a JPEG file that has an XMP packet embedded. Its record length shows the actual number of the bytes for the packet but that doesn't match the number of bytes until the start of the next record. The only thing that can be done here is to continue reading until the first 0xFF record marker which is not perfect but much better than to fail immediately with an IOException as happens now ("Stream not positioned at a marker segment header").