4 ms·

That JPEG XL prime computation is a pretty ugly DoS. Just selecting it in Finder, with the preview pane open, maxed out every core on my Mac inside a QuickLookS

That JPEG XL prime computation is a pretty ugly DoS. Just selecting it in Finder, with the preview pane open, maxed out every core on my Mac inside a QuickLookSatellite that also ate 4GB of RAM while doing so - for a good 15 seconds. Not bad for a 2KB picture. It seems like Apple did not set sane limits on their JXL previewer. It is, however, an incredibly cool demo of what the format is capable of. I'm not completely sure if an image format should be that flexible, but I'm impressed nonetheless.

est 21d ago
I wonder if similar hacks apply to zlib and .png as well.
- nneonneo 21d ago
  Probably not; for PNG, the image size is declared in the header, so a decoder can decide immediately if it wants to decode the image or not. The output is bounded by the size of the image times the bit depth, and decompression runs in time proportional to output size. zlib bombs exist, but they don't affect png because a decoder can simply refuse to decompress past the size of the pixel buffer.
  - tacomagick 21d ago
    The infamous PIL DOS errors, rooting from the library refusing to process images larger than a hard limit. Does this mean though JXL does not have that data accesible quickly?
    - nneonneo 21d ago
      The problem is that JXL has a ridiculously versatile modular mode which enables high-complexity “prediction” computations. These were designed to encode reusable, custom predictors that could reduce the prediction error and thus the number of bits needed to encode the error. However, the predictors can be abused to perform very complex computations instead. The prime image is only 4kx2k, but encodes a very complex prediction algorithm that happens to generate prime numbers. In principle, a decoder could refuse to process images with predictors above a certain complexity limit, but it’s hard to know how to set such limits accurately.
- wmf 21d ago
  Zip and PNG bombs have been around for a while: https://github.com/0x48piraj/gz-bomb https://github.com/0x48piraj/gz-bomb https://libpng.sourceforge.io/decompression_bombs.html https://libpng.sourceforge.io/decompression_bombs.html
  - est 21d ago
    I mean "mild" bombs where the final output bytes looks normal, a regular sized image, but the decompressing steps takes unnecessarily long, eating CPU or/and RAM
  - eru 21d ago
    You can also have a zip that decompresses to itself: https://research.swtch.com/zip https://research.swtch.com/zip
dylan604 21d ago
When a format has so much flexibility, the world will glom onto the first thing that it solves and put it into the wild to solve that problem. The rest of the capabilities fall by the way side, yet not removed from the format. They're just ignored. MP4 can do so much more than the typical deliverable of a video stream and an audio stream. The spec allows for multiple video streams, multiple audio streams, subtitles, Flash like interactivity to allow self contained DVD style programming of menus to allow for chapter navigation, audio/sub selection, multiangle, etc.
- fc417fc802 21d ago
  > MP4 can do so much more None of that has fallen by the wayside though? I have seen examples of all of those in the wild except for interactive menus and multiangle. Multiple video streams is incredibly rare to encounter but I have run into it a few times. The argument in favor of flexibility (and jxl) is that if you optimize things for the "average" web user (as the essay seems to be suggesting) then fairly mundane usecases require you to start juggling formats, support becomes spotty, and things start breaking. It's nice to have generous limits within which you can be confident that things will "just work" for the end user. Even just on my own system I'd much rather use a single format rather than dealing with app x not supporting format y. tl;dr jxl is the mp4 of image formats and that's exactly why I like it. The only things I agree with the essay about are progressive decoding and decoding speed. Particularly the latter badly needs to be improved.
  - dylan604 21d ago
    > None of that has fallen by the wayside though? And then you go on to state that the use of said features is rare. How is that not fallen by the wayside? They features are still available and can be used. They have not be removed from the format. It's just nobody uses them. That's pretty much the very understanding of fallen by the wayside is it not?
    - fc417fc802 20d ago
      No? If mainstream software handles the features (which mpv, vlc, and ffmpeg do) I wouldn't consider them to have fallen by the wayside. I agreed that three were rare (two I've never personally encountered in the wild) but the rest I consider common. Actually if multiangle is referring to 3D video then I've encountered that one too. It's just that 3D videos are themselves quite rare but I think most software supports them.
