DHT marker: no Huffman table found

[ilya-fedin]

Describe the bug
Failing to decode the following image with jpegli: photo_2024-05-21_21-56-01.zip

To Reproduce
Try to decode the mentioned image with jpegli

Expected behavior
Image is decoded

Environment

• OS: Linux
• Compiler version: GCC 12
• CPU type: x86_64
• cjxl/djxl version string: I don't have cjxl/djxl... But I used v0.10.2 tag to build jpegli.

[j7nj7n]

This is the same bug as here: #3604

An empty huffman table seems to mean "use the last".

There are blank tables at 0x00002763 and 0x0000320A for refinement in progressive scans.

[eustas]

Once a quantization table has been defined for a particular destination, it replaces the previous tables stored in that
destination and shall be used, when referenced, in the remaining scans of the current image and in subsequent images
represented in the abbreviated format for compressed image data. If a table has never been defined for a particular
destination, then when this destination is specified in a frame header, the results are unpredictable.

With some fantasy, we can say that not defined Huffman table does nothing, but... Figure B.7 – Huffman table syntax does not allow DHT markers without payload...

[ilya-fedin]

mozjpeg (which apparently means libjpgeg-turbo too) can decode it just fine

[jonsneyers]

This is related to #2704

Strictly speaking, the JPEG file is not conforming to the JPEG spec (since DHT needs to have "one or more" tables). The current jbrd spec has no way of representing the reconstruction data for this JPEG file (since our encoding implicitly assumes that there will be at least one).

But many JPEG decoders do allow this case, e.g. libjpeg-turbo djpeg -strict is not even producing a warning for this, let alone refusing to decode it. And we can make it work in jbrd too (see #2704), although it does require an update to the jxl spec and to libjxl.

@veluca93: I made this proposal because #2542 was complaining about this. Back then we decided to take no action yet, since we had only one issue report so we had no idea how common this problem is. Now we also have this report here (#3597) and also #3604. So that's three independent instances of the problem (as far as I know, at least the reports are coming from different people). I would argue that we can now assume that this case happens in enough cases to make it worth addressing the issue. Especially because it can be fixed without causing major interoperability trouble (the worst thing that can happen is that you receive a jxl file that you can view but you cannot reconstruct it to a jpeg file without upgrading your djxl version).

[ilya-fedin]

Will libjxl fix affect jpegli? As my problem is with jpegli, not jxl.

[filipe-luis]

I've faced the same issue with jpegli. @jonsneyers Do you know when this is expected to be addressed? Thank you

[ilya-fedin]

Do you know when this is expected to be addressed?

Looking at the mentioned PR they disagree this is a bug and don't plan addressing this