Hacker News Reader

Comment by pornel | Hacker News Reader

That's not a replacement nor a competitor for the popular "JPEG" format. The only commonality here is that it's coordinated by the Joint Photographic Experts Group.

You'll never see JPEG-XS images stored on disk or sent over the web. This is a special-purpose format for video signals on the wire (e.g. for transmission between your graphics card and a 4K monitor). Currently if your cables don't have enough bandwidth for the full uncompressed RGB signal, you get lower FPS, or lower bit precision, or subsampled YCbCr. This is an attempt to make something a bit smarter and apply cheap nearly-lossless compression on the fly instead.

View on HN

This is generally called "mezzanine compression" [1], aiming at <10x reduction over uncompressed streams. Here's a PDF with more details on JPEG-XS: https://www.ibc.org/download?ac=3823

> "4K / 60p / 422 / 10 bits. throughput: 10.8 Gbit/s. link: 3G-SDI available throughput: 2.65 Gbit/s compression ratio: ~4"

[1]: https://www.deltacast.tv/technologies/mezzanine-compression

I'd point out that DisplayPort includes "Display Stream Compression", which is "visually lossless" (aka lossy) compression for display cables. So we are not talking some far-future thing, but something that is actually already being deployed (in some form) on the field.

How widely deployed is that display stream compression?

Not very widely-- it's not really necessary for 4K@60 over many standard links, and 8K is very rare. https://www.pcworld.com/article/3187336/displays/more-high-e...

>You'll never see JPEG-XS images stored on disk or sent over the web.

I don't see why not. The image quality is near perfect, according to the article, for not even double the average file size, and it uses much less energy to encode and decode, so it's better for your battery life on mobile devices.

Because this would be at least 5 times slower to transfer compared to regular image formats, and on mobile a lot of energy goes to power the screen (while user is staring at a blank one, waiting for data) and radios (which now have 5x more work to do).

JPEG XS has severe restrictions of realtime encoding and a 30-line buffer, which are necessary for its goals, but make it a bad choice for anything that doesn't have such limitations.

Is it a bad choice, or an impossible choice?

Because if it’s possible to send one over the web, I would like to see it rendered with my own eyes. Speed be damned.

I think the whole appeal is faster encoding/decoding, but compared to a normal jpeg, it's the same image quality with a larger file size. I could be mistaken, the article is kinda light on actual technical details.

Reply on news.ycombinator.com