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

51–60 of 68 posts

Re: First automatic JPEG-XL cloud service

#51

Post by supermatt »

KronisLV wrote: post #49
supermatt wrote: post #19

Earlier quoted context omitted.

High quality progressive decoding at reduced filesizes is a big positive for me. There is no other format that supports that. https://www.youtube.com/watch?v=UphN1_7nP8U

> High quality progressive decoding at reduced filesizes is a big positive for me. This is really cool! Honestly, I want to use regular progressive JPEGs for a current project of mine, but it seems that even that doesn't have support in all the tech stacks yet despite how long it's been around for, for example: https://github.com/SixLabors/ImageSharp/issues/449 Here's hoping that in the case of JPEG-XL this will be m…

yeah, you are very much at the mercy of the libs you use if you want full feature parity with, for example, libjpeg-turbo in the case of JPEG.

In the browser where supported, I guess loading="lazy" probably already works (i havent tried). I think a more advanced version where you can choose maybe a "staged" loading type, or some mechanism to choose the pass/frame to pause the network activity at so that you can control it further via JS would be nice. At a minimum it would be a feature enabling a preview and a reduced download for the full version. I can see many usecases where that could be useful.

Re: First automatic JPEG-XL cloud service

#52

Post by adityapatadia »

q87b wrote: post #45
adityapatadia wrote: post #28

If you are curious, here is how JPEG-XL adoption looks like after 42 hours of iOS 17 launch: https://twitter.com/adityapatadia/status/1704407864326939043

What does that show? Adoption where? By whom?

Out of total requests we have served in last 1 minute, this was percent of response was JPEG-XL. This is across all of our customer base.

Re: First automatic JPEG-XL cloud service

#53

Post by adityapatadia »

sonar_un wrote: post #35
adityapatadia wrote: post #28

If you are curious, here is how JPEG-XL adoption looks like after 42 hours of iOS 17 launch: https://twitter.com/adityapatadia/status/1704407864326939043

IOS 17 also added HEIF/HEIC support to their browers, which IMO, is HUGE.

We also support HEIF conversion with `format=heif` parameter. It's not automatic though.

Re: First automatic JPEG-XL cloud service

#55

Post by heykoo »

adityapatadia wrote: post #53
sonar_un wrote: post #35

Earlier quoted context omitted.

IOS 17 also added HEIF/HEIC support to their browers, which IMO, is HUGE.

We also support HEIF conversion with `format=heif` parameter. It's not automatic though.

And HEIF are automatically converted to JXL for iOS 17?

Re: First automatic JPEG-XL cloud service

#58

Post by JyrkiAlakuijala »

a-french-anon wrote: post #42
martin_a wrote: post #17

Now... Do we need JPEG-XL in the first place? What's the benefit? Hardware is fast enough to decode JPEG, also storage is cheap enough to stick to JPEG. What's the point in using JPEG-XL if you're not running an imageboard or whatnot?! edit: Happy Birthday, JPEG! We also got 30 years of integration, optimization and everything else for that image format, too.

Don't ignore the fact that unlike WebP (lossless: missing grayscale | lossy: forced 4:2:0 chroma subsampling =x | both: missing metadata and progressive) and AVIF (lossless: worse than PNG in many cases, i.e. useless), it's both a very good PNG and JPEG replacement; only AVIF wins in my books are very low bpp lossy quality (not very interesting), hardware decoding support and dav1d being amazing. I seriously see JXL…

WebP lossless as a format has two or three efficient ways of encoding grayscale (subtract green mode, palette, perhaps cross color decorrelation would work, too). Perhaps the libwebp APIs don't make it obvious. Density should be quite a bit better than with PNG.

Re: First automatic JPEG-XL cloud service

#59

Post by ElectricalUnion »

preya2k wrote: post #41

JPEG-XL is a fantastic format but it has a big marketing/naming problem. I think the the lack of popularity/adoption is in big parts due to the confusing name.

It sucks that there are several other combinations of 2 letters suffixes that are also taken:

JPEG XR (Windows Media Photo, hdr), JPEG XS (a "realtime" one) and JPEG XT (a "very backwards compatible" one). So besides XL I'm never sure what the hell I'm dealing with.

Re: First automatic JPEG-XL cloud service

#60

Post by ddalessa »

adityapatadia wrote: post #25
supermatt wrote: post #13

> JPEG-XL is newest image format and Gumlet is first cloud provider to support it. This is completely untrue. Cloudinary have supported it since 2020, which is where Jon Sneyers, the chair for the JPEG XL WG and lead developer of libjxl works. Shame on you for making false claims - especially considering your "service" is in direct competition to cloudinary.

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.

Probably never heard of them, but https://www.peakhour.io have had automatic support for it based on the accepts header for about a year.
Post reply on HN