I find Philips quite an interesting player in imaging, PACS and related space. At the innovation space they might be coming up with new technologies and solutions but during service and delivery side they provide quite an awful service, at least in my personal experience in Singapore. I have friends at various healthcare institutions and we were just surprised how could the service be so bad for a vendor who is considered as a valuable one in the industry.
Philips announces digital pathology scanner with native DICOM JPEG XL output
41–50 of 56 posts
Re: Philips announces digital pathology scanner with native DICOM JPEG XL output
#42Earlier quoted context omitted.
> 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 de…
jxl let’s you further compress existing JPEG files without additional artifacting, which is significant given how many jpeg files already exist.
Re: Philips announces digital pathology scanner with native DICOM JPEG XL output
#43I find Philips quite an interesting player in imaging, PACS and related space. At the innovation space they might be coming up with new technologies and solutions but during service and delivery side they provide quite an awful service, at least in my personal experience in Singapore. I have friends at various healthcare institutions and we were just surprised how could the service be so bad for a vendor who is consi…
Their RIS and PACS software is also objectively poor, and they actively promote vendor lockin with solutions like iSyntax in the old IntelliSpace, and a horrifically bad and non-conforming IHE SWF implementation in Vue (which is partly Carestream’s fault to be fair).
They will also prefer to gaslight their clients rather than fix issues, and good luck if you’re already committed to an (un)managed service from them.
Re: Philips announces digital pathology scanner with native DICOM JPEG XL output
#44Earlier 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…
> JPEG XL as a technical project was a real nightmare
Why?
> (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!)
There is no waiting on Chrome involved in: https://bugzilla.mozilla.org/show_bug.cgi?id=1986393
Re: Philips announces digital pathology scanner with native DICOM JPEG XL output
#45Earlier quoted context omitted.
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 wou…
[deleted]
Re: Philips announces digital pathology scanner with native DICOM JPEG XL output
#46Always impressed when someone does anything with DICOM, it's a bit complex format IMHO.
Image data is just encapsulated: you just take a jpeg file and write it to bytes and wrap it a little.
That’s misleading.
- medicine chooses lossless formats
- there are security concerns with decoders and operating systems
- once you build a medical device, the future of your company depends on being able to expensively patch it
Re: Philips announces digital pathology scanner with native DICOM JPEG XL output
#47Re: Philips announces digital pathology scanner with native DICOM JPEG XL output
#48Earlier 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…
> (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!)
The fuck are you talking about? The jxl-rs library Firefox is waiting on is developed by mostly the exact same people who made libjxl which you say sucks so much.
In any case, JXL obviously has mindshare due to the features it has as a format, not the merits of the reference decoder.
Re: Philips announces digital pathology scanner with native DICOM JPEG XL output
#49My first ever job in software was working for PathXL (a Belfast startup implementing digital pathology software). Lots of fond memories working there, including how cool it was working on what was effectively Google Maps but for massive tissue sample images. PathXL actually ended up getting acquired by Philips, seems like a great match if they're building the hardware for this.
They sold them off to Cirdan, they are not doing much with the software...
Oh interesting, I missed that. Pity that Philips sold them off.
Re: Philips announces digital pathology scanner with native DICOM JPEG XL output
#50Earlier quoted context omitted.
> 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 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 faster and faster to decode as you reduce the quality; it's only faster to decode than JXL for low quality images. And about half of all JPEG images on the web are high 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. WebP beats JPEG at low quality, but is literally incapable of very high quality[1] and is worse than JPEG at high quality. AVIF is really good at low quality but fails to be much of an improvement at high quality. For high resolution in combination with high quality, AVIF even manages to be worse than JPEG.
[1] Except for the lossless mode which was developed by Jyrki at Google Zurich in response to Mozilla's demand that any new web image format should have good lossless support.