Skip to content

A bunch of broken images, and escape hatches that "*fix*" them #257

Description

@MoSal

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
  # ...
fi

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:

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:

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions