I just saw there is a new open source backwards compatible jpeg format coming out.
“The format will benefit photographers by including a wide color gamut, HDR (high dynamic range), and high bit depth images.”
Regretfully, as usual, it could be bloated with a lot of patents 
Supposedly its royalty free.
Google hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license
3 Likes
JPEG XL - a new image encoding format.
The official name of the codec is “JPEG XL”, so with a space, not “JPEG-XL”.
JPEG XL is a new image encoding format (file extension *.jxl). In addition to more efficient compression and support for modern standards such as HDR, it features backwards compatibility with JPEG files.
More information: JPEG - JPEG XL
A suitable encoder is already in development in GIMP 2.10.24 (‘file-jxl’ plugin for GIMP-2.10 32/64 bits Win samj Créations: Plugin 'file-jxl' pour GIMP-2.10 32/64 bits Win 29 September 2021r) and in development version
GIMP 2.99.8 Development version: GIMP 2.99.8 Released - GIMP
(compiled thanks to Daniel Novomesk`y)
With some work we can upgrade our browsers Google Chrome, Microsoft Edge version 95 or Opera (Firefox for now only in Nightly version) to view *.jxl files, and I can also do it in XnView MP, IrfanView, a customized Windows Photo Viewer.
There are several sources on the net where you can download up-to-date versions of the cjxl.exe encoder (Binaries ) to convert your files for example jpeg, png, gif to jxl (you have to write yourself a small windows batch file to convert all images in a specific directory).
This is just preliminary information on the above topic.
Please find attached below files of visual comparison of the possible results.
Here some of the test results achieved:
[because it contains very many comparisons of different jpg, png, tiff, webp, fliff files … In total, a sizeable folder of about 350MB
Also includes to visualize all IrfanView portable files.
I think generally everyone will be impressed by the effects of the coming new era of compression and network changes.
Just to make it clear, IrfanView is also a test version !]
At the moment, for example. GIMP writes and reads files individually, IrfanView, XnView MP…
I wrote myself a little Windows batch file and.
Takes a minute and the entire jpg, png, and gif folder converted to the Conversion sub folder. At any time I can reverse the process and go lossless to the originals again.
I do this when I deem it necessary to save disk space without sacrificing quality.
Recording as lossless gives us an average file saving of 20%.
For example, I created a folder called Trials and placed in it png, jpg, gif files including animated gifs folder size 100MB after conversion 31MB.
Please note that this format is also used to store e.g. alpha channels, etc.:
1 Like
It’s a shame the format hasn’t taken off. On my computer, ImageMagick is the only software that can read/write it.
Once browser support comes, I think it’ll be good.
Some interesting stats from repology.org:
libjxl/jpeg-xl has a spread of 14
libavif has a spread of 26
libjpeg-turbo has a spread of 51
(lib)tiff has a spread of 55
Maybe a couple of reasons for the slow uptake:
- API is still not complete and is changing/stabilizing
and perhaps more importantly
- libjxl is complex to build: there are quite a few dependencies on some “specialized” and cutting-edge (therefore lesser-known) libraries that are just not available on any of the repositories; libjxl therefore just ships them w/ their source code, but most repositories/packagers dislike this “vendored” library approach…
This is the first I’ve heard of this. If I’m not reading this wrong, it is not encumbered the way HEIF is?
One more puzzle piece to a widespread easily viewable high dynamic range future? That day when the effort of learning scene referred editing really starts to pay off in more obvious ways…
On a more immediately practical side, once this is more supported, I could see using this to store my processed images instead of high quality jpegs.
Example png file is 6.6MB received jxl 554kB (left PNG)
Example png file is 20.4MB received jxl 420kB (left PNG)
An example made just now
I’ve been using this since the format was frozen. Trying to keep up2date with windows builds.
I really really like this format. It supports bitdepths higher than 12bpp (unless heif/avid/webp2). Its lossy compression is not a ‘smooth away all the details’ one , its actually more made for photography content vs flat images for instance.
It’s ‘near lossless’ style is out of this world.
Webp1 I never cared about since it’s never used in high bitdepths.
Avif/heif also are really bad supported once you try to get above 8bpp. And it’s even worse if you don’t want 422 or 420.
I don’t know how it compares in a web context (8bpp, 422 or 420 and starved for bits with acceptable quality loss ).
But if you target something like 16bpp and want the only thing to be changed in the image to be the randomness of grain patterns , I didn’t find something that goes as low as this.
Now I hope I tested it well 
There is a jxl irfanview plugin ? The author once said he didn’t think the format was worth his time yet. (Or another better reason :P)
The format has been frozen for quite some time now . So the bitstream it final, which means that if you build a decoder , it will stay compatible with whatever newer encoders come up with.
The demo program (and library)has been thinking away and coming up with new tricks and ways to do stuff, but always writing the same type of compliant jxl file.
Just wanted to clarify that. "The API is not complete " sounds as something bad , while the format specification is perfectly fine and safe to use.
1 Like
In the folder attached to the first message, IrfanView is attached
Just to make it clear, IrfanView is also a test version jxl!
the latest encoder and decoder has been published today
and exiftool.exe in 16.10.2021r
The codestream definition might indeed be frozen so you can decode it in the future, but people looking at this as a serious format alternative for their content need more features than this. There is more to photos than just pixels. For example, the libjxl API is still missing a way to store Exif/XMP metadata in your files (although this is coming very soon).
1 Like
there’s something
Since version 12.23, ExifTool supports reading JPEG XL metadata. ExifTool shows you the file size, image width, image height, image dimensions and number of Megapixels.
According to https://github.com/w3c/csswg-drafts/issues/4929#issuecomment-718849793: “If the optional Exif (or XMP) metadata says something that conflicts with what the codestream says, then a decoder has to ignore the Exif/XMP”
And
In practice, once the process reaches the FDIS stage, the spec is “frozen” and you can use JPEG XL for real.
Again, all of that falls just a bit short for now - metadata is not juts image dimensions and orientation… 
But as I said, it’s coming, we’ll just have to be patient - IMHO the next libjxl 0.7 will be the first version that’ll offer metadata writing and be worth considering for more serious work.
Age may not be on everyone’s side, but patience is a virtue — wait until at least 2023.
Oh very good point.
For me storing scans and other in between files, it’s all just about the pixels so I don’t notice this stuff.
There are commits in gitlab about storing exif blocks in October. So indeed , something is coming but it’s very recent.