A bunch of broken images, and escape hatches that "*fix*" them #257
Description
Hello. I've been testing a bunch of images from random sources around the internet against some JPEG decoders, and found
a bunch that fail with jpeg-decoder.
An image was considered potentially broken in my scripts if it failed with ffmpeg's -err_detect explode:
if ! ffmpeg -loglevel quiet -nostdin -err_detect explode -i "$l" -f null - &>/dev/null; then
# ...
fiThe total number of potentially broken, but at least partially decode-able (by djpeg) images was 74, 27 of which jpeg-decoder
already decoded without error, so theoretically, the decoder needs both a stricter and a more lenient modes of operation.
The remaining images all fail currently with jpeg-decoder, 27 of which should be safe to share and are attached below:
I managed to "fix" all those images (including the non-sharable ones) with a few escape hatches, available in my fork here:
https://github.com/MoSal/jpeg-decoder/commits/master
Those also "fix" images shared in issues around here like in #251 #229 and #228.
Details about the effects of each escape hatch on the broken images:
marker-loop-alone:
success 9/27
failure 18/27
without-marker-loop:
success 0/27
failure 27/27
without-block:
success 13/27
failure 14/27
without-component-fallback:
success 27/27
failure 0/27
without-marker-bits-read:
success 12/27
failure 15/27
with-all:
success 27/27
failure 0/27
Note that the potentially redundant component-fall-back escape hatch fixes 3 images if the following escape hatch is not applied.