Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The case for JPEG XL

cloudinary.com

Post reply on HN
Print view View original

131–140 of 210 posts

Re: The case for JPEG XL

#131

Post by bartimus »

HDR is mentioned only once. Yet this should be the primary case for any new image standard.

I'll repeat a comment I wrote here earlier:

Our camera hardware supports HDR. RAW image formats support HDR. Our display devices support HDR. Videos support HDR. Smartphones can now record in HDR.

All the hardware is there ready for the future. Yet due to (30 year old) software limitations we're still cutting off HDR data when saving our precious memories as JPEG. All whites become #ffffff. The white of paper. The color of Word's document background color.

The gamut of color has expanded and we need image standards to expand with it.

Re: The case for JPEG XL

#132

Post by JyrkiAlakuijala »

nigeltao wrote: post #128
JyrkiAlakuijala wrote: post #113

Earlier quoted context omitted.

I believe that density is 100x to 1000x more important for fast experience and computational cost than the near instantaneous decoding speed of common lossless formats.

I agree that compression ratio is the primary metric (but not the only important metric). I just found "[better] in all ways", explicitly calling out encode speed, incongruous with simply ignoring decode speed. As for which is more important out of encode and decode speed, I would personally rank decode speed higher. For example, app icons on your home screen were encoded once (by the graphic artist) but are decoded…

Agree with decode time being more important. There we still can improve.

We have ideas how to make it faster than WebP lossless, but haven't engaged with that yet -- the lossless decoding is already fast enough not to be a blocker.

Also, given how efficient and quality-sure the lossy is, it will become tempting to migrate many of the PNG/GIF/WebP lossless cases to JPEG XL lossy further reducing the priority in JPEG XL lossless. This can be a 4x-5x savings whereas a better lossless is only 10-40 % savings in density.

Re: The case for JPEG XL

#133

Post by LoganDark »

cesarb wrote: post #119
janwas wrote: post #48

Earlier quoted context omitted.

Disclaimer: I co-chaired the JPEG XL working group; opinions are my own. The JPEG XL format is most certainly not a nightmare internally. Compare the spec lengths: 681 pages for https://aomediacodec.github.io/av1-spec/av1-spec.pdf , 101 for https://www.iso.org/standard/77977.html . Or code sizes: 6.6 MB uncompressed for libjxl (encoder+decoder), 9.5 MB for dav1d (decoder only) plus 34.2 MB for SVT-AV1 (encoder). Feat…

> Compare the spec lengths: 681 pages for https://aomediacodec.github.io/av1-spec/av1-spec.pdf , 101 for https://www.iso.org/standard/77977.html . And here we immediately see one important difference between them: the first link is to a 681-page PDF, which opens immediately in my browser. The second link is to a place where one can buy access to what it says is a 101-page PDF, after paying more money than it would co…

...After seeing this, I no longer care if JXL lives or dies.

Re: The case for JPEG XL

#134

Post by LoganDark »

Heikete wrote: post #53

The thing that I don't understand is why the world has switched over to Chrome leaving Firefox behind. Here in Poland most of the tech people use Firefox as that was the alternative when IE was a bad guy and Firefox continues to be a good browser. What was the advantage of Chrome which made people exchange one monopoly for another? PNG had also hard times in IE at first, as far as I remember. So instead of fighting f…

Maybe it's because Chrome does not have a huge memory leak that brings down your system after a few days of uptime.

I use Firefox because Chrome's updater kept trying to sneak past my firewall and one day it succeeded. As soon as it did, I switched. **No.**

I don't like Firefox because of all its issues (including the memory leak), but at least it supports trackpad gestures and overscroll and all that good stuff that Chrome doesn't. And it doesn't keep trying to backdoor my computer using a stupid hard-to-disable updater. One single JSON file and it obeys for good.

Re: The case for JPEG XL

#135

Post by JyrkiAlakuijala »

Heikete wrote: post #53

The thing that I don't understand is why the world has switched over to Chrome leaving Firefox behind. Here in Poland most of the tech people use Firefox as that was the alternative when IE was a bad guy and Firefox continues to be a good browser. What was the advantage of Chrome which made people exchange one monopoly for another? PNG had also hard times in IE at first, as far as I remember. So instead of fighting f…

For me, the competition there is pretty simple. The browser shouldn't crash.

Until now I used firefox on my home ubuntu box (intel nuc). Yesterday it started crashing, and crashed about 15 times. I downloaded chromium and it didn't yet crash.

Now, I'll probably move to it for home computer browsing, too. Even when I don't agree with their decision on not enabling JPEG XL by default. If there is a browser that has it on by default, then I naturally switch to that instead :-) -- but I'm not aware of such. Perhaps Brave?

Re: The case for JPEG XL

#136

Post by Lockal »

