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

First automatic JPEG-XL cloud service

gumlet.com

Post reply on HN
Print view View original

31–40 of 68 posts

Re: First automatic JPEG-XL cloud service

#31

Post by adityapatadia »

supermatt wrote: post #26
adityapatadia wrote: post #25

Earlier quoted context omitted.

Founder here. We are first cloud service to do it "automatically" based on client support. Most services don't have this and those who have it, don't do it automatically and requires code change.

That is exactly what cloudinary does as part of their optimized delivery. https://cloudinary.com/documentation/image_optimization#auto... Also, your claim is that you are "first to support", not "first to serve all our clients images as jxl without asking if thats ok"...

It still needs `f_jxl` in parameter. Automatic support has still not launched as per this article's last paragraph: https://cloudinary.com/blog/jpeg-xl-how-it-started-how-its-g...

Re: First automatic JPEG-XL cloud service

#32

Post by supermatt »

adityapatadia wrote: post #31
supermatt wrote: post #26

Earlier quoted context omitted.

That is exactly what cloudinary does as part of their optimized delivery. https://cloudinary.com/documentation/image_optimization#auto... Also, your claim is that you are "first to support", not "first to serve all our clients images as jxl without asking if thats ok"...

It still needs `f_jxl` in parameter. Automatic support has still not launched as per this article's last paragraph: https://cloudinary.com/blog/jpeg-xl-how-it-started-how-its-g...

The "automatic support" you mention there is for the AI optimization, which decides which format to use based on the image content. It is unrelated to the client detection.

You dont need to use the f_jxl parameter. e.g. https://res.cloudinary.com/demo/image/upload/c_scale,w_500/f...

And can all be handled via srcset.

Re: First automatic JPEG-XL cloud service

#33

Post by ZeroGravitas »

robertlagrant wrote: post #30

Any insight on why Firefox and Chrome dropped it, other than how disappointing it felt? What was their reason?

For Google, focusing on one next gen image codec is the basic reason.

A perfectly reasonable decision if made by a committee of disinterested parties deciding the future of the web for the benefit of humanity, but a bad look when pulled by a megacorp.

For Firefox, it's about hoping to get to that latter situation. They want the web to move forward in step as much as possible rather than it being some wild west where everyone just does their own thing. They've lived through that already. And it sucked. Hence the various standardisation and community interoperability measures which have radically improved the web platform over the last decade or so.

Re: First automatic JPEG-XL cloud service

#34

Post by sonar_un »

robertlagrant wrote: post #30

Any insight on why Firefox and Chrome dropped it, other than how disappointing it felt? What was their reason?

From what I remember, Firefox was basically neutral on it, and didn't want to extend resources to it if it wasn't adopted at wide scale. Chrome basically said that there wasn't much interest so they weren't going to put resources towards it.

Re: First automatic JPEG-XL cloud service

#36

Post by cjpearson »

robertlagrant wrote: post #30

Any insight on why Firefox and Chrome dropped it, other than how disappointing it felt? What was their reason?

Unless something changed recently, Firefox never dropped support. It's always been behind a feature flag though. Google gave some reasons on their issue tracker.

https://bugs.chromium.org/p/chromium/issues/detail?id=117805...

Re: First automatic JPEG-XL cloud service

#37

Post by youngtaff »

sandGorgon wrote: post #29
_ache_ wrote: post #11

Earlier quoted context omitted.

From my own tests. JXL is better for photos and competitive with AVIF for images with flat areas of color (PNG-like). JXL is about the same speed as AVIF but WebP is quicker than both.

JXL is same speed as AVIF ? but what everyone has been commenting is that AVIF is 100x slow

Encoding AVIF is very slow for large images.

Instead of using a breakpoint style approach with several predefined sizes some site generate images related to viewport size at very fine granularity and even changing the viewport by 1px will cause the AVIF to be regenerated

In these cases you can notice services like Cloudinary take several seconds to generate the new variant if it’s a large image

Re: First automatic JPEG-XL cloud service

#40

Post by a-french-anon »

robertlagrant wrote: post #30

Any insight on why Firefox and Chrome dropped it, other than how disappointing it felt? What was their reason?

Might have to do with https://flak.tedunangst.com/post/on-building-jpeg-xl-for-was... libjxl being a big C++ pain to build and maybe needing some serious audit/fuzzing. Still, AVIF isn't that much better except libavif being C (libheif is C++ though, and it's probably what's in use).
Post reply on HN