Error: "use of unset quantization table"

[ArturKovacs]

The attached image fails to load with the following error.

Decoding(DecodingError { format: Exact(Jpeg), underlying: Some(Format("use of unset quantization table")) })

desktop.zip

This was orignially posted to https://github.com/ArturKovacs/emulsion/issues/35

[ArturKovacs]

Multiple fixes have been implemented in image-rs crates that were reported through emulsion, for which I'm really happy 😊 Now I'm on a mission to include all these in the next release of emulsion and it made me curious if there's been any progress made with this. @HeroicKatora

[HeroicKatora]

No progress in the form of PR yet, unfortunately. The cause does not seem nearly as obvious to me as the png errors, a format with which I have more experience.

It has been suggested to me that jpeg-decoder is quite strict with the order of markers it expects and it might need to relax this order. In particular, we expect all quantization tables (DQT) before the first scan header (SOS), but they might be interleaved and only be required before the last scan header which produces the dequantized form of all rows from the coefficients decoded from the earlier data. This is an educated guess, of sorts.

[lovasoa]

Hello, I cannot reproduce the error with the given file (desktop.jpg, sha1: 58902cedf28ca0fed0171e1f18c527346254f354). The file is decoded without errors by jpeg-decoder (tested on e2d3aa2da35333fa8d049ddfa87bb5926ed1d0d9). @ArturKovacs, are you sure you joined the right file ?

[lovasoa]

@HeroicKatora I wanted to test your hypothesis so I manually created a file with a quantization table defined after the first Start Of Scan (but before the last). jpeg-decoder indeed fails to open it, but so do all the other jpeg decoders I tested.

[ArturKovacs]

@lovasoa This is super strange. When I use image::open(&path) in a speparate little test project, it loads the image without an error and I can save the image as a png correctly. When I use the same function in the emulsion source, it returns the error stated above. Both use image "~0.23.4" which should exactly match to 0.23.4 as that's the latest. The path is also exactly the same. Emulsion does open images in a separate worker thread so I tried running image::open in a new thread but it still succeeds every time in the test program. I have no idea what's going on :D

[HeroicKatora]

@ArturKovacs Have you compared the exact version numbers of all selected libraries? Keep in mind that for a program the Cargo.lock files means you don't automatically get the newest version while in the case of a library, or when you create a new program, cargo resolves the crates to their newest compatible versions. Maybe this was fixed in a previous version, possible with the marker segments fixes of 0.19?

[ArturKovacs]

That was exactly the resolution to the mystery, @HeroicKatora. The Cargo.lock referred to an earlier version of jpeg-decoder. Deleting the lockfile and building emulsion solved the issue. Well, I learned something today.

I think this can be closed as this is fixed in 0.1.19.