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?
First automatic JPEG-XL cloud service
61–68 of 68 posts
Re: First automatic JPEG-XL cloud service
#62Earlier 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.
I mean, Webp must store an RGBA tuple for each pixel, even for grayscale without alpha, right?
Re: First automatic JPEG-XL cloud service
#63JPEG-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.
Re: First automatic JPEG-XL cloud service
#64JPEG-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.
Perhaps they should have called it JPEG 2.0.
Re: First automatic JPEG-XL cloud service
#65> 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 "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
#66Earlier 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?
Re: First automatic JPEG-XL cloud service
#67Earlier 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.
Re: First automatic JPEG-XL cloud service
#68Earlier 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