A new JPEG format(actu.epfl.ch)
actu.epfl.ch
A new JPEG format
https://actu.epfl.ch/news/a-new-jpeg-format-for-virtual-reality-drones-and-s/
49 コメント
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
> "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...
[deleted]
>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.
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.
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.
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.
> A new JPEG format for virtual reality, drones and self-driving cars
The only buzzword missing from that list is blockchain, and I’m sure they would add it if they could.
The only buzzword missing from that list is blockchain, and I’m sure they would add it if they could.
A new blockchain-based distributed image format for virtual reality, drones, and self-driving cars, delivering maximum company synergy with minimal downtime, vis-a-vis cloud dependency concerns
Someone invest in me.
Someone invest in me.
You got a vote, in exchange I want 10% of all your karma for the next year, or your account password retain the possibility of "correcting" the growth path of your account.
Also: shit, you're penniless, why did I invest? Whyy?
Also: shit, you're penniless, why did I invest? Whyy?
Yeah, he has only 40 karma. That's why you gotta do your due diligence. :)
I wonder if it uses machine-learning-AI-neural-networks-blockchain-serverless-as-a-service technology
No deal unless it's also quantum.
So excited for JPEG 2000. It's the future!
So excited for JPEG XR. It's the future!
So excited for JPEG XS. It's
So excited for JPEG XR. It's the future!
So excited for JPEG XS. It's
Interesting concept. That said, I don't think the world needs yet another patent-encumbured image format.
I can't find any references to JPEG-XS patents anywhere. Do you have some more information, or just spreading fud?
I found this: https://encode.ru/threads/2824-JPEG-3000-Anyone?s=79e2301ec5...
>For High-Throughput JPEG 2000 (that is the official name), we have a desire to make this a royalty free standard. For JPEG XS, there is no such desire. The market - professional broadcasting applications - does not have problems with licensing, so it seems very likely that this standard includes IPs. The license costs in broadcasting are minor compared to the hardware costs and the savings you get from a mezzanine codec.
>For High-Throughput JPEG 2000 (that is the official name), we have a desire to make this a royalty free standard. For JPEG XS, there is no such desire. The market - professional broadcasting applications - does not have problems with licensing, so it seems very likely that this standard includes IPs. The license costs in broadcasting are minor compared to the hardware costs and the savings you get from a mezzanine codec.
Thanks very much, this was my curiosity.
Okay everybody, JPEG XS is just software for magic boxes. Nothing to see here, implementing it is pointless.
Actually wait. Argh. What are the patented bits of the encoding process? Now FOSS has to go add those to the "but we can't come up with this" list. Grr.
Okay everybody, JPEG XS is just software for magic boxes. Nothing to see here, implementing it is pointless.
Actually wait. Argh. What are the patented bits of the encoding process? Now FOSS has to go add those to the "but we can't come up with this" list. Grr.
The post that BurningCycles quotes is hardly strong evidence that JPEG-XS is (intentionally) covered by any patents. There is just some random speculation based on "lack of desire to make royalty-free standard", and I'd point out that this comes from someone who is apparently developing a at least somewhat competing standard.
While it is not unreasonable to think that there are patents involved, I would want to hear something bit more definite before making any conclusions or assumptions.
While it is not unreasonable to think that there are patents involved, I would want to hear something bit more definite before making any conclusions or assumptions.
The patent will kill it in its tracks. mp3 is dead now because of the patent (well, also because of streaming).
The open source community tends to provide a lot of the system-level technology for using things like this and I'd expect them to completely ignore a patented format.
The open source community tends to provide a lot of the system-level technology for using things like this and I'd expect them to completely ignore a patented format.
MP3 was arguably among the most successful format in history, surpassed only by html.
If it is dead now, which it isn’t, the patent has nothing to do with that, because it actually just expired.
MP3 becoming less important is simply a result of incremental improvements on its fundamental ideas, like AAP.
If it is dead now, which it isn’t, the patent has nothing to do with that, because it actually just expired.
MP3 becoming less important is simply a result of incremental improvements on its fundamental ideas, like AAP.
I would have to say that jpegs were more successful than mp3s
The MP3 format will outlive every single person posting in this thread. Potentially by an order of magnitude.
I literally just installed WinAmp about 30 minutes ago to listen to my recovered MP3 collection. If I'm going to beat a dead horse, I'm going to do it while really whipping the llama's ass.
You didn't even need to install it! https://webamp.org/
I always have an old version of winamp installed.
The MP3 patents expired last year FYI
In the introduction paper [1], there is no mention of handling of raw images which haven't been turned into RGB. I.e. it assumes an RGB image, not a colour filter array (Bayer) image.
This is odd because the use case for this is sending the image from the sensor, and the de-bayer step would therefore need to be done before the image is sent, which is a lossy step and also can be quite slow and complex to do well, which sort of compromises the point of this effort.
This is very much needed and I appreciate that it's happening. Looking forward to a reference implementation.
[1] https://www.ibc.org/download?ac=3823
This is odd because the use case for this is sending the image from the sensor, and the de-bayer step would therefore need to be done before the image is sent, which is a lossy step and also can be quite slow and complex to do well, which sort of compromises the point of this effort.
This is very much needed and I appreciate that it's happening. Looking forward to a reference implementation.
[1] https://www.ibc.org/download?ac=3823
I'm genuinely not seeing the usefulness here. There's always been a tradeoff between image quality and the rate of compression. What they're basically saying is that they are worsening the compression ratio for better image quality, but they want to be the ones to slap a name on this 'new' paradigm shift? Sure they're also making their own compression scheme, but it doesn't matter all that much. We can pretty much gain the equivalent of what their saying from just streaming images encoded with pre-existing lossless compression schemes like png.
[deleted]
Low-quality, buzzword-filled blogspam for https://jpeg.org/jpegxs/
Some presentations and/or papers:
[1] 'Introduction to JPEG XS - The New Low Complexity Codec Standard for Professional Video Production', Fraunhofer IIS & intoPIX SA, https://www.ibc.org/download?ac=3823 (pdf)
[2] 'JPEG XS, a new standard for visually lossless low-latency lightweight image compression', Fraunhofer IIS, http://publica.fraunhofer.de/documents/N-479925.html (login and/or paywall) (pdf)
[3] JPEG XS workplan from 2016, JPEG, https://jpeg.org/downloads/jpegxs/wg1n71031-REQ-JPEG_XS_Call... (pdf)
Essentially, a low-loss, partially-wavelet video format heavily implied to be applicable for pro video, in the vein of VC-2/Dirac.
Some presentations and/or papers:
[1] 'Introduction to JPEG XS - The New Low Complexity Codec Standard for Professional Video Production', Fraunhofer IIS & intoPIX SA, https://www.ibc.org/download?ac=3823 (pdf)
[2] 'JPEG XS, a new standard for visually lossless low-latency lightweight image compression', Fraunhofer IIS, http://publica.fraunhofer.de/documents/N-479925.html (login and/or paywall) (pdf)
[3] JPEG XS workplan from 2016, JPEG, https://jpeg.org/downloads/jpegxs/wg1n71031-REQ-JPEG_XS_Call... (pdf)
Essentially, a low-loss, partially-wavelet video format heavily implied to be applicable for pro video, in the vein of VC-2/Dirac.
It's just different article aimed at a different audience, it's not in any way 'blogspam'.
It's an article from a school whose faculty member leads JPEG. It namedrops VR, space agencies, 5G; vaguely alludes to some upcoming work, links to nowhere of interest -- it's university press release mixed with quasi-marketing undertones you'd find in a business magazine.
I think we should strive for better sources than this, so I provided some.
I think we should strive for better sources than this, so I provided some.
Striving for better sources doesn't mean misrepresenting sources. The university press release might not be to your taste but it's not 'blogspam' - it's not a lifted copy of the sources you are suggesting.
How does it compare with MJPEG, which performs very well on even low-end devices and is supported in most web browsers?
Are files going to have .jpg extension?
This is not an on-disk format. There will be no files. It's for low-latency on-the-wire transmission.
Can we just skip JP2?
You have missed the point. The concept here is low-latency, low-compression.
Just use PNG
For streamed video? Don't be daft!
You have completely missed the point.
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.