bad jpg causes assertion failure in upsample()

[rtmrtmrtmrtm]

The attached JPEG file, when loaded by the program below and zune 0.5.0-rc1, causes this assertion failure:

% xxzune/target/debug/xxzune zune1a.jpg thread 'main' panicked at /usr/rtm/.cargo/registry/src/index.crates.io-6f17d22bba15001f/zune-jpeg-0.5.0-rc1/src/worker.rs:412:13: assertion left == right failed left: 256 right: 128 stack backtrace: 0: rust_begin_unwind 1: core::panicking::panic_fmt 2: core::panicking::assert_failed_inner 3: core::panicking::assert_failed at /wrkdirs/usr/ports/lang/rust/work/rustc-1.77.0-src/library/core/src/panicking.rs:297:5 4: zune_jpeg::worker::upsample at ./.cargo/registry/src/index.crates.io-6f17d22bba15001f/zune-jpeg-0.5.0-rc1/src/worker.rs:412:13 5: zune_jpeg::mcu::<impl zune_jpeg::decoder::JpegDecoder>::post_process at ./.cargo/registry/src/index.crates.io-6f17d22bba15001f/zune-jpeg-0.5.0-rc1/src/mcu.rs:410:17 6: zune_jpeg::mcu::<impl zune_jpeg::decoder::JpegDecoder>::decode_mcu_ycbcr_baseline at ./.cargo/registry/src/index.crates.io-6f17d22bba15001f/zune-jpeg-0.5.0-rc1/src/mcu.rs:199:13 7: zune_jpeg::decoder::JpegDecoder::decode_into at ./.cargo/registry/src/index.crates.io-6f17d22bba15001f/zune-jpeg-0.5.0-rc1/src/decoder.rs:712:13 8: zune_jpeg::decoder::JpegDecoder::decode at ./.cargo/registry/src/index.crates.io-6f17d22bba15001f/zune-jpeg-0.5.0-rc1/src/decoder.rs:209:9 9: xxzune::main at ./xxzune/src/main.rs:21:15 10: core::ops::function::FnOnce::call_once at /wrkdirs/usr/ports/lang/rust/work/rustc-1.77.0-src/library/core/src/ops/function.rs:250:5

use zune_jpeg::zune_core; use std::fs::File; use std::io::BufReader; use std::env; fn main() { let args: Vec = env::args().collect(); let str1 = File::open(&args[1]).unwrap(); let str = BufReader::new(str1); let options = zune_core::options::DecoderOptions::default() .set_strict_mode(false) .set_max_width(usize::MAX) .set_max_height(usize::MAX); let mut decoder = zune_jpeg::JpegDecoder::new_with_options(str, options); match decoder.decodeheaders() { Ok() => { match decoder.decode() { Ok() => println!("decode ok!"), Err() => println!("decode failed!"), } }, Err(_) => println!("header error!"), } }

[etemesi254]

Acknowledged, working on a fix

[fpgaminer]

Just ran into this issue as well.

Problematic example attached (sha256 hash: f1cc47440aa4d4314e53ad3f09878515be839d6c18c6cf2d612a4b537425e49a)

[etemesi254]

Hi @fpgaminer , your image issue was fixed it should work in the latest version

[fpgaminer]

Hi @fpgaminer , your image issue was fixed it should work in the latest version

@etemesi254 Thank you so much! I have a dataset of about 8M images I'm working with and that patch fixed all those panics.

There were 16 images causing this panic which all seem to decode now using git HEAD. Most match PIL's decoding within a reasonable margin of error (<1.0 MAE).

However two images decoded using git HEAD do not match PIL and have visible artifacts in the decoded result. MAE is 4.1 and 15.7. The images look fine using PIL, Firefox, and macOS preview. jpeginfo -c reports no errors.

Here is a crop showing the decoding artifacts (Original JPEG was decoded using git HEAD, resulting pixel buffer was saved out as PNG, and then cropped to show the artifacts):

Both, unfortunately, are mildly nsfw so they won't be attached.

[etemesi254]

hi @fpgaminer , you can share the images via email(etemesicaleb@gmail.com) otherwise there's no way I can be of help

Also would be nice if you see whether the artifacts came with new versions or were always there, helps in bug hunting

[mqudsi]

Not a bad jpeg as far as I can see, but the attached causes a panic in zune-jpeg when decoding (via image-rs 0.25.1).

fail.zip

Edit: maybe I misread the sequence of posts, this has already been fixed? It would be great to get a bugfix 0.4.x release for the sake of the image crate.

[etemesi254]

Made a release with fixes

0.4.13 0.5.0-rc2 contain fixes for the bugs above