8 ms·
As a radiology software developer: please please let JPEG XL become a thing. I sincerely hope this might make Chrome change its mind. JPEG XL is a game changer
by amoerie 3y ago
As a radiology software developer: please please let JPEG XL become a thing.
I sincerely hope this might make Chrome change its mind.
JPEG XL is a game changer for 16 bit lossless images. The technical landscape for these kinds of images today is barren.
- jeffbee 3y agoCan you explain to the rest of us what about JPEG XL applies to that use case? If you asked me to store lossless, 16-bit (per channel, or monochrome, I am assuming) images I would suggest TIFF.
- lonjil 3y agoI think they want better compression. JXL has excellent lossless compression.
- deleted 3y ago[deleted]
- vetinari 3y agoTIFF is a container, it can have payload with different compression schemes, lossy or lossless. Including JXL.
- account42 3y agoTIFF can be used as a container. It also comes with its own (relatively shitty) compression methods which is probably what you'd end up using if you wanted 16-bit TIFFs today. And TIFF as a container for JXL would no less require JXL adoption than plain JXL.
- PaulHoule 3y agoAs a mirrorless photographer who wants to publish photos on the web that look like they came out of a mirrorless camera I want JPEG XL. In trials I've done, AVIF works well for a throwaway splash image for a blog but compression results are not so impressive compared to JPEG or WEBP if you want the image to hold up under close inspection. On the other hand there is something that seems almost infantile about image support in the "operating system" being pivotal. If you read a review of a new MacOS in ArsTechnica you might get the idea that 99% of an OS is about what the buttons look like but in terms of the computer science definition, image codecs are definitely a userspace thing and as a Windows or Linux user I never wait for my OS to support an image format, I just install the codec and code away.
- kps 3y agoAs an ‘operating system’ OS X includes user space tools like the Finder and Quick Look in particular where vendor support is helpful.
- asddubs 3y agoalso crucially, safari
- woah 3y agoDumb question, but why is OS or browser support necessary? Couldn't an HTML canvas element and some JS that can parse the file format display any kind of image that you might want?
- ianlevesque 3y agoA canvas element is not as performant as an image element.
- PaulHoule 3y agoWhen I am serious about images it is all about high performance: upgrading to better data compression (1) speeds up the network and server and reduces (2) network and (3) storage costs. (4) Decompression of the image is another bottleneck and a soft decoder is itself something to download and compile locally. If you use a high-powered device you might not appreciate that performance of a low-end Android device hasn't really improved since 2017. I test with an Android Go device that does pretty well if you feed it scaled images but would struggle with the soft decoder. The native implementation of the decompressor can be much better than one in WebAssembly in that it can use SIMD units on the CPU and many other tricks, including special purpose hardware. That's why Apple is so keen to say that an image format is now supported in the OS, because they codesign the hardware, the OS and the file formats to take advantage of all that.
- Scaevolus 3y agoThere's a JS/WASM polyfill for JXL, but it involves some fragile hacks like MutationObserver and canvas writes, has worse performance than native code, and tends to crash Chrome.
- bick_nyers 3y agoEx-radiology software developer here, and seconded! J2K is good, but here are some advantages of JXL in the context of medical imaging: - Better compression ratios - Ability to modify effort of lossless compression (good for real time transcoding) - Multi-threaded encode and decode - Far superior progressive decoding (great for low bandwidth scenarios, just stream in the lossless quality over time)
- vbezhenar 3y agoDoes it really matter? These days decoding image with JS or Wasm should be fine. It's not video.
- bick_nyers 3y agoVideo is not lossless, a second of high quality video might be a total of 5 megabytes. A mammogram on the other hand, might be 300 images of lossless 4k resolution, which could clock in at about 2 gigabytes. That could be per breast in a given study, and a study could have prior mammograms attached as well. You will hit memory limits, so you need to be able to unload and load data intelligently and quickly.
- simondotau 3y agoImage compression for mammograms seems like a thing ideally suited to a straightforward ML task — a model trained to classify sections of an image which are outside of the area of relevance (i.e. not the breast) and classify details of high importance so that detail can be retained where it's needed. Especially handy that it wouldn't require a new file format. It only requires the encoder to support variable compression. (I know Photoshop supported this for JPEG many decades ago.)
- bick_nyers 3y agoI might be missing the details here, but everything outside the breast should be pretty much black and will get compressed very efficiently (high signal, low noise, easy to predict). Foveated compression sounds like a super cool idea I've never thought about before. Before that, you would need to get radiologists onboard with the idea of something being "diagnostically lossless" (think visually lossless), which is currently a hard sell (some promising research does exist on this)!
- crazygringo 3y agoImages are opened and used in a lot of places that aren't browsers.
- 3y ago
- jez 3y ago> I sincerely hope this might make Chrome change its mind. I take this to suggest that Chrome actively decided against implementing JPEG XL? Did they consider supporting it and reject support for it, or has it simply not been prioritized, but still might be prioritized one day? If the decision was intentional: did they state a reason why?
- csnover 3y agoFrom April: https://arstechnica.com/gadgets/2023/04/free-software-group-decries-google-dropping-space-saving-jpeg-xl-format/ https://arstechnica.com/gadgets/2023/04/free-software-group-... Discussed several times previously on HN: https://news.ycombinator.com/item?id=35589179 https://news.ycombinator.com/item?id=35589179 https://news.ycombinator.com/item?id=33399940 https://news.ycombinator.com/item?id=33399940 https://news.ycombinator.com/item?id=33563378 https://news.ycombinator.com/item?id=33563378
- derefr 3y agoThey did all the work required to implement it, sat around for a few months, and then removed it, before anyone else even noticed it was there / had a chance to start integrating it. My personal conspiracy theory is that some Google engineer who works on Chrome, came up with "JPEG XL support" as a feature they could work on, pushed it through to prod, patted themselves on the back, and forgot about it; but this was all done without first getting sign-off from whoever at Google is trying to push for WebP to be a thing. When that person or group noticed "Chrome now supports JPEG XL", they got that support ripped out.
- asddubs 3y agoit was also only ever hidden behind a flag
- lonjil 3y agoThe work wasn't done by anyone on the Chrome team. Someone at Google Research Zurich (I don't recall who) wrote the patches and submitted them. Actually, I think that they've even kept the patches up to date with newer Chrome releases so in theory it would be easy to re-introduce JXL into Chrome if there is a will to do it...
- kstrauser 3y agoI am suuuper ignorant on the subject, but is this something that could replace DICOM?
- concise_unicorn 3y agoNo, DICOM is a container format that can contain JPEG XL image data
- kstrauser 3y agoAh, I see. What does the contain provide other than image data?
- neandrake 3y agoLots of metadata about the image scan. Patient name/id, etc. and often physics related to the image scan such as the voxel size, units, properties of the imaging equipment, etc. DICOM is also used for other data that isn’t directly related to the visual image such as segmentation of the image, radiotherapy planning info, and so on. There are hundreds of dicom tags (the metadata entries) that can be in the dataset.
- mk_stjames 3y agoNot an expert either by far, but DICOM isn't just images, it's a much larger data structure and following protocol, which deals with the transmission of the data between devices as well. The files are just one part of it. It also supports more dimensions to the data frames other than 2D. The pixel data in DICOM itself uses JPEG however (among other potential pixel compression methods), and it is possible that JPEG XL rolled into DICOM could allow for benefits.
- alwillis 3y ago> As a radiology software developer: please please let JPEG XL become a thing. If things with Apple go well and JPEG XL is supported natively on macOS, iOS and iPadOS this fall, it would be on its way to becoming a thing. After all, 2 billion devices isn't nothin’.