Earlier quoted context omitted.
hardly, it's a google team that made the thing.
Then why does Google not want JPEG XL support in Chrome?
Google is not a monolith. The Chrome team doesn't want it in Chrome, but many other parts of Google likes it.
Philips announces digital pathology scanner with native DICOM JPEG XL output
51–56 of 56 posts
Re: Philips announces digital pathology scanner with native DICOM JPEG XL output
#52Earlier quoted context omitted.
Hard disk and bandwidth of jpegs are almost certainly negligible in the era of streaming video. The biggest selling point is probably client side latency from downloading the file. We barely even have movement to webp &avif, if this was a critical issue i would expect a lot more movement on that front since it already exists. From what i understand avif gives better compression (except for lossless) and has better de…
> We barely even have movement to webp &avif If you look at CDNs, WebP and AVIF are very popular. > From what i understand avif gives better compression (except for lossless) and has better decoding speed than jxl anyways. AVIF is better at low to medium quality, and JXL is better at medium to high quality. JXL decoding speed is pretty much constant regardless of how you vary the quality parameter, but AVIF gets fast…
>AVIF is better at low to medium quality,
>The Chrome team really dislikes the concept of high quality images on the web for some reason though, that's why they only push formats that are optimized for low quality.
It would be more accurate to say Bit per Pixel (BPP) rather than quality. And that is despite the Chrome team themselves showing 80%+ of images served online are in the medium BPP range or above where JPEG XL excel.
Re: Philips announces digital pathology scanner with native DICOM JPEG XL output
#53Earlier quoted context omitted.
Hard disk and bandwidth of jpegs are almost certainly negligible in the era of streaming video. The biggest selling point is probably client side latency from downloading the file. We barely even have movement to webp &avif, if this was a critical issue i would expect a lot more movement on that front since it already exists. From what i understand avif gives better compression (except for lossless) and has better de…
> We barely even have movement to webp &avif If you look at CDNs, WebP and AVIF are very popular. > From what i understand avif gives better compression (except for lossless) and has better decoding speed than jxl anyways. AVIF is better at low to medium quality, and JXL is better at medium to high quality. JXL decoding speed is pretty much constant regardless of how you vary the quality parameter, but AVIF gets fast…
Isn't medium quality the thing to optimize for? If you are doing high quality you've already made the tradeoff that you care about quality more than latency, so the precieved benefit of mild latency improvement is going to be lower.
Re: Philips announces digital pathology scanner with native DICOM JPEG XL output
#54Seeing JPEG XL integrated into the DICOM standard was a particularly proud moment for me as the manager of the effort at Google.
It felt like closing a major circle in my career, because I spent the first 16 years of my career in the medical industry, working on Neurosurgical Robots (Oulu Neuronavigator System), and one of the first tools I built was an ACR-NEMA 1.0 parser, ACR-NEMA being the direct predecessor to DICOM, and then continuing on radiation treatment planning systems with plenty of DICOM work within them. To now contribute back to that very standard is incredibly rewarding.
Re: Philips announces digital pathology scanner with native DICOM JPEG XL output
#55Can someone comment on what is newsworthy about this?
JPEG XL is alive despite google trying their best to kill it and is used to treat cancer
Google Research was central in developing and continuing to push JPEG XL.
The Google Chrome folks are the ones who decided to disallow it. You could argue that they are trying to kill it, but certainly not Google at large.
Re: Philips announces digital pathology scanner with native DICOM JPEG XL output
#56Earlier quoted context omitted.
Hard disk and bandwidth of jpegs are almost certainly negligible in the era of streaming video. The biggest selling point is probably client side latency from downloading the file. We barely even have movement to webp &avif, if this was a critical issue i would expect a lot more movement on that front since it already exists. From what i understand avif gives better compression (except for lossless) and has better de…
> We barely even have movement to webp &avif If you look at CDNs, WebP and AVIF are very popular. > From what i understand avif gives better compression (except for lossless) and has better decoding speed than jxl anyways. AVIF is better at low to medium quality, and JXL is better at medium to high quality. JXL decoding speed is pretty much constant regardless of how you vary the quality parameter, but AVIF gets fast…
> AVIF is better at low to medium quality, and JXL is better at medium to high quality.
BTW, this is no longer true. With the introduction of tune IQ (Image Quality) to libaom and SVT-AV1, AVIF can be competitive with (and oftentimes beat) JXL at the medium to high quality range (up to SSIMULACRA2 85). AVIF is also better than JPEG independently of the quality parameter.
JXL is still better for lossless and very-high quality lossy though (SSIMULACRA2 >90).