fix: handle 0x00E1 / 0x00E0 segments from Pixel phones

[AT41]

Original Issue: #82

I believe that the 0x00e1 bytes are not malformed, because in the 2nd picture of #82 (comment) the .jpg files already have an 0xffe1 segment. It seems to be a custom but unused segment, and it can be safely skipped over since the next 2 bytes indicate the size of this unused segment.

It might not be entirely related, but I took photos using a Pixel 4 XL emulator using Android Studios, and a similar "Unknown JPEG marker e0" exception error occurred when I tried to decode them.

This PR will skip over 0xe1 and 0xe0 segments while decoding.

[patrickhulce]

Thanks very much for the contribution @AT41 ! 🎉

because in the 2nd picture of #82 (comment) the .jpg files already have an 0xffe1 segment

This shouldn't be an indication of marker validity. Most images can and will have several APP1 segments of various types of metadata.

it can be safely skipped over since the next 2 bytes indicate the size of this unused segment.

For these particular pixel images they can be, but not generically. I'd prefer if the handler for these 0-padded markers would set a flag that referenced this recovery pattern.

I believe that the 0x00e1 bytes are not malformed

I'm not sure what to say here other than this file simply isn't a true valid JFIF :) (in several other ways as well, not just this one, there is no APP0 segment after SOI and no JFIF declared version either). Given the number of deviations from JFIF I might agree with your assessment that they're not trying to be valid and just shaving bytes wherever possible in a way that is still parseable by most decoders. The malformed segments in these example JPEGs are clearly supposed to be APP1 XML segments which are 0xFFE1 in the JFIF spec and the "unused bytes" label is the result of the way other JPEG decoders decide to handle the malformed segment, which is simply ignore it completely.

[patrickhulce]

what about moving this into default block and something like...

// Recover from malformed APP1 markers popular in some phone models.
// See https://github.com/eugeneware/jpeg-js/issues/82
if (data[offset - 2] === 0x00 && data[offset - 1] === 0xE1) {
  const nextOffset = readUint16();
  if (data[nextOffset] === 0xFF) {
    offset = nextOffset;
    break;
  }
}

[AT41]

Totally agree with you. In hindsight I should have seen that some of the files contained more than 1 0xFFE1 segment header and concluded that they aren't unique. Headers should also always start with 0xFF according to the JFIF standards, so you make a good point that 0x00E1 is definitely an error.

I've implemented the changes and added a new error that specifies the locations of 2 malformed headers like 0x00E1. Let me know if there's anything else that can be improved!

[patrickhulce]

LGTM, thanks again for the contribution and the flexibility in response to review! :)