Jpeg XL / jxl support
Jpeg XL is a new image format poised to replace Jpeg. It's got the support of major corporations like Google, Facebook and Adobe. GIMP already supports the format. Chrome, Edge, Opera and Firefox support the format as well, albeit locked behind a config flag for the time being.
It offers excellent lossy and lossless compression, over 4000 channels in a single image (so it's possible to store entire PBR sets in a single file), alpha transparency, animation and HDR/wide gamut. The reference implementation is available under a permissive license .
Please allow blender to use Jpeg XL as an input/output format.
18 Comments
I would like to dig this topic up again, since I think there is a use-case for JXL that none of the currently supported formats is good at.
tl;dr: JXL can store 16 and 32 bit float render passes (up to 4096 channels) at very small file sizes, and I want to use it instead of EXR.
Since the entire discussion seemed to be about Google, Facebook and browsers so far, let me quickly address this.
From my point of view, if browser support mattered, we wouldn't have OpenEXR and JP2 either. So please let's stop using browser support as an argument to allow/reject new formats.
Blender 3.2 introduced Webm support. It's faster than PNG, and supposedly has ~35% smaller files. Google strong-armed it into every browser, yet it's useless for me. It's only 8 bit, so not fit for storing log files, or anything you want to color correct later. Its lossy format is absolutely awful with forced 4:2:0 chroma, resulting in blurry colors. None of the art sites I upload to support it. Mostly it's a format that CDNs use to save a few bucks by converting images into a blurry mess, not something that actual humans use to save images.
The previous commenter criticized JP2 not being supported in browsers, but ironically I use that pretty often when I don't need lossless files. Since it's 16 bit, and can be imported in DaVinci Resolve, it's a pretty decent intermediate format, if you want an image sequence instead of MOV or MXF files. (Not relevant for this discussion, but all digital cinemas use JP2, so it found a niche that it dominates 100%.)
But let's get back to OpenEXR. It has some awesome features that don't matter for browsers, but matter a lot for Blender, like storing all render passes in 32 bit float channels for later compositing. Sadly that produces absolutely massive files. Because of that, I can't justify using it for animations, especially if I need to pull rendered frames from AWS, which bills by stored and transmitted data volume.
JXL (JPEG-XL) supports 32 bit float channels, and can store up to 4096 channels. It can compress them lossless or lossy.
Currently its not possible to test everything by using the reference implementation, since it has limited support for converting EXR files right now.
So what I could do for now is a simple compression test using 16 bit float.
I saved a 1080p render to 16 bit float single layer EXR files. File sizes: Uncompressed: 16.9 MB PIZ: 7.8 MB ZIP: 8.1 MB
Then converted it to JXL, using cjxl, setting only the quality and keeping the rest at defaults. The quality can be set from 0.0 (lossless) to 25.0 (very lossy). File sizes: 0.0 (lossless): 6.0 MB 0.1: 1.8 MB 0.5: 745.8 KB 1.0: 490.7 KB
I stopped at 1.0, since I wouldn't go higher than that. At 200% zoom, there is no noticeable difference between 0.0 and 0.5, unless I do an A/B comparison. Especially for denoised Cycles renders saved at 0.5, it's impossible to tell if you're looking at a compression or denoising artifact, so I could see myself using 0.5 as my default. So that would be a compression ratio of about 23:1 compared to the uncompressed EXR file, or about 11:1 compared to the PIZ/ZIP versions.
So my argument in favor of JXL is, that, if I'm allowed to use it, it would replace EXR for me in most scenarios, since it means I only have to pay 1/11 the price for S3 storage and data transfers, and would only use 1/11 the amount of local storage too.
I'd like to point out that blender already integrates libavcodec, and libavcodec contains a libjxl wrapper to support JPEG XL reading/writing, although the libavcodec libjxl wrapper does not support the large channel count that would be needed to store extra render passes (just like how it doesn't support it with OpenEXR).
At the very least, this enables easy JPEG XL export/import. Other graphics applications such as Krita and GIMP support JPEG XL, which allows us to avoid PNG between compositing and postproc.
Solid thumbs up. This would be huge.
Interesting update:
AVIF might be soon added to Blender , which among other things:
Apple have just announced they are giving their full support to Jpeg XL
MacOS Sonoma have OS-level support for JPEG XL. Something to keep in mind, considering that Blender is on MacOS, too.
It looks like it's far from being widely supported yet. All major web browser only have a flag about it. Operating systems need an external tool, and only a few image viewers have a support. github.com/libjxl/libjxl/blob/main/doc/software_support.md
So reasonable question you didnt ask, but i will xD why a heck do we need it in blender so much?
Because this is the new jpeg. And the new png. It's true that support is sparse right now, but this is the (near) future - Google and Facebook can't wait to cut their bandwidth costs by 30%. Blender will follow suit sooner or later. Therefore sooner is preferable. The bitstream is frozen and the format is standardized. Now is the best time to support it.
"Only" have a flag about it means they've all implemented it and are just waiting to see if no major bugs crop up. This is not a format that is going away at this point.
Everyone said the same when jp2 came around, or webp, or apng. Years later, these formats are inconsistently used and there's no major usage for them from a user input. It doesn't matter if a format is being designed to be the next standard. It is standard only when people actually adopt it.
And for now, random users don't even think about using something else than jpg and png, professionals use and will keep using EXR.
So why even bother adding a library at a time when we don't even know if it will even be actually used by users?
Furthermore, I find it surprising you tell 'Blender will follow suit sooner or later' when, Blender's file output has been dragging behind and untouched for years.
There are many widely used formats and codecs which users have been complaining about for years, and Blender still doesn't have. Like GIF, HEVC, hardware accelerated encodings, ...
There isn't much support for EXR's yet we still use them. This is a similar thing. It's not a format for the consumers but for the producers.
Quite the contrary, they are MASSIVELY used in the industry.
Yes but your argument is that JPEG XL is not supported in browsers or operating systems, which EXR also isn't unless you use external image viewers like you said for JXL, so if we go by that logic then EXR shouldn't have been supported in Blender.
Regardless on if they have huge adoption or not yet, i don't think it's fair to treat formats solely on that when they have benefits that could be handy to many people, like the ability to use 4096 extra layers which sounds insanely useful for putting many textures in the same file saving space, or how it compresses a lot better than pretty much any other option currently available.
If every developer treated new formats as "We shouldn't support them, they're not widely used yet", then it could kill off every new format that arrives before they even have a chance to show what they're capable of, and we would be stuck with the same old file formats that sure, everyone uses, but that are generally obsolete, like the GIF format, which still has no competitor despite how far behind it is by today's standards because nobody bothered to support the newer formats.
And people will only adopt them when the software they use actually supports it, this is not in the hands of the people, it's in the hands of the tools the people use, because no matter how good the file format is, if nothing you use supports it, you will never find the chance to use it, and if you have to jump through many hoops to even be able to save your file as the new format, nobody will want to use it, which is why it's extremely important that developers support new formats so that they're as easy to use as any other.
you forget that EXR is a production format. its target isn't to be displayed on a random page on the internet nor on random people's cat pic library. Jpeg XL is developped specifically for it afaik.
JXL is not designed as just a web delivery image format (it wouldn't need its 4096 32bit float channels for that), but also not designed as just a production image format (it wouldn't need its progressive decoding for that). Instead, it's designed as a universal image format that can be used for production, storage, and delivery.
I would recommend having a look at my wall of text up there. The JXL specification seems to support everything needed to put it on par with EXR, except that it produces files that are 1/11th the size, which would finally make animations with render passes feasible for individuals and small studios.
Blender is still not an industry standard in big studios, but that's no reason to shutdown further development and adoption. The same way JXL is not an industry standard in big studios, but that's also not a reason to give up on its adoption.
People can only adopt new tools if they get their hands on them, and JXL could become a very powerful tool for people who can't afford to use giant EXR files.
"Everyone said the same when jp2 came around, or webp, or apng"
With that being true, JXL has one thing the others don't which can be big for the web: you can, lossless that is, re-compress JPEG files with JXL and save like 20% and you can create JPG compatible JXLs. The artifacts aren't as severe, it's often faster to save, noticeably faster to load due to it being multi-threaded, unlike PNGs aging Deflate algorithm, properly supports HDR and thermal cams..
WebP is something I encounter online on a regular basis, Discord and Reddit use it for example. It IS used, but 4:2:0 bad for textures and IMO a last-resort option for images.
.GIF support really should be a thing, but HEVC might be problematic simply due to licensing/patent issues.
Checked the JXL wiki page to see how official support goes for now. Fortunately they have an "Official support" chapter:
JPEG XL - Wikiwand
Could be a temporary issue, but I think it isn't far-fetched to think that a removal of support after over a year isn't good news.
On the bright side, we can see some other FOSS packages do support is like Krita and GIMP, some libraries like FFmpeg and ImageMagick, and even Affinity Photo. But not Photoshop, nor other 3D packages like Maya or renderers. Though, it could just be there and undocumented.
Admittedly, if all it takes to get JXL into Blender is to click a checkbox somewhere at build time and add a few lines to show it in the format dropdown and expose at least the basic format options, then I guess there isn't much to debate anyway since it's a nice format on paper.
But there are other formats we don't have, including new ones like AVIF for example, even though Blender got the AV1 codec via FFmpeg.