Comment by refibrillator

Comment by refibrillator 2 days ago

9 replies

View on Hacker News

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.

tecleandor a day ago

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?

Reply View 0 replies
geokon 2 days ago

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?

Reply View 3 replies
  • OneDeuxTriSeiGo 2 days ago

    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.

    Reply View 0 replies
  • stingraycharles 2 days ago

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

    Reply View 1 reply
    • bmacho a day ago

      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.

      Reply View 0 replies
gonzalohm a day ago

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

Reply View 1 reply
  • tecleandor a day ago

    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.

    Reply View 0 replies
ksec a day ago

>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 View 0 replies