unknown JPEG marker e1

[hisham]

I'm getting this error when attempting to resize a particular jpeg. Unfortunately I'm unable to share the photo for privacy reasons.

"errorType": "Error",
"errorMessage": "unknown JPEG marker e1",
"methodName": "constructor",
"stack": [
"Error: unknown JPEG marker e1",
" at constructor.parse (/var/task/node_modules/jpeg-js/lib/decoder.js:825:19)",
" at Object.decode [as image/jpeg] (/var/task/node_modules/jpeg-js/lib/decoder.js:1096:11)",
" at Jimp.parseBitmap (/var/task/node_modules/@jimp/core/dist/utils/image-bitmap.js:196:53)",
" at Jimp.parseBitmap (/var/task/node_modules/@jimp/core/dist/index.js:431:32)",

[patrickhulce]

Thanks for filing @hisham! Unfortunately if we don't have a known valid JPEG to examine that reproduces this issue, we won't be able to do much :/ (this error can be reproduced in a number of ways and would be expected on malformed input)

[hisham]

Hi @patrickhulce - ok I sent you the image to your gmail you have on https://github.com/patrickhulce. Please don't post the image here or put it in the repo. Thanks!

[patrickhulce]

Thanks for the image @hisham!

This image was indeed malformed. An app data segment was annotated with 0x00E1 instead of the correct 0xFFE1. The byte region before this marker appears to have been overwritten with 0s, so I'm guessing whatever processed this has an off-by-1 error and accidentally overwrote the marker data instead of stopping at the previous app data segment boundary.

In principle given the stage and resource constraints of this package, we can't really add workarounds for any recovery situation that comes along (even if larger JPEG decoding projects can). If there's more evidence that this is very widespread and a particular camera or popular JPEG encoder is always producing malformed JPEGs like this then we can consider implementing a workaround, but from the data I saw it appears to be a post-processing application error.

EDIT: Anyone feel free to chime in with such evidence and we'd happily reopen!

[hisham]

Ok sounds good. If I see many images with this issue will let you know.

[hisham]

fyi, I got another these photos from the wild causing exact same issue. Both photos appear to be from Android device. This particular one's file name starts with "PXL" so it's coming Google's Pixel Camera app I believe: https://9to5google.com/2020/08/20/google-camera-7-5-pxl/

Here's the exif on the photo:

[hisham]

Just ran into this again @patrickhulce with another user. From Google Pixel 4 XL camera. Here's the exif data according to photoshop. Two photos taken with the front camera from same user - both have same issue. I think we should re-open this issue. And I'm going to try to find someone with a Pixel 4 XL to reproduce.

[patrickhulce]

Alright @hisham if you're able to get a consistent reproduction with a Pixel camera and an innocuous image we can add to the test suite, we'll gladly accept a narrow workaround PR :)

[hisham]

Ok here's an example image that reproduces the issue. @patrickhulce read below for more details. If you're ok with my way of reproducing this bug and the image below that I can add to the test suite, I'll get someone on my team to work on a fix and submit a PR. Please let me know, thanks! :)

So I looked at the exif htmldump of one of my known bad images, generated via https://exiftool.org/htmldump.html.

And I noticed the problematic marker is related to the APP1 XMP Segment - the exifdata tool marked that area as "unused 355 bytes".

I then googled around and found this comment about XMP Segment and a sample image from Android that contains it.

The image in the comment worked fine in jpeg-js though.

I looked at the difference in APP1 XMP Segment between my bad image and the good image, and noticed there was no "FF" before the "E1".

So I modified my bad image via a hex editor and put a F1 before the E1. Jpeg-js was able to process the image just fine.

So I took the sample image posted here and opened it in hexeditor and replaced F1 before the E1 with 00.

I then was able to reproduce the jpeg-js issue plus the "unused bytes" that the exiftool html dump showed.

[patrickhulce]

If you're ok with my way of reproducing this bug and the image below that I can add to the test suite, I'll get someone on my team to work on a fix and submit a PR. Please let me know, thanks! :)

Sounds great! :)

So I took the sample image posted here and opened it in hexeditor and replaced F1 before the E1 with 00.
I then was able to reproduce the jpeg-js issue plus the "unused bytes" that the exiftool html dump showed.

Yep, this is exactly what I found when looking at the image you sent privately as well. The "unused bytes" interpretation is a nice one, I think a decent jpeg-js workaround could be "If an unrecognized marker starts with 00, scan until a recognized marker is found and set a recovered flag. Throw if we reach a second unrecognized marker while recovered is true."

[patrickhulce]

fixed by #84 and published in 0.4.3, thanks!