Live data from Hacker News

First automatic JPEG-XL cloud service

gumlet.com

61–68 of 68 posts

Re: First automatic JPEG-XL cloud service

#61
post #57

Earlier quoted context omitted.

Yes!

I’m not clear on the benefit of doing that. Won’t you end up with worse quality from the transcode and have equivalent file size?

Do give it a try! In our tests we found that sizes are smaller and encoding of HEIF takes very very long time. Remember, we provide bunch of other things like image resize and crop etc so we always end up encoding image again. Encoding in HEIF is very slow.

Re: First automatic JPEG-XL cloud service

#62

Earlier quoted context omitted.

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.

Indeed, that wasn't obvious it was using tricks to improve the situation. But I do remember in my tests PNG beating Webp when using gray8 input.

I mean, Webp must store an RGBA tuple for each pixel, even for grayscale without alpha, right?

Re: First automatic JPEG-XL cloud service

#63
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.

Unfortunately the authors don't think that is the case. I pointed this out in 2019 / 2020 already.

Re: First automatic JPEG-XL cloud service

#64
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.

I've never been confused about it, not sure what the issue is. There's JPEG, and there's JPEG XL.

Perhaps they should have called it JPEG 2.0.

Re: First automatic JPEG-XL cloud service

#65
post #14

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

Also nearly all Apple devices should now be able to also convert JPEG-XL: https://www.theregister.com/2023/06/07/apple_safari_jpeg_xl/ >Google snubbed JPEG XL so of course Apple now supports it in Safari

The iPhone has something like an 87% market-dominating position with teens. Every single one has Safari preinstalled.

The "hedge" angle on doing what google isn't doing is a fascinating possibility.

Could it be that, paradoxically, Google actually inadvertently secured JPEG-XL's future by ripping it out of Chrome?

Re: First automatic JPEG-XL cloud service

#66
post #46

Earlier quoted context omitted.

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

Why not have one format good for everything image? There's zero reason to not have it now. Would you say 'We got GIF for that' if asked for animation?

I think animation is also part of the JXL spec, although may not be part of the reference implementation yet =)

Re: First automatic JPEG-XL cloud service

#67

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.

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.

It seems the poster isn't interested. I just checked in to see if they had "corrected" their article, and it seems not :(

Re: First automatic JPEG-XL cloud service

#68
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

if I understood well, AVIF encoder is quite fast for ugly qualities and very slow for standard and higher quality. https://cloudinary.com/blog/contemplating-codec-comparisons#...
Post reply on HN