lonjil 20d ago
The primary problem with that image is that is has over 60 channels, which means it'll take 20x more time to decode no matter what. Incidentally, the JXL spec suggests that web browsers shouldnt't decode images with so many layers. Jxl-rs will probably start enforcing such limits by default.

est 21d ago

I wonder if similar hacks apply to zlib and .png as well.

nneonneo 21d ago
Probably not; for PNG, the image size is declared in the header, so a decoder can decide immediately if it wants to decode the image or not. The output is bounded by the size of the image times the bit depth, and decompression runs in time proportional to output size. zlib bombs exist, but they don't affect png because a decoder can simply refuse to decompress past the size of the pixel buffer.
- tacomagick 21d ago
  The infamous PIL DOS errors, rooting from the library refusing to process images larger than a hard limit. Does this mean though JXL does not have that data accesible quickly?
  - nneonneo 21d ago
    The problem is that JXL has a ridiculously versatile modular mode which enables high-complexity “prediction” computations. These were designed to encode reusable, custom predictors that could reduce the prediction error and thus the number of bits needed to encode the error. However, the predictors can be abused to perform very complex computations instead. The prime image is only 4kx2k, but encodes a very complex prediction algorithm that happens to generate prime numbers. In principle, a decoder could refuse to process images with predictors above a certain complexity limit, but it’s hard to know how to set such limits accurately.
wmf 21d ago
Zip and PNG bombs have been around for a while: https://github.com/0x48piraj/gz-bomb https://github.com/0x48piraj/gz-bomb https://libpng.sourceforge.io/decompression_bombs.html https://libpng.sourceforge.io/decompression_bombs.html
- est 21d ago
  I mean "mild" bombs where the final output bytes looks normal, a regular sized image, but the decompressing steps takes unnecessarily long, eating CPU or/and RAM
- eru 21d ago
  You can also have a zip that decompresses to itself: https://research.swtch.com/zip https://research.swtch.com/zip

dylan604 21d ago

When a format has so much flexibility, the world will glom onto the first thing that it solves and put it into the wild to solve that problem. The rest of the capabilities fall by the way side, yet not removed from the format. They're just ignored. MP4 can do so much more than the typical deliverable of a video stream and an audio stream. The spec allows for multiple video streams, multiple audio streams, subtitles, Flash like interactivity to allow self contained DVD style programming of menus to allow for chapter navigation, audio/sub selection, multiangle, etc.

fc417fc802 21d ago
> MP4 can do so much more None of that has fallen by the wayside though? I have seen examples of all of those in the wild except for interactive menus and multiangle. Multiple video streams is incredibly rare to encounter but I have run into it a few times. The argument in favor of flexibility (and jxl) is that if you optimize things for the "average" web user (as the essay seems to be suggesting) then fairly mundane usecases require you to start juggling formats, support becomes spotty, and things start breaking. It's nice to have generous limits within which you can be confident that things will "just work" for the end user. Even just on my own system I'd much rather use a single format rather than dealing with app x not supporting format y. tl;dr jxl is the mp4 of image formats and that's exactly why I like it. The only things I agree with the essay about are progressive decoding and decoding speed. Particularly the latter badly needs to be improved.
- dylan604 21d ago
  > None of that has fallen by the wayside though? And then you go on to state that the use of said features is rare. How is that not fallen by the wayside? They features are still available and can be used. They have not be removed from the format. It's just nobody uses them. That's pretty much the very understanding of fallen by the wayside is it not?
  - fc417fc802 20d ago
    No? If mainstream software handles the features (which mpv, vlc, and ffmpeg do) I wouldn't consider them to have fallen by the wayside. I agreed that three were rare (two I've never personally encountered in the wild) but the rest I consider common. Actually if multiangle is referring to 3D video then I've encountered that one too. It's just that 3D videos are themselves quite rare but I think most software supports them.

lonjil 20d ago

The primary problem with that image is that is has over 60 channels, which means it'll take 20x more time to decode no matter what. Incidentally, the JXL spec suggests that web browsers shouldnt't decode images with so many layers. Jxl-rs will probably start enforcing such limits by default.