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

141–150 of 210 posts

Re: The case for JPEG XL

#141

Post by crazytalk »

JyrkiAlakuijala wrote: post #137
crazytalk wrote: post #117

Earlier quoted context omitted.

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…

60 mbps is easily beyond the limits of many home wifi network setups, and leaves the serving end with capacity for something like 166 users per 10 Gbit port. There are many additional costs to consider beyond the size of the home pipe

Re: The case for JPEG XL

#142

Post by RunSet »

> Recently, the Chrome developers announced their decision to remove the behind-a-flag support for JPEG XL.

Given that, is there any reason JPEG XL might be better for privacy / worse for advertising industry scumbags? I have no expectation that Google / Chrome will ever make any decision primarily with their users' best interest in mind.

Re: The case for JPEG XL

#143

Post by deskamess »

There really is no good justification for this decision.

Perhaps unrelated but Google seems 'business tone deaf'. With every product release the first question on our minds is 'When will it get deprecated?' - and that is a legitimate question. Their support story is not that impressive. They do not seem to have the history/culture/DNA for support that MS or Amazon has. Their best customer is the browser - a customer that does not ask for support, only ads. I think they have prospered and will continue to for some time but they have to get a better non-browser customer support story.

Ad revenue paved a runway so wide that potholes do not bother them. If the revenues keep coming down they will need a shift in attitude (management and developers).

Re: The case for JPEG XL

#144

Post by ksec »

gardaani wrote: post #15

I hope Edge and Safari will enable JPEG XL, but not AVIF. AVIF has several disadvantages, for instance, it takes much longer to encode than JPEG XL and it doesn't support progressing decoding. Google just doesn't like formats created outside their own company. They prefer WebP and AVIF (created by themselves), but dislike JPEG XL (not created by them).

This may have happened during Steve's era. Who tends to pick the best codec and fight for it.

No under Tim Cook though. They sided with Google already.

Re: The case for JPEG XL

#145

Post by ksec »

vanderZwan wrote: post #107
JyrkiAlakuijala wrote: post #25

Beautifully written article -- I couldn't agree more. From my personal point of view the biggest impact are: 1) e-commerce textures such as cloths are more faitfully represented -- more trust in e-commerce, more revenue 2) more equity for selfies, people-of-color skin is better represented in JPEG XL, selfies in general look more people like with less smoothing of skin performed at compression stage -- I'm a great fr…

Personally, even if Chrome goes ahead with removing support I hope JPEG XL will "win" in the long run by being an attractive "universal" format for all other use-cases for image compression. So in other words: that it finds an ecosystem elsewhere, slowly takes over outside of the browsers, and then the browsers will adopt it after all. For example, I remember reading somewhere that there are people looking at whether…

What if Google demand every Android devices to support AVIF and not JPEG XL?

This isn't a fight about whether something is technically superior, it is about marketing, cult and ideology. It wont be long before major force of AOM supporters arrives with new PR points to fight back.

Re: The case for JPEG XL

#146

Post by zinekeller »

vanderZwan wrote: post #107
JyrkiAlakuijala wrote: post #25

Beautifully written article -- I couldn't agree more. From my personal point of view the biggest impact are: 1) e-commerce textures such as cloths are more faitfully represented -- more trust in e-commerce, more revenue 2) more equity for selfies, people-of-color skin is better represented in JPEG XL, selfies in general look more people like with less smoothing of skin performed at compression stage -- I'm a great fr…

Personally, even if Chrome goes ahead with removing support I hope JPEG XL will "win" in the long run by being an attractive "universal" format for all other use-cases for image compression. So in other words: that it finds an ecosystem elsewhere, slowly takes over outside of the browsers, and then the browsers will adopt it after all. For example, I remember reading somewhere that there are people looking at whether…

> Personally, even if Chrome goes ahead with removing support I hope JPEG XL will "win" in the long run by being an attractive "universal" format for all other use-cases for image compression. So in other words: that it finds an ecosystem elsewhere, slowly takes over outside of the browsers, and then the browsers will adopt it after all.

