After reading a bit about jpeg xl [0], the bit depth, channel count and pixel count seem promising. Devils in the details. How will multiple focal planes be implemented?
https://www.abyssmedia.com/heic-converter/avif-heic-jpegxl.s...
Philips announces digital pathology scanner with native DICOM JPEG XL output
31–40 of 56 posts
Re: Philips announces digital pathology scanner with native DICOM JPEG XL output
#32Earlier quoted context omitted.
It's two different teams inside Google. Some part of the Chrome team is trying to quash JPEG XL.
Sure, but if it becomes political I expect the Chrome team to fully quash the JPEG XL team to hurt Firefox and JPEG XL in one go.
Other than Jon at Cloudinary, everyone involved with JXL development, from creation of the standard to the libjxl library, works at Google Research in Zurich. The Chrome team in California has zero authority over them. They've also made a lot of stuff that's in Chrome, like Lossless WebP, Brotli, WOFF, the Highway SIMD library (actually created for libjxl and later spun off).
Re: Philips announces digital pathology scanner with native DICOM JPEG XL output
#33Earlier quoted context omitted.
It's already under consideration but needs some work first: https://github.com/mozilla/standards-positions/pull/1064
Strange that Mozilla is going to rely on an internal team at Google to build a decoder for them in Rust, when Google is the one trying to kill JPEGXL.
Those writing the new Rust decoder are largely people who worked on the standard and on the original C++ implementation, + contributions from the author of jxl-oxide (who is not at Google).
Re: Philips announces digital pathology scanner with native DICOM JPEG XL output
#34Earlier quoted context omitted.
It's two different teams inside Google. Some part of the Chrome team is trying to quash JPEG XL.
Sure, but if it becomes political I expect the Chrome team to fully quash the JPEG XL team to hurt Firefox and JPEG XL in one go.
I'd argue the thread up through the comment you are replying to is fact-free gossiping - I'm wondering if it was an invitation to repeat the fact-free gossip, the comment doesn't read that way. Reads to me as more exasperated, so exasperated they're willing to speak publicly and establish facts.
My $0.02, since the gap here on perception of the situation fascinates me:
JPEG XL as a technical project was a real nightmare, I am not surprised at all to find Mozilla is waiting for a real decoder.
If you get _any_ FAANG engineer involved in this mess a beer || truth serum, they'll have 0 idea why this has so much mindshare, modulo it sounds like something familiar (JPEG) and people invented nonsense like "Chrome want[s] to kill it" while it has the attention of an absurd amount of engineers to get it into shipping shape.
(surprisingly, Firefox is not attributed this - they also do not support it yet, and they are not doing anything _other_ than awaiting Chrome's work for it!)
Re: Philips announces digital pathology scanner with native DICOM JPEG XL output
#35Earlier quoted context omitted.
Someone using JPEGXL in a real world product
jpegxl is supported by pretty much every relevant program that deals with images. The web situation is purely because of Google's monopoly.
But exceedingly few cameras (this is the only one I'm aware of). If I had to guess it's probably encoding in software but still, it's a start.
Re: Philips announces digital pathology scanner with native DICOM JPEG XL output
#36Earlier quoted context omitted.
Sure, but if it becomes political I expect the Chrome team to fully quash the JPEG XL team to hurt Firefox and JPEG XL in one go.
I'd argue the thread up through the comment you are replying to is fact-free gossiping - I'm wondering if it was an invitation to repeat the fact-free gossip, the comment doesn't read that way. Reads to me as more exasperated, so exasperated they're willing to speak publicly and establish facts. My $0.02, since the gap here on perception of the situation fascinates me: JPEG XL as a technical project was a real nightm…
> they'll have 0 idea why this has so much mindshare
Considering the amount of storage all of these companies are likely allocating to storing jpegs + the bandwidth of it all - maybe the instant file size wins?
Re: Philips announces digital pathology scanner with native DICOM JPEG XL output
#37https://connect.mozilla.org/t5/ideas/support-jpeg-xl/idi-p/1... vote for this feature to be natively supported in browsers
Voting for tickets does nothing when there are real reasons not to implement.
Re: Philips announces digital pathology scanner with native DICOM JPEG XL output
#38Earlier quoted context omitted.
It's already under consideration but needs some work first: https://github.com/mozilla/standards-positions/pull/1064
Strange that Mozilla is going to rely on an internal team at Google to build a decoder for them in Rust, when Google is the one trying to kill JPEGXL.
Sheesh. Google isn't trying to kill jxl, they just think its a bad fit for their product.
There is a huge difference between deciding not to do something because the benefit vs complexity trade off doesn't make sense, and actively trying to kill something.
FWIW i agree with google, avif is a much better format for the web. Pathology imaging is a bit of a different use case, where jpeg-xl is a better fit than avif would be.
Re: Philips announces digital pathology scanner with native DICOM JPEG XL output
#39Earlier quoted context omitted.
I'd argue the thread up through the comment you are replying to is fact-free gossiping - I'm wondering if it was an invitation to repeat the fact-free gossip, the comment doesn't read that way. Reads to me as more exasperated, so exasperated they're willing to speak publicly and establish facts. My $0.02, since the gap here on perception of the situation fascinates me: JPEG XL as a technical project was a real nightm…
> they'll have 0 idea why this has so much mindshare Considering the amount of storage all of these companies are likely allocating to storing jpegs + the bandwidth of it all - maybe the instant file size wins?
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 decoding speed than jxl anyways.
Re: Philips announces digital pathology scanner with native DICOM JPEG XL output
#40Can someone comment on what is newsworthy about this?
Basically there is a conspiracy theory that google is trying to kill jpeg xl, so the anti-google crowd is excited someone is using it.
The truth is that every image format added to a web browser has to be supported forever, so chrome team is wary of adding new file formats unless its an above and beyond improvement. Jpeg XL isn't (relative to avif) so google decided not to implement. Its not some malicious conspiracy, it just didn't make sense from a product perspective.
From what i understand https://storage.googleapis.com/avif-comparison/index.html is what was used to justify google chosing avif over jpeg-xl. Jpeg-xl was better at lossless images but avif was better at lossy, and lossy is the usecase that matters more to the web.