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

21–30 of 68 posts

Re: First automatic JPEG-XL cloud service

#21

Post by martin_a »

xena wrote: post #20
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.

The biggest advantage I can think about is transparency support.

Ok, but we got PNG for that. Photos usually don't contain transparencies, so why have several Megapixel/Megabyte large PNGs?

Re: First automatic JPEG-XL cloud service

#22

Post by martin_a »

supermatt wrote: post #19
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.

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

Ok, that looks better than Progressive JPEG, I'll give you that. ;-)

On the other hand: When your connection speed is 30 kb/s, images are probably the last problem with "modern" websites... ;-)

Re: First automatic JPEG-XL cloud service

#23

Post by xena »

martin_a wrote: post #21
xena wrote: post #20

Earlier quoted context omitted.

The biggest advantage I can think about is transparency support.

Ok, but we got PNG for that. Photos usually don't contain transparencies, so why have several Megapixel/Megabyte large PNGs?

Because JPEG XL has smaller file sizes, which saves you money in the era of Managed NAT Gateway's 7 cents per gigabyte egressed.

Re: First automatic JPEG-XL cloud service

#24

Post by supermatt »

martin_a wrote: post #22
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

Ok, that looks better than Progressive JPEG, I'll give you that. ;-) On the other hand: When your connection speed is 30 kb/s, images are probably the last problem with "modern" websites... ;-)

Oh yeah, definitely. For me the usecase is infinite scrolling, where you buffering offscreen images to allow you to continually flick through an image feed without having to "wait" for a preview to appear. Although you can do this without JXL, its a much more fluid experience with the progressive download - especially if you micromanage the behaviour of the network requests (i.e. progressive throttling of offscreen images past first frame). Lower filesize over JPEG is also a benefit there as you can more quickly resume the load of the higher fidelity frames when in view.

Current browser support where available is a lot more restrictive TBH, as you dont have any control over that behaviour. But outside the browser its solid gold.

Re: First automatic JPEG-XL cloud service

#25

Post by adityapatadia »

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.

Re: First automatic JPEG-XL cloud service

#26

Post by supermatt »

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.

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

Re: First automatic JPEG-XL cloud service

#27

Post by ChoHag »

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.

[dead]

Re: First automatic JPEG-XL cloud service

#29

Post by sandGorgon »

_ache_ wrote: post #11
sandGorgon wrote: post #7

This is google+cloudinary published benchmarks of jpeg-xl vs avif vs webp https://storage.googleapis.com/avif-comparison/index.html https://cloudinary.com/blog/contemplating-codec-comparisons

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
Post reply on HN