jpeg: decoder parity stack (post-#590)

[hjanuschka]

Depends on #590.

• Adds standalone JPEG decoder + regression fixtures
• Progressive scan handling
• SIMD YCbCr/BGRA and IDCT parity
• Libjpeg-turbo parity references (scaled + 12-bit)
• Chromium integration sample under samples/chromium_integration

Tests:

• cargo test -p jxl --features jpeg-reconstruction test_libjpeg_turbo_ -- --nocapture

Notes:

• Idea related to Feature request: JPEG decoding #513
• This PR is exploratory; not yet sure whether it should be kept or killed, might be a libjpeg-turbo replacement in chromium some day, or just a closed pr in the endless space!

[goodusername123]

while interesting I do feel like this is a bit out of scope for jxl-rs for a few reasons:

1. JXL only supports a subset of the de-facto JPEG spec/standard (some examples being no chroma sub-sampling modes besides 4:4:4 4:2:0 4:2:2 and no support for RGB outside of 4:4:4) so having a JPEG decoder that supports more of JPEG then JXL does feels a bit weird.
2. Matching the decoded output of libjpeg-turbo (or any other JPEG decoder for that matter) is a non-goal. For example libjxl decodes in a way that is compliant with how the JPEG spec defines images get decoded but different from what libjpeg-turbo outputs since the JPEG spec has/gives a bit of leeway as to how a decoder should produce pixels.

[jonnyawsom3]

See libjxl/libjxl#455 and libjxl/libjxl#1470 (comment)

As Username said, while theoretically possible, I'd say it's out of scope for now. There's been many discussions about it in the past, but other things take priority. jpegli already exists as a replacement JPEG library based on libjxl

[hjanuschka]

ok thank you folks! lets close it!