conaclos wrote: post #127

On the same website, another blog post [1] compares JPEG XL with other formats. [1] https://cloudinary.com/blog/time_for_next_gen_codecs_to_deth...

Be careful with this website. Cloudinary is a developer of JPEG XL, is an affiliated party, so there is absolutely no reason to expect a fair comparison.

Instead visit https://storage.googleapis.com/demos.webmproject.org/webp/cm... and you will see that JPEG XL has color fringing and ringing artifacts.

Re: The case for JPEG XL

#137

Post by JyrkiAlakuijala »

crazytalk wrote: post #117
mastax wrote: post #38

I had regarded the lossless re-compression as an interesting parlor trick, but I get it now. Coincidentally today I was testing how much we can shrink our archived videos. We have lots of videos recorded with the Intel hardware encoder in H264, so not even the state of the art of H264. I figured: pop it into handbrake, change the codec to H265 (X.265), and boom 30%+ reduction. No, the H265 file got 3X larger. Well th…

Most online video uses crazily overspecified h.264 bit rates for low complexity content. It's often possible to get 1080p well under 2 Mbit/s with little to no quality loss, and even lower by using 2 pass encoding where that's available. I'm not sure how things are with h.265 in a production setting, but at least for home use it seems to have much of the same flexibility

I get nervous when I see motion artefacts on netflix. This means I'm pretty much always nervous when watching netflix. I use a 1 gbps home connection and pay for the most expensive option netflix has. I'd like to think that the whole concept of motion frames based prediction will disappear in future videos.

Motion JPEG XL would be like in the movies where they have Motion JPEG 2000, but ~35-40 % more dense. We could add usual delta frames without motion without compromising quality criteria. This would get us in the 0.3 BPP range.

4k at 30 Hz would be 3840 x 2160 x 24 x 0.3 should need about 60 mbps (~ 7.5 MB/s), still doable for home internet speeds and would be visually lossless, a better experience than home movie streaming is today. (free startup idea) :-)

Re: The case for JPEG XL

#138

Post by JyrkiAlakuijala »

bartimus wrote: post #131

HDR is mentioned only once. Yet this should be the primary case for any new image standard. I'll repeat a comment I wrote here earlier: Our camera hardware supports HDR. RAW image formats support HDR. Our display devices support HDR. Videos support HDR. Smartphones can now record in HDR. All the hardware is there ready for the future. Yet due to (30 year old) software limitations we're still cutting off HDR data when…

Adobe and Intel seem to share your thinking with HDR driving this generation of image formats.

https://helpx.adobe.com/si/camera-raw/using/hdr-output.html

JPEG XL has HDR always built-in into its modeling, both SDR and HDR images are modeled exactly the same way and give the exactly same visual quality with the same encoding parameters. Compositing SDR and HDR materials does not need conversions between colorspaces -- everything is in absolute color XYB colorspace.

Other codecs (AVIF, HEVC) need a different set of encoding parameters for obtaining the same visual quality when used for SDR or HDR. Compositing SDR and HDR materials necessarily needs color conversions, since they will have different normalizations. Knowing which HDR quality setting corresponds which SDR setting will become additional cognitive load for the users.

Re: The case for JPEG XL

#139

Post by Mindless2112 »

jonsneyers wrote: post #126
palotasb wrote: post #124

Earlier quoted context omitted.

Is there a "latest draft" standard available legally and for free for wider audiences? C++, also ISO standardized, does this and I believe it has contributed greatly to its adoption and post-C++11 renaissance. See https://en.cppreference.com/w/cpp/links#C.2B.2B_Language_and... . For now, JPEG XL might as well be a proprietary closed format for most hackers here.

Recent drafts do tend to get circulated amongst the image compression community. For wide audiences I don't think this type of document is very readable nor relevant; the number of people who are going to make their own independent implementation is relatively small. In this sense the spec audience is not quite the same as that of a spec for a programming language, which is important not just for compiler implementer…

Any chance of publishing the spec with ECMA in addition to ISO? The C# spec is both an ECMA and an ISO standard, but it started with ECMA.

Re: The case for JPEG XL

#140

Post by JyrkiAlakuijala »

gruturo wrote: post #77
rob74 wrote: post #45

Earlier quoted context omitted.

Not to mention WebP, which I guess is the elephant in the room when they say that JPEG XL "does not bring sufficient incremental benefits over existing formats".

And which is very unconvincing in real world use.... It benchmarks well, but "looks" crap. I really wish they had produced something better than that, if that's what we're going to be stuck with. It's sad.

JPEG XL is the other way around: Okeyish/boring in usual PSNR, SSIM, VMAF benchmarks, great in benchmarks with DSSIM, SSIMULACRA2 and Butteraugli, but looks superb to humans.
Post reply on HN