17 ms·
JPEG XL is the standard to beat them all. Like how Opus became the definitive codec for lossy compression for the web. JPEG XL covers nearly every use case for
by lajamerr 4y ago
JPEG XL is the standard to beat them all. Like how Opus became the definitive codec for lossy compression for the web.
JPEG XL covers nearly every use case for images, even replacing GIFs with it's animation support.
Existing JPEGs can also be re-encoded losslessly into JPEG XL format/data structure and get significant file size savings. This backwards compatiability is very important in transitioning to web to JPEG XL seamlessly.
What I'm most excited about for JPEG XL is progressive decoding, I had been following the FLIF project for a while and was disappointed with it's lack of adoption. But it's future found itself in JPEG XL.
Without a doubt 5 years now JPEG XL will become like Opus and set the standard for next generation image formats.
- mgraczyk 4y agoI used to think this, but I've lost confidence over the last year. I literally work on the software that generates jpg files on Googles Pixel phones, and there seems to be no realistic path to JPEG XL adoption within the next 5 years.
- jl6 4y agoWhy not? What’s stopping the next Pixel phone producing JPEG XL images the same way the iPhone switched to HEIC images a few years back?
- mgraczyk 4y agoTo first approximation, nothing. And it's possible that we will at some point in the near future. The problem is consuming it. You won't be able to view the photo on device until Android adds it, or until the gallery and camera apps add custom software decoders. You won't be able to share with anybody until Facebook/Whatsapp/etc add support. you won't be able to view online until the browsers add support....
- ComputerGuru 4y agoI’ve read up about JPEG XL in the past but a question just occurred to me: is it just an image format or is it also a document format? Can it replace TIFF as a container for multi-page documents/images?
- lajamerr 4y agoNo, it's not a document format. JPEG XL won't replace TIFFs by and large because it has a different use case. TIFFs are more in-line with a combination of FLAC/WAV from the audio world. It's meant for raw data used in production/manipulation. As a professional you would work with TIFFs/RAW photo formats and then master it in JPEG XL for mass-consumption.
- ComputerGuru 4y agoI’m aware that it isn’t meant to replace TIFF, but merely having document/multi-page support wouldn’t do that (or at least, not for most pro usages). There’s a severe dearth of consumer-friendly multi-page static image containers that don’t start with the letters P and D and end with F, and it would be great if someone in a position of influence would suggest such a format (especially if it really were just “multiple page support” and not “everything plus the kitchen sink masquerading as a multi-page image/document format).
- pmoriarty 4y agoDoes lossless JPEG XL support 16-bit images?
- lajamerr 4y agoJPEG XL supports 24-bit integers/32-bit floats per channel.
- MallocVoidstar 4y agoI gave cjxl a 16-bit depth PNG, told it to use lossless encoding, and it gave me a 16-bit depth JXL. Seems so.
- rektide 4y agoAlso ticks the HDR box! As I comment elsewhere[1] it also has an experimental fast mode in tree that is crazy fast, using AVX2, NEON, or fallback. Hopefully Microsoft patenting the thing someone else invented (ANS)[2] doesn't gum this all up. [1] https://news.ycombinator.com/item?id=31658871 https://news.ycombinator.com/item?id=31658871 [2] https://news.ycombinator.com/item?id=31657383 https://news.ycombinator.com/item?id=31657383
- JyrkiAlakuijala 4y agoJPEG XL in lossy mode models SDR and HDR images using the same model (absolute color XYB). This reduces tweaking and makes it easier technically to create mixed SDR/HDR composites, animations or overlays. All other coding systems that I know of use a different coding method for SDR and HDR, meaning that the quality settings and other encoding parameters are slightly different for these modes.
- amelius 4y agoIsn't JPEG patent-encumbered technology?
- dharmab 4y agoJPEG XL is a different technology than the original JPEG format. (JPEG is also the name of the organization that contributed to both formats.) JPEG legacy's patent expired in 2006 although lawsuits continued afterward. JPEG XL is royalty free.
- calibas 4y agoEverything about JPEG XL sounds great, except that it takes about 34 times longer to encode an image compared to PNG. Edit: Apparently there's an experimental faster version: https://github.com/libjxl/libjxl/tree/main/experimental/fast_lossless https://github.com/libjxl/libjxl/tree/main/experimental/fast...
- edflsafoiewq 4y agoDepends, are you optimizing the PNG? Because cjxl is a hell of a lot faster for a much smaller file than zopflipng.
- klodolph 4y agozopflipng is a very aggressive form of optimization.
- Melatonic 4y agoIf it takes that much longer to encode then I am guessing it takes a lot longer to decode as well which I am going to guess makes it completely out for image sequences, film archiving, VFX work, high end photography, etc etc.
- TylerE 4y agoThat is usually not true. The time spent by high quality encoders is generally trying different settings to find optimals... decoding should be unaffected.
- edflsafoiewq 4y agoIt may take less time actually since it can be parallelized. PNG's big problem is it's serial.
- lifthrasiir 4y agoIn fact, Apple introduced its own extension chunk to PNG to enable parallel decoding, by splitting IDAT into two halves, put a zlib sync flush between them and record the offset to the second half [1]. This kind of split is bulit into JPEG XL. [1] https://www.hackerfactor.com/blog/index.php?/archives/895-Connecting-the-iDOTs.html#c4809 https://www.hackerfactor.com/blog/index.php?/archives/895-Co...
- mikewarot 4y agoHow well does JPEG XL deal with color spaces? I don't know much about them, but understand that not all color spaces are create equal, and data gets lost in conversions.
- lifthrasiir 4y agoJPEG XL bitstreams always have a defined color space, optionally described by an embeded ICC profile. They are a part of bitstreams instead of containers [1] because they are considered necessary to reproduce the exact output. When converting from file formats with an ambiguous color space (e.g. PNG without color space information) cjxl assumes sRGB as far as I know; you can give any display color space to djxl. [1] A JPEG XL file can be a minimal bitstream or an ISOBMFF container, where the latter can contain the actual bitstream and additional metadata like Exif. The bitstream itself should be enough for decoding.
- Iv 4y agoHow does it relate to JPEG2000? I may soon have to recommend a lossy but potentially lossless image format for 3D medical images (with 16 bits channels), would JPEG XL fit this bill?
- lajamerr 4y agoThe future isn't here yet unfortunately. I imagine the doctors would view these images in multitudes of ways(browsers, operating systems, image viewers) with varying level of support. So encoding in a standard that is yet to be entirely finalized and adopted is a bad move as of now. You'd be best off with going with JPEG2000 still if that's what you prefer or DICOM.
- Iv 4y agoOh adoption does not have to be that good. It is for researchers right now, to exchange results. So the only requirement is that it is possible to use it with a somewhat mature lib in python.
- detuur 4y agoI absolutely recommend JXL. It is developed by the JPEG Group as a successor to JPEG2000 and performs better in nearly every metric (big exception currently being encoder speed). JPEG2000 isn't really widely supported, but does have many more libraries available. So unless you expect library availability and/or encoder speed to hurt adoption, go for JXL.
- Iv 4y agoThanks I'll give it a try!
- andbberger 4y agoyou should use NIfTI, which is the de facto standard for 3D medical imaging. not compressed, but handles the voxel-image space transform which is far far more important and quite complicated. you can slap gzip on top of it and most libraries/FIJI will transparently decompress
- Vladimof 4y ago> Opus became the definitive codec for lossy compression for the web. never heard of Opus for images... must have been sleeping
- lajamerr 4y ago:P I assumed anyone reading it would know Opus is an Audio-codec. Was comparing the paradigm of where I see image codecs going with a similar one that happened in audio.
- lifthrasiir 4y agoThey are also common in that they are effectively two different codecs combined.
- Beltalowda 4y ago> Without a doubt 5 years now JPEG XL will become like Opus and set the standard for next generation image formats. I wrote a little X11 screenshot tool last year; one of the reasons I wrote it is because I wanted to save images as WebP rather than PNG that most tools use, since it's quite a bit smaller. Not that I'm running out of disk space, but it just seemed nice; one of those "no, it's not really needed but it's fun and why not?" weekend projects. Anyhow, I discovered that loads of stuff doesn't support WebP. This was unexpected as it's been around for ages and supported by almost everything, but things like uploading to GitHub, Telegram, and many services doesn't work. It was disappointing and I had to add PNG support just for that. I fear that JPEG XL will be in a similar situation in the future, where loads of websites can and do use it for their images, but also loads of services don't support it so it's a lot less useful than it could/should be. I hope I'm wrong.
- Wowfunhappy 4y agoYou could make a similar case for audio. GP described Opus as "the definitive codec for lossy compression", which made me do a bit of a double take. Opus is absolutely the technically superior audio format, but when you want to give users a file you'll be sure they can play, you give them an MP3. I expect JPEG and PNG to become for images what MP3 is today. And I expect H.264 to become that for video. These formats are too ingrained, whatever their technical limitations. Technologists consistently underestimate the power of backwards compatibility. Itanium was better than AMD64, DVORAK is better than QWERTY, and I'm sure Esperanto is lightyears ahead of the monstrosity that is English. But backwards compatibility always wins, because it fits what the world was already designed around. ----- (To be fair to GP, they said Opus is the definitive choice for the web, which may be true for integrated in-browser playback. But in other contexts, well, Amazon sells MP3s, not Opus files.)
- axiolite 4y ago> Itanium was better than AMD64, No, AMD64 is far superior, Itanium's benefits never materialized. Any BOTH offer backwards compatibility, anyhow. > DVORAK is better than QWERTY, Not by enough to matter except in extreme circumstances. I say this as a Dvorak typist. > I'm sure Esperanto is lightyears ahead of the monstrosity that is English. It's not. It is needlessly complicated. "Basic," "Simple," or "Technical" English (which came along a few years after Esperanto) is far simpler and quicker to learn. > But backwards compatibility always wins, because it fits what the world was already designed around. Besides all the above being incorrect, some examples like the rise of ARM serves as a count-point.
- Melatonic 4y agoUnless nobody adopts it? EXR seems like it does all of the high end pro features of JpegXL and more (including 32 bit color). JPEGXL can do some odd stuff like animated gif type images but that seems more like a web end user feature than something professionals would care about. I can see it replacing Jpeg / GIF but I don't see this becoming an industry standard anytime soon.
- guitarbill 4y agoI kind of hope that happens. First of all, still charging for the spec is ridiculous. So most people really have no idea how (over)complicated or long it is, except by trawling through a C++ reference implementation. E.g. AVIF does this much, much better. Do we really need to support images with 4096 channels in a web browser? And the name is going to be super confusing; it's too close to JPEG.
- B1FF_PSUVM 4y agoYeah, but what is the file extension? If it is .jpx, maybe. Otherwise, no. (Only partially kidding, unfortunately. Outcomes sometimes hinge on trivial details.)
- npteljes 4y agoIt's .jxl, apparently. The wiki says so and jpegxl.io's online converter also produces .jxl-s.
- GetJiggyWithout 4y agoThe standard supported by a whopping 9 (!) apps! Sorry, but prevalence of support matters too, and PNG can't be beat there.
- LeoPanthera 4y agoThis is very misleading. Some of those 9 "apps" include imagemagick, ffmpeg, exiftool, libvips, and Qt KImageFormats. These libraries power a vast amount of software. Support is also in beta for Firefox and Chrome.
- thayne 4y agoSo if you are on linux, practically every app that deals with images will work. On windows and mac, it's probably less likely.
- BeFlatXIII 4y agoI wonder why companies with multi-billion dollar budgets for each OS release are such laggards at building in support for formats that presumably would not change much between each release.
- CaptainNegative 4y agoFor one thing, delaying support for basic features lets one ship them as hot features for future launches and updates. Case in point, Apple making a fuss last Monday over finally allowing users to change file extensions in CandyCrushOS^H^H^H^H^H^H^H^H^H^H^H^H iPadOS 16, a move some 51 years after mv was introduced to Unix on which that operating system is ostensibly based.
- pmoriarty 4y ago"So if you are on linux, practically every app that deals with images will work." Linux has way more than 9 apps that deal with images. So if you are on linux, practically every app that deals with images will NOT work with JPEG XL.
- mekster 4y agoIf the format is meant to be the next defacto standard, wish they made the name more distinguishable. People without fully understanding it will abbreviate to JPEG as well and definitely cause confusion.