Philips announces digital pathology scanner with native DICOM JPEG XL output
31 comments
·September 20, 2025CaliforniaKarl
yread
> If you want files in TIFF format, you (the lab tech) have to take an action to export a side in TIFF. It can take up a fair amount of lab tech time.
Worse, you have to do it manually one by one in their interface, it takes like 30 minutes per slide and you only have like 20 minutes after it's done to pick it up and save it somewhere useful otherwise the temporary file gets lost.
DICOM is of course the way to go, but it does have its rough edges - stupid multiple files, sparse shit, concatenated levels and now Philips is the only vendor who makes JPEG XL (next to jpeg, jp2k and jpeg xr).
We learnt to live with iSyntax (and iSyntax2), if you can get access to them that is. In most deployments the whole system is a closed appliance and you have no access to the filesystem to get the damn files out.
zokier
In case others are not aware what "pathology scanner" is, apparently it is a device to scan/image microscope slides. Found some specs, apparently these Philips units do 0.25um/px and 15mm x 15mm imaging area, making the output images presumably 60000 x 60000 pixels in size. Apparently Philips previously used their own "iSyntax" format, and also JPEG2000 DICOM files for these devices.
sandGorgon
https://connect.mozilla.org/t5/ideas/support-jpeg-xl/idi-p/1...
vote for this feature to be natively supported in browsers
CharlesW
It's nice to see Safari lead the pack: https://caniuse.com/jpegxl
Vinnl
It's already under consideration but needs some work first: https://github.com/mozilla/standards-positions/pull/1064
righthand
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.
Mindless2112
It's two different teams inside Google. Some part of the Chrome team is trying to quash JPEG XL.
jiggawatts
And then to actually support the HDR images that can be encoded with JPEG XL, they'd have to implement HDR in the browser graphics pipeline.
Any decade now, any decade...
adolph
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...
dom96
My 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.
yread
They sold them off to Cirdan which is not doing much with the software
TheChaplain
Always impressed when someone does anything with DICOM, it's a bit complex format IMHO.
Dayshine
Image data is just encapsulated: you just take a jpeg file and write it to bytes and wrap it a little.
avalys
Can someone comment on what is newsworthy about this?
kiicia
JPEG XL is alive despite google trying their best to kill it and is used to treat cancer
arccy
nerds desperately clinging to any hope that jpeg xl will be revived
kangalioo
Someone using JPEGXL in a real world product
ndriscoll
jpegxl is supported by pretty much every relevant program that deals with images. The web situation is purely because of Google's monopoly.
Hamuko
There has to be someone else since my dad just emailed me a JPEGXL image less than 15 minutes ago. No idea on how he produced or procured it.
UltraSane
Nerds like JPEG XL but Google is trying to kill it.
ThrowawayTestr
A medical device that outputs a standard image format instead of proprietary garbage
lostlogin
The cluster fuck that is DICOM and HL7 once vendors go to town is far from the ‘open’ utopia we dream of.
null
formerly_proven
WebP artifacts not pathological enough?
Ugh, Pathology image processing is really annoying.
IF Philips is going to stick to the DICOM format, and not add lots of proprietary stuff, _and_ it's the format that it uses internally, then this will be good.
For example, folks can check out OpenSlide (https://openslide.org) and have a look at all the different slide formats that exist. If you dig in to Philips' entry, you'll see that OpenSlide does not support Philips' non-TIFF format (iSyntax), and that the TIFF format is an "export format".
If you have a Philips microscope that uses iSyntax, you are very limited on what non-Philips software you can use. If you want files in TIFF format, you (the lab tech) have to take an action to export a side in TIFF. It can take up a fair amount of lab tech time.
Ideally, the microscope should immediately store the images in an open format, with metadata that workflow software can use to check if a scanning run is complete. I _hope_ that will be able to happen here!