search

libjxl / libjxl

JPEG XL image format reference implementation
BSD 3-Clause "New" or "Revised" License
2.39k stars 239 forks source link

DHT marker: no Huffman table found #3597

Open ilya-fedin opened 2 months ago

ilya-fedin commented 2 months ago

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

j7nj7n commented 2 months ago

This is the same bug as here: https://github.com/libjxl/libjxl/issues/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 commented 2 months ago

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 commented 2 months ago

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

jonsneyers commented 2 months ago

This is related to https://github.com/libjxl/libjxl/pull/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 https://github.com/libjxl/libjxl/pull/2704), although it does require an update to the jxl spec and to libjxl.

@veluca93: I made this proposal because https://github.com/libjxl/libjxl/issues/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 (https://github.com/libjxl/libjxl/issues/3597) and also https://github.com/libjxl/libjxl/issues/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 commented 2 months ago

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

filipe-luis commented 2 weeks ago

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

ilya-fedin commented 2 weeks ago

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