False negative on image with long exif

[olizilla]

This guy (and a bunch of other images on my local filesystem) trigger a false negative from the is-progressive cli:

It was encoded with mozjpeg which enables -progressive by default.
exiftool agrees:

exiftool fixture/curious-exif.jpg | grep Encoding
Encoding Process                : Progressive DCT, Huffman coding

It looks like the optimisation where it checks for a baseline marker and bails early is being triggered by some metadata in the file, before it finds the real encoding marker later on:

baseline / SOF0 marker

$ hexdump fixture/curious-exif.jpg | grep "ff c0"
00003c0 ff c0 00 11 08 00 6c 00 a0 03 01 22 00 02 11 01
0001e20 0c 0c 0c 0c 0c 0c 0c 0c 0c 0c 0c ff c0 00 11 08

progressive / SOF2 marker

$ hexdump fixture/curious-exif.jpg | grep "ff c2"
0005b00 32 32 ff c2 00 11 08 00 89 00 cc 03 01 22 00 02

It also contains sequences of bytes that match the SOS marker that occur before the progressive marker:

start of scan / SOS marker

$ hexdump fixture/curious-exif.jpg | grep "ff da"
0000510 37 47 57 67 77 87 97 a7 b7 c7 ff da 00 0c 03 01
0001f80 87 97 a7 b7 c7 ff da 00 0c 03 01 00 02 11 03 11
0005b30 07 00 08 ff da 00 08 01 01 00 00 00 00 18 9c 7e
0005ce0 04 05 00 ff da 00 08 01 02 10 00 00 00 e7 ec 7c
0005d50 ff da 00 08 01 03 10 00 00 00 e9 e7 5a d6 79 c8

it looks like it progressive marker at 0005b00 is quickly followed by several start of scan markers at 0005b30, 0005ce0 etc. as you'd expect. The irritation is the same sequence of bytes occurs _way _ before then too, defeating the optimisation.

As this is a valid, if a somewhat grubby jpeg, the only solution I can think of is to remove the optimisations... PR to follow.