Ah, like how Chrome delayed APNG so much that there was a dedicated extension for it? (https://github.com/davidmz/apng-chrome) Sadly the Chrome extension page was removed around June (I assume it's more of cleaning up obsolete extensions rather than something nefarious) but I have recovered its description here:

Support for animated PNG images in Google Chrome browser.

Chrome 59 now have native support of APNG, so you do not need this extension anymore. Goodbye, it was an interesting 6 years!

About APNG format: http://en.wikipedia.org/wiki/APNG

This extension animates IMG elements. Also it animates background images/list style images from css styles (div style="…"), but CSS images support may be incomplete.

You can prevent this extension from work on specific domains (Black List mode, default) or allowed it to work ONLY on specific domains (White List mode).

Source code is available on GitHub: https://github.com/davidmz/apng-chrome

WARNING! CAPTCHA may not work on some sites because of this expansion (it is not always possible to correctly detect captcha images). If captcha does not work on some site, just (temporarily) disable the extension on the it.

---------------------------------- Latest notable changes:

3.1.0 (2017-06-07) Chrome 59 now have native support of APNG, so you do not need this extension anymore. Goodbye, it was an interesting 6 years!

3.0.0 (2016-09-12) IT WORKS AGAIN!!!

In Chrome 48 (Feb 2016) Google turns off getCSSCanvasContext API. It was the critical part of extension, and within six months the Chrome has no technologies to animate images. Fortunately, it has changed recently and now this extension works again.

In version 3 algorithm was changed from canvas animation to APNG → animated WebP conversion.

2.1.4 (2014-11-28) Fixed some incorrect captcha images.

2.1.2 (2014-01-15) Better Reddit support.

2.1.0 (2014-01-12) Partial Reddit emotes support.

2.0.7 (2014-01-12) Redirects support.

2.0.4 (2013-05-26) Ext. was broken because of bug 238071 in Chrome 27. Fixed it.

2.0.3 (2013-03-19) Fixed bug with images with 'auto' height/width in style.

2.0.0 (2012-10-01) Most of the code rewritten. CSS background/list animations is turned off (except inline styles). Fixed slow work in some sites (g+, gmail and so on).

0.7.1 (2012-04-07) animated-gif-captcha images support (strange captchas of wedge.org)

0.7.0 (2011-08-03) fix for facepunch.com (perhaps the only site where this extension is actually used:))

0.6.9 (2011-07-14) data: url support, fixes for google maps images

0.6.8 (2011-07-09) fixed bug with CAPTCHA images

0.6.7 (2011-07-03) support for list-style-images

0.6.6 (2011-06-30) tracking changes in image's 'src'

0.6.2 (2011-06-30) background-image animation for internal and external CSS

Re: The case for JPEG XL

#147

Post by account42 »

Lockal wrote: post #136
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.

There is some irony on calling out benchmarks from an affiliated party and then linking to benchmarks from an affiliated party of the competing format.

> The source images were stripped of any metadata, EXIF, XMP, color profile etc. including the gAMA PNG chunk.

Just so happens that cjxl correctly supports PNG color profile/gamma data while cwebp doesn't.

Re: The case for JPEG XL

#148

Post by pornel »

Tomte wrote: post #22
sedatk wrote: post #3

Browser support: - JPEG XL: none - HEIF: none - AVIF: all but Edge - WebP: all

I'd have expected HEIF to be implemented in Safari, at the very least mobile Safari. Did Apple really not include their native image format on recent iPhones?

AVIF is based on HEIF + free codec. Apple's HEIC is HEIF + commercial patent-encumbered codec libre browsers are not allowed to use.

Re: The case for JPEG XL

#149

Post by account42 »

rob74 wrote: post #45
dmitriid wrote: post #43

Earlier quoted context omitted.

Google don't need to resort to such tricks when they can just bludgeon everyone to death. Se how they forced support of VP9 and AV1: https://www.protocol.com/youtube-tv-roku-issues

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

Also brotli - not that its a bad format but its weird how quickly it made it into browsers without proving itself first when there have been so many general purpose compression algorithms better than gzip that were just ignored.

Re: The case for JPEG XL

#150

Post by pornel »

JXL developers are understandably upset about being a victim of Worse is Better.

The Web platform is hardly cutting edge here. It took 10 years to add WebP across browsers, and it wouldn't have been added at all if it didn't cause web-compat issues for non-Chrome(ium) browsers.

From browsers' perspective the question isn't "is the new codec better", but "are existing codecs so terrible that they need urgent replacement". Most people still use JPEG, not even WebP or AVIF yet.

Post reply on HN