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

It's nice to see Safari lead the pack: https://caniuse.com/jpegxl

It's already under consideration but needs some work first: https://github.com/mozilla/standards-positions/pull/1064

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

Voting for tickets does nothing when there are real reasons not to implement.

They sold them off to Cirdan, they are not doing much with the software...

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.

JPEG XL is alive despite google trying their best to kill it and is used to treat cancer

Someone using JPEGXL in a real world product

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.

nerds desperately clinging to any hope that jpeg xl will be revived

A medical device that outputs a standard image format instead of proprietary garbage

Nerds like JPEG XL but Google is trying to kill it.

Image data is just encapsulated: you just take a jpeg file and write it to bytes and wrap it a little.