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.decode_headers() {
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