You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
The 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:
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
:The total number of potentially broken, but at least partially decode-able (by
djpeg
) images was 74, 27 of whichjpeg-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:broken_images.zip
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:
Note that the potentially redundant component-fall-back escape hatch fixes 3 images if the following escape hatch is not applied.
The text was updated successfully, but these errors were encountered: