Hacker News Reader

Comment by nneonneo | Hacker News Reader

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.

View on HN

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.

MPEG4 supports interactive 3D scenes (read: games!) via bit-encoded VRML which can include JavaScript. I don't know any software which support this features (even without interactivity), but it is here.

I'd wrote reader for this bit encoding many years ago when company I'd been employed at made custom VRML engine for Samsung featurephones (project was dead on arrival as at this moment smartphones / Android become available and all this lineage of featurephones was killed).

> 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.

> 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?

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.

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

Zip and PNG bombs have been around for a while: https://github.com/0x48piraj/gz-bomb https://libpng.sourceforge.io/decompression_bombs.html

You can also have a zip that decompresses to itself: https://research.swtch.com/zip

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

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.

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?

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.

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.

Reply on news.ycombinator.com