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.

▲

dylan604 7 hours ago | parent | next [-]

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.

	▲	blacklion 25 minutes ago \| parent \| next [-]
		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).
	▲	fc417fc802 3 hours ago \| parent \| prev [-]
		> 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.

▲

est 9 hours ago | parent | prev [-]

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

▲

wmf 8 hours ago | parent | next [-]

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

	▲	eru 6 hours ago \| parent \| next [-]
		You can also have a zip that decompresses to itself: https://research.swtch.com/zip
	▲	est 6 hours ago \| parent \| prev [-]
		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

▲

nneonneo 9 hours ago | parent | prev [-]

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 8 hours ago | parent [-]

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 8 hours ago \| parent [-]
		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.