First automatic JPEG-XL cloud service • Hacker News Board

Re: First automatic JPEG-XL cloud service

#11

Post by _ache_ » Wed, Sep 20, 2023, 7:06 AM UTC

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.

Re: First automatic JPEG-XL cloud service

#12

Post by NetOpWibby » Wed, Sep 20, 2023, 7:15 AM UTC

gadtfly wrote: post #6

pdntspa wrote: post #3

Every time I see JPEG XL I always get my wires crossed with JPEG 2000... as in, "Isn't that that weird format I had to use Irfanview to decode?"

I always confuse it with JBIG2, infamous from NSO's Pegasus zero-click iMessage exploit: > JBIG2 doesn't have scripting capabilities, but when combined with a vulnerability, it does have the ability to emulate circuits of arbitrary logic gates operating on arbitrary memory. So why not just use that to build your own computer architecture and script that!? That's exactly what this exploit does. Using over 70,000 segme…

I’m glad most people use their powers for good. This is beyond me.

Incredible programming.

Re: First automatic JPEG-XL cloud service

#13

Post by supermatt » Wed, Sep 20, 2023, 7:21 AM UTC

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

Re: First automatic JPEG-XL cloud service

#14

Post by blurred » Wed, Sep 20, 2023, 7:28 AM UTC

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.

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

Re: First automatic JPEG-XL cloud service

#15

Post by Scaevolus » Wed, Sep 20, 2023, 7:32 AM UTC

charcircuit wrote: post #8

For other platforms it should check to see if it's more efficient to serve a JPEGXL WASM polyfill

Writing a good polyfill for this is harder than you might think, because the browser by default does lazy decoding of JPEG images to avoid holding too many buffers in RAM. Naive attempts (niutech/jxl.js) at JXL polyfills tend to crash browser tabs by using too much memory if they contain a few dozen megapixels of images, while Chrome normally can handle hundreds of megapixels of JPEGs on a page without difficulty.

Re: First automatic JPEG-XL cloud service

#16

Post by [deleted] » Wed, Sep 20, 2023, 7:32 AM UTC

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.

[deleted]

Re: First automatic JPEG-XL cloud service

#17

Post by martin_a » Wed, Sep 20, 2023, 7:34 AM UTC

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.

Re: First automatic JPEG-XL cloud service

#18

Post by xena » Wed, Sep 20, 2023, 7:35 AM UTC

Does anyone know of a Go library for encoding JPEG-XL files?

Re: First automatic JPEG-XL cloud service

#19

Post by supermatt » Wed, Sep 20, 2023, 7:37 AM UTC

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

Re: First automatic JPEG-XL cloud service

#20

Post by xena » Wed, Sep 20, 2023, 7:37 AM UTC

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.