Hacker News Reader

Comment by refibrillator | Hacker News Reader

One of the cooler and lesser known features of JPEG XL is a mode to losslessly transcode from JPEG while achieving ~20% space reduction. It’s reversible too because the original entropy coded bitstream is untouched.

Notably GCP is rolling this out to their DICOM store API, so you get the space savings of JXL but can transcode on the fly for applications that need to be served JPEG.

Only know this because we have tens of PBs in their DICOM store and stand to save a substantial amount of $ on an absurdly large annual bill.

Native browser support is on our wishlist and our contacts indicate the chrome team will get there eventually.

View on HN

If it's reversible, why not just store as JPEG XL and then convert back when it's served? Does it take a lot of processing time?

You can do that and that's one of the big appeals. You can serve bost JXL and JPEG from the same source and you8 can actually serve downscaled versions of the JXL image from the original bytestream.

Also OP did say "transcode on the fly" to serve JPEG, not actually storing as JPEG.

Isn’t that what the comment you’re replying to is suggesting?

I think GP only wants to convert images back for users with legacy browsers, not for everyone. So converting 100% of the images needs more compute money than the amount of storage money it saves, but only converting ~1% of the images on-the-fly would be worth it financially.

Didn't have time to test GCP DICOM store back in the day (not that I'm going to use it, as I've always been working in-house...), but, how is it? Is it a full fledged PACS? a WADO implementation? just a custom API?

Compared to an average jpeg encoder, or something like mozjpeg?

What's the point of transcoding? You still have to store the original DICOM right? That's probably the bulk of the cost

This is for when you receive JPEG encoded DICOMs. You transcode them to JPEG XL (saving that 20% of storage) and then, if a modality/viewer/whatever that needs JPEG requests them, they're transcoded on the flight to JPEG losslessly.

Losslessly meaning, with the same quality than the original JPEG received by the storage.

>Only know this because we have tens of PBs in their DICOM store and stand to save a substantial amount of $ on an absurdly large annual bill.

So basically JXL is only being pushed to Chrome within Google because GCP have large clients that benefits from this and want this to be default.

Reply on news.ycombinator.com