JPEG XL

Weird that jpegli got its own repo, but not jxl-tools like cjxl, which would have a much greater benefit (less dependencies for libjxl}

It was split so that libjxl updates wouldn't hold back jpegli updates. Namely all the fixes for failing decodes which won't officially be released until 0.11 of libjxl

libjxl updates are already holding back libjxl updates... all of the quality improvements apply to libjxl too, they share a lot of code. So by not releasing an update, libjxl is missing out just as much if not even more than jpegli

Forget quality improvements; significant bugfixes too.

Having libjpeg-jpegli integrated more closely with libjxl will hopefully provide more reasons and impetus for people to incorporate libjxl into their projects. But having the complexity and dependencies of cjxl/djxl so deeply entwined into the tree and build system rather than as a separate folder and build system, has an opposite and dampening effect

Although it would be nice if there were separate commands to install libjpeg headers and library, rather than just having 1 ultimate install command that's modified with -D switches

I'm not familiar enough with Cmake to know how to do that.

is it normal that FFmpeg and ImageMagick say that JPEG "losslessly" reconstructed file does not match JXL ? ```$ jxlinfo 1n17lc6ck2041.jxl JPEG XL file format container (ISO/IEC 18181-2) JPEG bitstream reconstruction data available JPEG XL image, 6071x4299, (possibly) lossless, 8-bit RGB Color space: RGB, D65, sRGB primaries, sRGB transfer function, rendering intent: Relative $ compare -metric pae 1n17lc6ck2041.{jxl,jpg} null: 2056 (0.0313725) $ ffmpeg -v warning -i 1n17lc6ck2041.jxl -map 0 -sn -f streamhash -hash crc32 - 0,v,CRC32=913fb90c $ ffmpeg -v warning -i 1n17lc6ck2041.jpg -map 0 -sn -f streamhash -hash crc32 - 0,v,CRC32=c73984f8```

JPEG XL's decoder could possibly be applying deblocking filters or other enhancement

Try decompressing the JXL back to JPEG and the compare them

> Try decompressing the JXL back to JPEG and the compare them wdym, that's what I did with `djxl 1n17lc6ck2041.jxl 1n17lc6ck2041.jpg`

as in ``` cjxl source.jpg image.jxl djxl image.jxl destination.jpg ``` then compare `source.jpg` and `destination.jpg`

The `image.jxl` may be slightly different due to decoding differences

JPEG decoding is not fully defined so different JPEG decoders produce slightly different results and this is just a case of that so when you decode the ".jxl" it's libjxl that is doing the work of decoding it and when you decode the ".jpg" it's whatever JPEG decoder that is bundled into ffmpeg doing the decoding work

``` ➜ jxltest md5 * MD5 (destination.jpg) = 330783450a65d4bd60194a57fac6502b MD5 (image.jxl) = 07ae8eb1ba44b51af871c83321ef40ab MD5 (source.jpg) = 330783450a65d4bd60194a57fac6502b ```

this can also cause it

I'm almost 100% sure it is the case since I almost always get very slightly different results and this is normal

hashes expect the data to be **exactly** the same and doing hashes on the decoded pixels of different JPEG decoders will have different hashes

just tested, can confirm

`source.jpg` and `destination.jpg` are bit identical (md5 match) but `image.jxl` decodes slightly differently to `source.jpg` or `destination.jpg`

it's nothing to be worried about

right JPG matches and I get the same amount of PAE error between reencoded JXL and redecoded JPG

it's nothing to worry about

you shouldn't be able to see a difference, and on the off chance you can it should be a good difference (less blocking)

decoding a JPEG is always a lossy process because JPEGs don't really exist as a direct representation of pixels so JPEG decoders producing different results is only really a problem if they fall out of spec or if someone has a poorly system setup that expects decoded pixels to be identical across different decoders

> expects decoded pixels to be identical

lol kinda silly to use a **lossy** format for anything involving things being "identical"

even if the format has a well-defined spec without deviations

Yes... It's because of slight pixel differences between different jpeg decoder libraries... libjxl and jpegturbo produce very slightly different pixels from the same JPEG data, and that's normal for different JPEG decoders to have slightly different decode output, since it's a lossy format that can be decoded with varying levels of precision.

This question gets asked around 5 times a week by different people

lossy image decoders are allowed to decode image differently, and iirc JPEG doesn't really define max error allowed (or it's too permissive)

remembers me lossy WebP: FFmpeg gave me pixels that were all with an offset of 1 compared to dwebp [⠀](https://cdn.discordapp.com/emojis/867794291652558888.webp?size=48&quality=lossless&name=av1_dogelol)

Pixel values decoded from jpeg would often fall in between the 8 bit levels. Decoders usually do some kind of rounding. lbjxl performs dithering if the pixel values don't match 8 bit values.

As long as you can't see any difference with your eyes between decoders, the lossy compression is working as intended.

Still, this question gets asked so often that maybe we should have an FAQ or something.

People expect all JPEG decoders to produce identical pixel values when converted to an image buffer

And it doesn't immediately occur to people that different decoders produce slightly different output, even in lossy audio for example, like how libmad is considered a superior quality MP3 decoder compared to others

a FAQ was in progress, lead by <@594623456415449088> https://discord.com/channels/794206087879852103/794206087879852106/1247977436478574715 If you want to contribute

How can I sign individual CLA without Google account?

I'll add it.

How's this? **Is Lossless JPEG Transcoding really bit-for-bit accurate?** Converting a JPEG to JPEG XL using `cjxl` and then back to JPEG with `djxl` results in a bit-identical copy of the original JPEG image. However, it’s important to note the JPEG standard leaves room for some interpretation, leading to potential minor variations between different decoders.

... between different decoders, including when decoded directly when using libjxl

- encode .jpg to .jxl - decode .jxl to .png - ??? - profit of your better quality image <:KekDog:805390049033191445>

Reminds me people transcoding mp3 to flac to get lossless quality

Even better if they simply rename the file

Lost information is lost, obviously. But how the remaining information is used to reconstruct an image is not completely fixed (at least not in jpeg and not in jxl). A decoder can be sloppy (trading precision for speed, for example), or it can be more precise. They can both be conforming decoders. It generally doesn't make a huge difference, but e.g. when cramming an HDR image in an (8-bit mode) jpeg, it can make noticeable differences: the result of libjpeg-turbo decoding to 8-bit buffers can look significantly worse than the result of djpegli (or djxl) decoding to 16-bit buffers.

That issue... makes no sense to me. According to the flicker test, the "issue" is close to the realm of hallucinations.

Ok, looking at it again on another screen, I can see the very slight difference in sharpness of the texture. But it's very, very close to my threshold of hallucinatory perception.

lossless means lossless, not visually lossless...

It's about lossy jpeg decoder output

and the minute differences between libjxl and libjpeg-turbo

or mozjpeg

oh, I didn't scroll up so I thought that was about the lossless bug.

The other thing is, if you don't have the original image before jpeg compression, you can't tell which decoder is closer to the original.

djpegli does that btw in one pass

so does jpegli have ready executables 😛

Yes

cjpegli/djpegli

I meant ready-built

They are part of the libjxl compilation.

You just download it. It's right next to cjxl

... why the heck even Nix doesn't bundle that in their jpegxl toolchain...

oh they updated it, now it's just a bunch of stable distros

Isn't this changing though?https://github.com/libjxl/libjxl/pull/3707/commits/5114b1e098aca67a2daf3db8a46e8dc2cead447c

https://github.com/google/jpegli

Yes... I do check commits every other day.. I like jxl a little :)

It's a shame. Would rather they separated `[cd](jxl|jpegli)` first since that would have a much greater benefit for adoption of the library

Having the libraries bundled together costs absolutely nothing and makes sense to do since it's free

But having the tools intertwined into the library adds a lot of complexity and dependencies to the library that makes it harder for people who want to include the library into their own projects

If anything having jpegli and libjxl as a package deal will just increase interest in the newer format

"I see this as an absolute win" :P

I think I see your point

Ideally, if you ask me, I think we should at some point have: - a libjxl-core repo that's just the libjxl library, nothing else, only depends on libhwy - a libppf repo (what's now libjxl_extras_codec), depends on libjxl, libpng, etc (does PackedPixelFile internal representation <-> various codecs) - a jxl tools repo, with cjxl/djxl/jxlinfo, depends only on libjxl and libppf - a benchmarking repo, with benchmark_xl/butteraugli/ssimu2/..., depends on libppf and has libjxl as submodule - a hdr tools repo - a jxl dev repo, which has all of the above as git submodules and contains all the unit tests and CI stuff, and remaining tools like jxl_from_tree (the existing libjxl repo could be turned into this) - a libjpegli repo - a jpegli tools repo - a new repo that implements a "combined high-level library" that offers a simple api for doing one-shot encode/decode where the encoder can produce jpeg (with jpegli), jpeg-in-jxl (like what `cjpegli input.png tmp.jpg; cjxl tmp.jpg output.jxl` would produce, but this can be done more efficiently in one go), and jxl (with libjxl), and the decoder can decode both jpeg and jxl. That would be a clean way to separate things imo.

jpeg-in-jxl is the most cracked idea ever, being able to encode straight to it would be nice

I don't think keeping jpegli in libjxl's codebase is very realistic honestly, someone might want *just* jpegli without a hypothetical perceived bloat of JXL (as much as I dislike to say that)

Though people are already packaging it separately from libjxl, as in Arch Linux where the libjxl package does not contain jpegli, while there is an AUR package for jpegli

Don't you think it's possible to go too far in the other extreme too? Most codec libraries only have a separate "lib" and "tools" tree. As long as you keep the testing/benchmarking stuff optional, and keep the dependencies minimal for people who just want to use the library, then that's as complex as you want to make it. Any additional complexity will just make people confused as hell and wondering what they need to download for their XYZ use case.

libjpegli does not add any additional dependencies or hardly any extra weight to libjxl at all

Except the libjpeg headers

It depends on libjpeg headers and it's not smart enough to use the preinstalled headers in the system include path

But that's not actually that big of a deal.

I would say 3 trees is fine, “lib” “tools” and “benchmarks”

some of the tools like the metrics and the color conversion / hdr tools are not really specific to jxl at all, except they're made by the same people and they reuse some of the libjxl code

I don't think you need a separate library that can be exported for libppf or whatever, just have it be a library that's statically linked to the tools at compile-time

I definitely think cjxl/cjpegli and djxl/djpegli should be bundled together, since they both share 90% of their code...

libjxl (which includes optional dev tools that don't add any additional dependencies and aren't compiled unless enabled), jxl-tools (which includes everything that adds extra dependencies that library users don't need to have), and libjxl-testdata which I think already exists.

Do they?

Do they have the same API?

If so it could help people have an easy upgrade path from JPG to JXL

iirc, that’s because it actually depends on the libjpeg header _templates_ that are used to generate the installed libjpeg headers

the templates are not installed system-wide

no. Jpegli has the libjpeg-turbo API, which is completely different and totally inadequate for jxl.

I dunno about _totally_...

So, I suppose the jpegli folder in libjxl repository becomes a link to the new jpegli repository?

`libjxl-dec` only repo would be useful too for folks maintaining jxl-capable browser forks

browsers might be more into jxl-oxide since rust, and browsers do love rust

true, but that would work for mainline browsers; moving to jxl-oxide for browser forks maintainers would probably be too much overhaul over using pre-existing implementations as base, and only upgrading libjxl version or adding some patches extending functionality (for firefox forks)

I know Firefox does a lot of stuff in Rust, but does Chrome? I thought they were still super into C++.

chrome has been pushing towards rust pretty hard

Just a suggestion, but flac has a -V (verify) mode that decodes the file during encoding to make sure the decoded samples match the input values. It's a pretty good idea for a lossless codec to have this. For relatively immature software like libjxl, it should maybe even be enabled by default for every lossless encode. Just for some assurance that the encode really is mathematically reversible and produces the same exact sample values in the original sample format.

Agreed

That could help foster some more trust and convenience for people who would consider using libjxl to reduce the size of image archive/backups

If I have a large corpus of images that I want to losslessly preserve and shrink using libjxl, currently it's infeasible because of the amount of work required to ensure that it's truly reversible (At least in the sense of getting the same exact sample values, or in the case of JPEG, the same DCT coefficients and metadata/icc profile)

So if it was built into the encoder and library in a convenient and automatic way like just flipping a switch, that would be great

that's my 2 cents :)

Agreed

There are some lossy options usable with `-d 0` as well. The verification would warn the user they're using a lossy feature.

What, like -d 0 -m 0 -epf 1 or something?

I assume the non-lossless lossless images pushed this back a while?

Mostly people being on holidays is delaying v0.11, I guess.

At this pace 1.0 will be released in 2026 instead of 2025 😅

There are options like lossy palette, resampling, bitdepth override etc.

Looks like it was just one dev to fix it in about 8 days

I would assume exhaustive lossless tests will be developed after 0.11

(Ngl, the fact that this issue came up at all makes me wonder how libpng or libwebp guarantees losslessness.)

This particular regression was a race condition bug in multithreading with relatively rare conditions for happening in practice (you need an image that is just slightly larger than 2048x2048), which caused it to remain undetected.

Libpng and libwebp don't do multithreading so that makes it easier to avoid those kind of bugs, I guess 🙂

is there any way to force cjxl to use huffman for entropy coding?

with or without source changes?

well I can edit the source code if needed 🙂

https://github.com/libjxl/libjxl/blob/main/lib/jxl/enc_ans_params.h#L83

make that always true 🙂

ooh okay

it seems to work, thanks!

<:This:805404376658739230> 👍

There really is no hurry. Because it's enough to point a finger to find unfixed bugs and artifacts - that you would not like to see on the release... Although I'm not sure about ambitions and all of like dct 256x256

When using cjxl to make a lossless jxl file from an existing lossy jpg file, the resulting jxl file is lossy. Below is the command I ran, any ideas why this would be? It only occurs if the source is jpg, while png, webp, etc all work fine. `cjxl source.jpg -q 100 -e 9 --lossless_jpeg=0 --num_threads=15 -x strip=exif -x strip=xmp -x strip=jumbf output.jxl`

Also, just noticed the "tools" channel. I just posted here because it was the first channel that came up useful when searching "cjxl". Let me know if that's the more appropriate place to ask this.

How are you checking if it's lossless?

And is there a reason to use `--lossless_jpeg=0`?

I've checked by opening the two files in gimp and checking the color values in different areas, and they are close but not the same. Also, I should be able to convert the original jpg file and the new jxl file to a png and have the hashes match, this is how I noticed the issue originally.

Just for testing. If I disable the pixel re-encode the same thing happens but even more pixel colors are off.

could that not just be within the jpeg margin of error?

If I convert the source jpg file to a png, the pixel colors match exactly between the jpg and the new png file. If I then convert that new png to a jxl file and back to a png again, the colors are still a perfect match. A lossless conversion should not have a margin of error I'd not think?

Basically, right now in order to preserve my image quality, I'm having to first convert my jpg files to png before making them jxl files. This seems a little silly, especially since I'm loosing out on the lossless recompression feature (--lossless_jpeg=1), maybe I'm missing something obvious? haha

jpg itself has a little bit of leeway in how it can be decoded, so im wondering if that's taking effect.

Mozjpeg vs Jpegli vs JpegTurbo, ect

I see. That is probably what's going on, as the colors are just changing, there is not any compression artifacts or anything being added.

And if I recall JXL decoding differs from jpeg decoding slightly too, I know there was a recent discussion about this noting the combinations that do and don't work for verifying

interestingly enough, when I encoded a file with this `cjxl source.jpg -q 100 -e 9 --lossless_jpeg=0 --num_threads=15 -x strip=exif -x strip=xmp -x strip=jumbf output.jxl` vs just `cjxl -e 9` the rendering intent changed from relative to perceptual

Likely the stripped metadata, right?

that shouldn't make a difference since it's srgb, but interesting

Also you can do `-x strip=all`

Or at least used to be able to

I dunno what metadata that would be in so I dunno

```ps ➜ diff <(magick identify -verbose reverse.jxl) <(magick identify -verbose no-reverse.jxl) 26,29c26,29 < standard deviation: 82.0186 (0.321641) < kurtosis: -1.47152 < skewness: 0.177541 < entropy: 0.985663 --- > standard deviation: 81.9497 (0.321371) > kurtosis: -1.47093 > skewness: 0.176782 > entropy: 0.986004 33c33 < mean: 122.941 (0.482123) --- > mean: 122.925 (0.482061) 35,38c35,38 < standard deviation: 83.517 (0.327518) < kurtosis: -1.51971 < skewness: 0.135561 < entropy: 0.982954 --- > standard deviation: 83.5489 (0.327643) > kurtosis: -1.51862 > skewness: 0.135424 > entropy: 0.983019 42c42 < mean: 107.741 (0.422513) --- > mean: 107.881 (0.423062) 44,47c44,47 < standard deviation: 85.414 (0.334957) < kurtosis: -1.353 < skewness: 0.374853 < entropy: 0.972055 --- > standard deviation: 85.4917 (0.335262) > kurtosis: -1.3523 > skewness: 0.375165 > entropy: 0.971709 52c52 < mean: 116.124 (0.45539) --- > mean: 116.161 (0.455533) 54,58c54,58 < standard deviation: 83.6499 (0.328039) < kurtosis: -1.44808 < skewness: 0.229318 < entropy: 0.980224 < Rendering intent: Relative --- > standard deviation: 83.6634 (0.328092) > kurtosis: -1.44729 > skewness: 0.229124 > entropy: 0.980244 > Rendering intent: Perceptual 84,85c84,85 < icc:description: RGB_D65_SRG_Rel_SRG < signature: 2cbc7de4586d92dc4f6a89b6875442a1e8bd1dab4c574bd861fca2830c0d260e --- > icc:description: RGB_D65_SRG_Per_SRG > signature: a3b730ca784b7eb0bfe4e755bfe5b2a9e4b49e9457368372c5df3f0f95347d76 ```

the magick diff is interesting

Yeah, I used compare and was just so confused. lol

these seem tight enough that it may just be rounding error

That does sound right. Transcode would be using the JXL decoder, the pixels would be using jpegli for decoding and then saving that losslessly, so probably closer to Gimp using mozjpeg (or something similar)

From an image preservation standpoint, even though I understand that different decoders can show an image with different color values based on how the math is done, I feel like it's not really "safe" to convert to jxl from jpg if these values are physically changing and essentially "lost" when decoding using the same method (gimp).

Take everything with a grain of salt, but I think I recall the transcode uses Chroma from Luma to try and repair the subsampling, so that would explain the bigger differences

Unless I'm just ignorant and am missing some fundamental understanding, which to be fair may be possible. I'm coming from webp and avif, where I can convert back to png and get a hash perfect conversion every time (using the same encoder).

I mean, the jpeg transcode let's you get the exact same file back, so you can't get much more lossless than that

The jpeg reconstruction?

well in the end, that's why jpeg reconstruction is important, the file decodes differently in ffmpeg, due to the differences and rounding error and what not, but it reconstructs perfectly ```ps ➜ ffmpeg -hide_banner -loglevel error -i reverse.jxl -c:v ppm -f image2pipe - | b3sum a923cc87c284bc9f9b94eb6df58b605d711e672d8f7a09db05e22ecf88223a0c - ➜ ffmpeg -hide_banner -loglevel error -i input.jpg -c:v ppm -f image2pipe - | b3sum c010d16793e755671204543c237093286701ba2c94d38bc651e45058f069bea4 - ➜ b3sum input.jpg reverse.jxl.jpg faa6b9de237443827a5a41f5c4536e3dab770090ad271005c6f10ee642d93ceb input.jpg faa6b9de237443827a5a41f5c4536e3dab770090ad271005c6f10ee642d93ceb reverse.jxl.jpg ```

Yeah, which is also usually smaller than the standard lossless mode too

just djxl a transcoded jxl that you didn't do `--lossless_jpeg=0` on

Also, here's the old thread I mentioned https://discord.com/channels/794206087879852103/804324493420920833/1263767599460778036

That's the missing piece I did not know! xD

That's perfect, and it's working as I'd hoped now, lol. Thanks for all the info!

Always check what you're turning off first! xD

Yup. I was like, hey with this on converting to png is even worse, but now I see if I use the tooling right it gets me where I want to be. haha

Thanks again, you two!

Feel free to ask any more questions in future

or just `cmp` instead of `sha256sum` and comparing the hashes yourself

That's a good point... Technically it's NOT lossless to decode a JPEG and encode the resulting pixels. If it's not lossless, then cjxl should exit with error status instead of trying to encode the lossy decoded pixels losslessly

When I decode a (lossy) jxl that has an embedded ICC profile, djxl creates a new, linear(?!) ICC profile and mangles the colors instead of re-using the same ICC profile embedded in the input file for the output file.

Can anyone decode this without getting terrible banding? https://cdn.discordapp.com/attachments/794206170445119489/1083872278128885790/imagetest15-Q70.jxl

From https://discord.com/channels/794206087879852103/847067365891244042/1083980340164558908

For comparison here it is with `djxl --color_space=RGB_D65_SRG_Rel_SRG` which is still not the same color space embedded in the input file... By default it decodes to `RGB_D65_SRG_Rel_Lin` which would only make sense if decoding to a floating point output buffer...

Is there a way to force cmake to compile the built-in libpng? I'm cross-compiling on Linux for mingw, and it compiles fine, but cmake can't find the png library bundled in (yes, I ran ./deps.sh) which means that it can't get any pixel data

this issue has been reported already, iirc

lemme see if I can find the issue

update:

``` $ wine mingw32/tools/cjxl.exe george.png test.jxl JPEG XL encoder v0.11.0 e10fb685 [AVX2,SSE4,SSE2] ./lib/extras/dec/exr.cc:29: JXL_FAILURE: EXR is not supported ./lib/extras/dec/decode.cc:151: JXL_FAILURE: Codecs failed to decode Getting pixel data failed. ``` well that's probably not supposed to happen now is it

it's definitely a PNG though

``` $ umbrielpng george.png PNG signature found: george.png Chunk: IHDR, Size: 25, Offset: 8, CRC32: fab5570d Chunk: sRGB, Size: 13, Offset: 33, CRC32: d9c92c7f Chunk: IDAT, Size: 1281627, Offset: 46, CRC32: c85fd495 Chunk: IEND, Size: 12, Offset: 1281673, CRC32: ae426082 Size: 1080x720, Color: 8-bit RGB ```

without a fairly complex chunk structure either

Not to derail your question, but this image is a perfect example of the bug in macOS's Preview I've submitted to Apple (on an M1 MacBook Pro running 14.6.1). Seems to be any relatively large image with more than 8 bits:

I linked to the issue.

no, there was a different one

Hello again. I am trying to understand parallel runners in libjxl. Apparently my code doesn't compile due to missing functions in libjxl (linking problem) and I am stuck. My issue: https://github.com/libjxl/libjxl/discussions/3749 Everything else works absolutely fine and beside that, my little program converts a PNG file into lossless JXL without any problems.

Can somebody take a look at my issue? Ty.

Nevermind 😉

That was fast 😅

have you reported this in apple's Feedback app?

Oh yes.

OK, I can confirm at least two of the bugs I reported over the past year are fixed in the latest Sequoia 15.1 Beta (I took the plunge to check!). Preview no longer corrupts as shown in the video above with >8 bits and it now recognizes that it can open JXL files. The other zillion I've filed are a no go, including Preview (and Safari, not that we were expecting that) supporting HDR images…

I can't seem to compress this image https://www.mediafire.com/file/mo42xgq0f4dw8nx/Combined_100%2525.png/file

it's 835MB hence the mediafire

wow, this image bloody sucks

magick failed to convert it ```ps ➜ scratch dua 834.93 MiB Combined_100_.png 27.77 GiB magick--yqEFduwpNou4vopFmb6kcq4Pr943Bsr 28.58 GiB total ```

I cant evennn convert the image to exr using oiiotool

nothing I have can actually convert this file to anything lmao

oh wait, png2pnm is streaming, that decoded it

hydrium?

Ill try out hydrium, but trying to encode the ppm file without streaming caused cjxl to oom [av1_dogelol](https://cdn.discordapp.com/emojis/867794291652558888.webp?size=48&quality=lossless&name=av1_dogelol) to be expected since the decoded ppm is 9.77gib lmao

whats that 834mb png even about? you might need to stream it to encoder

hit heap max ``` ➜ scratch ~/code/hydrium/build/hydrium Combined_100_.png Combined_100_.png.hydrium.jxl libhydrium version 0.4.1 Max libhydrium heap memory: 2185897 bytes ```

or is this just output?

in any case, I can't actually open the image since I don't have a compatible viewer right now lmao, but here are the sizes, i'm assuming hydrium finished, it's quite nice, and that's just output, hydrium certainly didn't kill my PC ```ps ➜ scratch dua 119.69 MiB Combined_100_.png.ppm.default-streaming-in+out.jxl 174.82 MiB Combined_100_.png.hydrium.jxl 591.86 MiB Combined_100_.png.ppm.e3-d0-streaming-in+out.jxl 834.93 MiB Combined_100_.png 9.77 GiB Combined_100_.png.ppm 11.45 GiB total ```

i wonder why it gives a Segmentation fault

it doesn't even try to use all the RAM before giving up

The big hump near the middle is the `cjxl` invocation, system total is 36gb

could a `ect -1` increase compatibility of the image ?

no idea, I deleted it since it was sitting in ram

"might"

So out of all the people who downloaded it, what's the actual resolution?

72622x48128 @ 24 bpp

So (Roughly) 10x10 8K images stitched together

3.5 gigapixels... That's 10 GB for an 8-bit RGB buffer and 40 GB for a float32 buffer...

Awesome!!

Being futureproof for high resolutions is paying off already at least

Isn't the software supposed to break the input file into square chunks as it reads it? Why does the whole thing need to be loaded into memory at the same time?

I know every jxl file is divided into big chunky squares and that's how it seems to use multiple threads and how it theoretically can do roi decoding

It doesn't have to be. Currently cjxl only has streaming input for ppm though. It does have tiled processing and streaming output, but all input formats are still loaded as full buffers except for ppm...

I see. Well streaming input is still relatively new.

The libjxl API supports it, that is the main thing. In the end, cjxl is just a demo application for libjxl.

Speaking of, is there a way for a library or application that uses libjxl to enforce memory limits to prevent denial of service? Would be especially important for libvips for example since it's used a lot on web facing servers

Yep, true. The library is more important.

You can do that if you use your own memory manager. Or you can just decode the header, and decide based on image dimensions (and channel count). We designed things so that memory usage for encode and decode is always at most proportional to the number of samples (though the worst-case constant factor can be quite large, if you e.g. go up the allowed limits of splines, patches and modular MA tree sizes for the highest profile, Main Level 10)

So vips would have to implement their own malloc wrapper that keeps track of how much heap libjxl is using.

Sounds like a lot of work.

And if a malloc were to fail, libjxl won't crash or corrupt the heap by doing out of bounds heap access?

There is example code for that in the fuzzing decoder, it artificially pretends to have limited memory

It shouldn't, modulo bugs of course. But this is one of the reasons fuzzing is done...

That's good... some projects are holding off on including libjxl or adding jxl support because they are waiting for certain issues to be closed on github so they know they can use libjxl without it misbehaving if it encounters a corrupt or maliciously-crafted input file or if a malloc fails. If it's getting fuzzed for these things then maybe those issues can be finally closed until a bug is found or unless there are still some unpredictable cases where it will abort

Once those issues are closed on github, support for the format and adoption of libjxl is expected to grow since a lot of different projects are waiting on that

Sounds like things that will happen when 1.0 releases

They aren't waiting for 1.0, they're waiting for those github issues to be closed

No, I mean the issues will probably be closed as part of 1.0

They should be closed when they're fixed and when there's tests/fuzzing in place, regardless of the version number

I know they are part of 1.0 goals but I don't think they will wait until 1.0 to close the issue, if it's fixed before then

that's just the output. what does it say with `--one-frame`?

hydrium by default makes jxls that are exceptionally slow to decode with libjxl unless you use `--one-frame`

but that uses way more RAM so it's off by default

unfortunately I already deleted the image, but ill DL and run it again once my PC is done updating

not a big deal, I'm just curious

ran time this time too ```ps ➜ test time ~/code/hydrium/build/hydrium --one-frame Combined_100_.png Combined_100_.png.hydrium.jxl libhydrium version 0.4.1 Max libhydrium heap memory: 4576204876 bytes ~/code/hydrium/build/hydrium --one-frame Combined_100_.png 458.20s user 4.83s system 99% cpu 7:45.33 total avg shared (code): 0 KB avg unshared (data/stack): 0 KB total (sum): 0 KB max memory: 4034 MB ➜ test dua 161.27 MiB Combined_100_.png.hydrium.jxl 834.93 MiB Combined_100_.png 996.20 MiB total ```

nice, now it'll decode with libjxl maybe

lol

what happens if you try to decode it with djxl/libjxl?

also I'm surprised by that 99% system time, I wonder if it's because it performs a lot of allocs and frees in order to prevent hoarding memory

Did anyone actually try without `--one-frame` anyway? I mean it'd either go at a snail's pace or just give up, but I'd be curious to see what happens anyway

I don't know. for massive massive images then `--one-frame` is significantly more memory-hungry than every other mode. the biggest compromise is `--tile-size=3` which is one LF group per frame, rather than one group per frame

On Windows it silently fails with WerFault.exe called in the background

well now that's interesting

``` leo@gauss ~/Downloads :( $ time hydrium --tile-size=3 combined.png combined.jxl libhydrium version 0.4.1 malloc(): unsorted double linked list corrupted Aborted (core dumped) real 0m4.369s user 0m3.561s sys 0m0.353s leo@gauss ~/Downloads :( $ valgrind hydrium --tile-size=3 combined.png combined.jxl ==507761== Memcheck, a memory error detector ==507761== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al. ==507761== Using Valgrind-3.23.0 and LibVEX; rerun with -h for copyright info ==507761== Command: hydrium --tile-size=3 combined.png combined.jxl ==507761== libhydrium version 0.4.1 ==507761== Warning: set address range perms: large range [0x4fc6040, 0x1f94b040) (undefined) vex amd64->IR: unhandled instruction bytes: 0xC5 0x79 0xD6 0xC0 0xC5 0x7A 0x7E 0x5 0x41 0xEB vex amd64->IR: REX=0 REX.W=0 REX.R=1 REX.X=0 REX.B=0 vex amd64->IR: VEX=1 VEX.L=0 VEX.nVVVV=0x0 ESC=0F vex amd64->IR: PFX.66=1 PFX.F2=0 PFX.F3=0 ==507761== valgrind: Unrecognised instruction at address 0x485ceb3. ```

this happens even if I set cflags to `-march=x86_64`

actually I lied, it doesn't

which means valgrind may not support fma instructions

which are here `scratchblock[0][y][k] += encoder->xyb[(posy + n) * 3 + c].f * cosine_lut[k - 1][n];`

yea, setting `-march=x86_64` doesn't stop malloc from crashing though, but `LD_PRELOAD=/usr/lib/libtcmalloc.so` does

I heard outstanding things about mimalloc

mimalloc is nice, but I prefer jemalloc, mimalloc has best performance I find, but it's really aggressive and can cause other applications on the PC to slow down if it's being called a lot

Easy solution... Just make all apps use mimalloc! ^o^

I heard it's a good replacement for the default minimal malloc in musl.

The musl malloc is probably the fewest LoC but it chokes when combined with multiple threads.

Hello!! Complete nooby here. Can someone tell me how to make my Windows 11 Notebook to Recognize .jxl files? I mean I already downloaded "jxl-x64-windows-static.zip" file but I'm not sure where to extract it.

https://github.com/saschanaz/jxl-winthumb ^^^This is for windows thumbnails https://github.com/sylikc/jpegview ^^^This is a solid image viewer for jxl files

Thanks for the help. What I'm aiming for is for the Windows 11 OS to recognize .jxl files without the need of third-party software (jxl-winthumb worked, I just want to install libjxl directly). But again, thank you so much for the links, if I don't learn how to install libjxl then i'm definetly using JPEGView as an alternative (also jxl-winthumb)

Major fail that Microsoft doesn't allow third party wic codecs even though they pretend they do

XL Converter seems cool, or just use scoop

Oh, nvm about scoop. if you're a nooby, it's probably not your thing. XL converter is a good interface for converting image files

So sad, JPEG XL is an absolutely amazing codec. I understand Google not supporting it because of WebP preference since they made it, but why Microsoft?

https://codepoems.eu/xl-converter/

Don't get the wrong idea, MS doesn't have it out for JXL specifically

There is evidence they are secretly working on their own jxl codec

It's just annoying that people aren't allowed to write their own module and have it integrate seamlessly into Windows. The closest thing is jxl-winthumb

with Microsoft, it's more they haven't gotten round to it / haven't finished

Also, it's not google. It's literally just the webm/avif tech lead and his team from On2 Technologies who Google put in charge of the Chrome Codec Team with no oversight

so literally just the people who are working on the direct competitor

so massive conflict of interest

Yeah. It's literally that cartoonishly ludicrous and shameless

Man, such impotence. Not sure if I'm correct on saying this but JPEG XL appears to be objectively superior to WebP. After knowing all the different things it can accomplish while being royalty-free I became obsessed with it. That's why I want my Windows 11 machine to fully recognize JPEG XL images thus making it my default image codec.

I just used scoop and "'libjxl' (0.10.3) was installed successfully!"

thanks you so much for the info about scoop, might use it more later

How do I encode multiple images with the same file extension that are in a folder in the main directory? What I mean by that is that I create a new folder (let's say "Images"), then I put all my image files (let's say they are all PNG files) into that folder, and I want to use a cycle (for/while/etc.) that enters Images folder, encode the images one by one and each encoded image must have it's original name (but now instead of .png they are .jxl) and saves said encoded files in Images folder.

I know it's very specific but if anyone can help me, I would greatly appreciate it. for now I have been using this code in FFMPEG: for %f in (*.png*) do ffmpeg -i "%f" -c:v libjxl -distance 0.0 "%~nf.jxl"

but not only it doesn't work for libjxl, it also reads images that are on the main folder

are you unix or windows

Windows 11

sorry idk then

i use mac

No problem. Thanks anyways for the help!!

Maybe PowerToys could implement earlier

It seems quite versatile, I'll take a look. Thanks!!

I love scoop. It's not what newbies usually like but it's perfect for simplifying things with the Terminal

https://xl-docs.codepoems.eu/adding-files

Keep in mind: Blindly batch converting without verification is danger dragon.

Even better is verification using three different decoders.

That actually helped finding and fixing bugs in the decoders.

I feel like everyone immediately forgot them saying they're a noob, and started throwing around pretty complicated stuff

To put it more simply <@383447728685842432> Microsoft are working on adding JXL support, but for now we need separate image viewers Since different programs use libjxl in different ways, I download the static zip and then use cjxl after extracting everything to a folder If you want to set it up for long term use, I made a "Jpeg XL" folder in my Program Files, extracted everything there, and then added the folder to PATH (can look up guides online, it's fairly simple) And this is the command I used to use to convert a folder ```for %i in ("FolderPath\*.png") do cjxl "%i" "FolderPath\%~ni.jxl" -d 0``` If you didn't do the PATH thing, just swap cjxl with the path to it instead The others mentioned verifying the files after, but that can always be done after with a batch file instead

scoop takes care of all that PATH and installation stuff for ya. if you don't use it already I highly recommend you do.

And if you're doing a batch lossless conversion job, it's possible and highly wise to add a decode/verification step after each encode to ensure the decode perfectly matches the original...

If you're writing your own batch conversion script you could ask me or someone else here for advice... For PNG/GIF/BMP etc I would probably use vips to compare pixel data.

Thanks for all the help guys, really appreciate it. How do I add a decode/verification step for all my encoded files? Never thought of that but seems smart to do so, considering I mostly want 100% lossless encoded files.

If there is a built in way, in one of the encoding tools, idk of any. I think you need to do it yourself, if you are writing a bulk conversion script...

For jpeg conversion, I would just decode back to jpeg and make sure the two file streams are identical. For regular lossless comparison? I would probably use vips to compare.

Thanks!!

No prob. If you need help writing a script, just post what you have so far and I or someone else may help suggest improvements.

how do you use vips to compare images automatically?

Good question... It's not obvious. If you're using the vips command line utility, then I think you need to use 2 separate commands. `vips relational` will compare two images...

But then you need to use a second command on the output of `relational` to see if a difference is found, like `vips min`

if you're using the library, then it can be chained together and optimized so that it stops comparing as soon as a difference is found.

You can also use ImageMagick: `compare -metric pae imageA.png imageB.png null:` should return 0

Is PAE as efficient as possible? (Single O(N) loop)?

``` magick "$INPUT" /tmp/image.ppm cjxl /tmp/image.ppm "$OUTPUT" -d 0 djxl "$OUTPUT" /tmp/image2.ppm diff /tmp/image.ppm /tmp/image2.ppm ```

this seems to work for me

only thing is this removes iCC profiles

oh, i forgot the `null:` that's why it was not working for me

Actually `compare` also ignores ICC profiles so it's not perfect

as in converting to `ppm` stripped ICC profiles

Yes, but `compare` just compares sample values and ignores colorspace info too, so it is kind of the same thing

converting to `ppm` means the resulting JXL does not have colour space info. `compare` ignoring colour space is not important to me

the code i gave above converted any input image to `.ppm` which doesn't allow the JXL to have colourspace

imagemagick's identify may be better than diff since it only hashes the image data itself

`identify -format "%#\n" INPUT(s)`

if it's PPM, the only metadata other than image data is the bitdepth and dimensions, so in this instance it's fine

i would agree in most other situations

If I remember correctly libjxl uses abort which is bad for uses by other software and there is plan for fixing this. How far is this goal?

I think it is done, in current git version

I don't think converting to PPM is a good or efficient idea.

no, it's not

that's why im thinking of other solutions

`convert -metric pae` is probably hat ill use

Why can not **-I 10000** <:Stonks:806137886726553651>

presumably, there are only ever 100% pixels

quick question, are there routines for basic resizing using cjxl ?

you can upsample

requires `--resampling` with `--already_downsampled`

Better use ImageMagick

Then there's also --upsampling_mode=0 for nearest neighbour, or something like that

using imagemagick does not cover apps and scripts integrating cjxl

Thanks for the pull request, <@263300458888691714> ! Now e11 is still very slow but an order of magnitude faster, and better. We'll have to be careful, at some point it might actually become a useful effort setting 🙂

I was relying on Luca to catch my mistakes, but he missed something.

Significant density boost when you translate settings correctly. Anyway, yeah, it's still bad, but all the fanatics out there should still be satisfied with this version.

Iterations, not %

but it's comparing to some percentage of pixels, represented by 0-100

<:Thonk:805904896879493180> uhh

`-I` is the percentage of pixels used for MA tree learning, with 0 disabling it and 100 using the entire group

never do that, it's a mistake 😛

thanks for the PR 🙂 it's a very nice improvement

thanks for taking my memey article seriously

Pedantic. 2 keywords are too general right now. Just remove https://github.com/topics/lossy-compression and https://github.com/topics/lossless-compression-algorithm from https://github.com/libjxl/libjxl. The repository has 2 -image-compression keywords and even image-compression. JPEG XL can't compress arbitrary binary files easily...

You already said that exact message before

fab 2

Me when I chuck a PPM header on arbitrary data

Lossy compression is not really a thing for arbitrary binary files 🙂

I tried to force FFmpeg to encode a text file as MP3, you could imagine how well it went

Of course you have to use aplay first to get a PCM stream lel

https://libjxl.readthedocs.io/en/latest/api_metadata.html#_CPPv4N12JxlLayerInfo17save_as_referenceE says that `save_as_reference = 3` "should not be used by applications", but it seems to be reserved only for patches (`kPatchFrameReferenceId = 3`). Can I use `save_as_reference = 3` in case of disabled patches?

Oh, there is a tight check in `lib/jxl/encode.cc` for `save_as_reference >= 3`, but it seems to work fine without it

I'd assume no in case decoders tried to interpret it as a patch, but on the other hand if there are no patch references I suppose nothing would happen

Is this a convention thing or a spec rule?

I think conventional one, as each patch have its own reference frame (`ref`)

What is this bug report?

https://github.com/libjxl/libjxl/issues/3764

One that should be closed

I don’t get it

It doesn’t look filled in

Like they forgot to put the bug

That seems to be the case, yes

So it’s duplicate / spam then ?

Maybe the guy wonders why no one has replied to his bug report yet lol

don't you know that JPEG XL gives you telekenetic powers?

i thought that was common knowledge

The profile looks like a spam bot

i guess, that's the only thing they have done on that account

stack plot from `git-of-theseus` (https://github.com/erikbern/git-of-theseus) on libjxl

So, since every year trends smaller, eventually there will be no code at all?

The overall total amount of code has nearly doubled, but every year more old code is replaced by newer

this is for authors

but a lot of this is "jpegxl-bot" since initially we did the development on a private gitlab repo and the github repo got synced by a bot

these are the authors when I run it on that private gitlab repo (which was used in the first 2.5 years or so)

shouldn't syncing to another repo retain commit authorship information?

That can be done I guess, but back on gitlab the CI was configured so that the bot would always do the merging, and somehow that's the only thing that survived into the github repo

Alex Deymo is overrepresented in this gitlab plot since he did the initial PIK code dump commit

You can see how small FUIF was compared to PIK in lines of code 🙂

I guess it should be possible to reconstruct a git history that has both (and maybe even pik)

by reparenting the first github revision on the last gitlab one, or something along those lines

Seems like a researcher is trying to compress 10-bit video frames with JXL, but is having issues getting it to convert properly https://github.com/libjxl/libjxl/issues/3787

Wasn't there Y4M support at some point?

Just curious, why Eugene has two names 🙂

E. Upenik is not really a jxl contributor, but he was Touradj' PhD student when that gitlab repo was created and he was the one who created it 🙂

I dunno why <@811568887577444363> has his first name spelled in two different ways 🙂

I have an idea, but it depends on where he is from

I guess the massive drop is due to jpegli getting its own repo (and being removed from libjxl) ?

I think jpegli is more recent than the massive drop

also, I’m in the process of trying to rerun this on the entire history

although the pik part will be imperfect because that, in turn, was exported from internal code

e.g. https://github.com/google/pik/commit/6fa4a5b96131d5b251d588535452b1cfb377d8e3

and with a mailmap to have only one Eugene (and consolidate a few other people as well)

It's also not been removed from libjxl, just mirrored and then continued

``` Rebasing (60/2646) ```

there we go (but as I said, likely distorted by how we exported pik)

Wait, what parts of JXL came from FUIF/FLIF and Pik

Modular is from FUIF

VarDCT is a mixture of PIK and some bits from FUIF

<@794205442175402004> does that sound about right?

without authors

Yes, but that's just the origin, JXL has had ~2 years of new ideas/improvements added on top of the pik/fuif blend before we decided to freeze the bitstream.

I wonder how well this kind of analysis works when a commit is a big refactor that moves around a lot of code (so lots of lines added and removed if you look at the diff)...

yeah, probably not so well – it tries to use `git blame`’s line tracking but that’s easily tripped up

I can retry with `--ignore-whitespace`, maybe that will help somewhat

the difference is minor

It's a nice chart, really shows that it was a group effort and many people made substantial contributions. Jan, Lode and Deymo are no longer working on jxl but they did quite a lot in the early years and still a lot of their code is in there. Lines of code is of course not a perfect metric, but still, it's a nice diagram.

for a 5000x5000 image, and a 16 hyperthreads/cores CPU, how long can I expect `-e 11` to take ? I need to know an order of magnitude, like is it ~10 hours, ~3 days, ~1 week ?

just don't do it for anything that's not a tiny icon, it's a waste of energy in any scenario

yeah but i'm actually curious how much storage I would save <:KekDog:805390049033191445>

like 4 kB

at best

1 way to find out™️

Might try it on a 1080p background, but it'll take a while, because 9900K

https://tryitands.ee

-e 9 -q 100 -I 100 -E 3 -g 3 was 0.048MP/s

-e 10 -q 100 -I 100 -E 3 -g 3 was 0.016MP/s

I fear for how slow -e 11 will be XD

``JPEG XL encoder v0.11.0 960d97c [AVX2,SSE2]``

i feel bad for your pc

It has done 100% load encodes that took over a month <:KekDog:884736660376535040>

av1?

At this point I kinda want my 9900K to die, because then I have an excuse to buy a 9950X XD

Yup, cpu0 qpsweep 1

So basically slowest. qpsweep makes it I think about 3 times as slow with tiny benefits XD

And that was a while ago, so no doubt that I can get better results now with cpu1 without qpsweep which I guess will be 5 - 10 times faster <:KekDog:884736660376535040>

-e 11 -q 100 was 0.003MP/s

Why not threadripper 🤔

Because rip gaming performance™️

yay, you saved 25 kB

Build a dedicated encoding box with 128 core threadripper [LUL~3](https://cdn.discordapp.com/emojis/1246890433041137735.webp?size=128&quality=lossless&name=LUL%7E3)

Or even better, get your own server farm with thousands of cores <:KekDog:884736660376535040>

For that we'll then need -e 13 or more xd

Don't give the devs ideas <:RaysShock:686219918030798921>

im still adament about my "try every possible bitstream" idea to be added

Maybe in a hundred years when the hardware makes that possible

would be massively parallelizable

try every possible bitstreams simultaneously with quantum computing

quantum bogo-cjxl

destroy all universes with non-valid bitstreams

I tried to graph the correlation of Megapixels to seconds spent in effort 11 to estimate what large files would be like... Turns out I can't graph to save my life :P

Over the weekend my friend casually mentioned running a VM for me on 3 gigabit fibre so I can run JXL encoding on an old Google server haha

Letsgo 😂

none because you'll never finish encoding all your files

on *one* file

anyway, intuition says it should take less than 10 hours, but for some edge cases libjxl freaks out and take like 200x as long as expected

it should be photo-like to avoid that

The VarDCT itself is from Pik, but some of the control fields -- like which transform it is or what is the adaptive quantization level are then compressed by using FUIF-inspired (but re-engineered by Luca to be faster in decoding) decompression

except Pik only had 8x8

at least at the time of the initial JPEG XL competition

we only added variable sizes after the competition

I designed it (the decomposition to a uniform 8x8 field for previews but still having variable DCT sizes) and Luca did the actual implementation

here, design was easy and implementation difficult 😅

If pik did 8x8 dct what were the difference with jpeg?

XYB, adaptive quantization, better DCT coeff encoding (num_zeroes based, with flexible coeff reordering), ANS, CfL, Gaborish are some of the things I can think of

Pik seems pretty cool. Much cleaner more organized source tree compared to libjxl, but that's not saying much, since almost anything is...

And it's basically just lossy 8x8 DCT jxl, optimized for high fidelity, and probably super fast too.

I guess with such small headers, it's much easier to make a 'valid' file by random https://github.com/libjxl/libjxl/issues/3793

```JPEG XL image, 848302208x293, (possibly) lossless, 8-bit RGB num_color_channels: 3 num_extra_channels: 0 have_preview: 0 have_animation: 0 Intrinsic dimensions: 848302208x293 Orientation: 1 (Normal) Color space: XYB, D65, gamma(0.333333) transfer function, rendering intent: Perceptual layer: 136x9 at position (64,16) Decoder error```

250 Gigapixels, gee I wonder why it uses 4 GB of memory just to try and load

This is why it's nice to have convenient knobs for memory and response time for a codec library... 😅

width of 848302208 doesn't conform to Level 10 right? maybe libjxl is checking only frame dimensions

`1073741824` Max Width and `1099511627776` Max Pixels if I'm reading this right. So it's within spec by 203 million Width still

Even Level 5 allows for 258 Megapixel images

oh so it allows up to 1 terapixels

(in base 2)

Just like the advertising ~~barely~~

technically it should be able to go to 1 exapixel?

or is there a reason why not

(other than practical limitations)

Based on what?

then it's not like something libjxl can prevent, and we need some image dimension limit or something

1 Billion width * 1 Billion height?

width * height is limited to `1 << 40`

is that a level-based limit or a fundamental limit in the bitstream?

level 10 limit

im saying if someone made a 'level 20' or something

maybe a "web-safe" level 1 could be created specifically for browsers?

I remember something about encoding the earth with 1 metre resolution in 1.5 JXL files by bending the spec slightly, so that was probably it

disabling features that would not make any sense on the web?

level 5 is meant to be web-safe I think

not sure what web app would need / want 256k by 256k images

i guess other formats don't have arbitrary limitations

so it's probably fine

you can always make a 2 gigapixel png

Yeah, it is a bit of an odd case... On one hand doing nothing would mean annoying the people reporting it, on the other hand nothing is technically wrong. You requested 250 Gigapixels and it failed to decode :P

Oh... It's 6am... Maybe I should stop thinking about <:JXL:805850130203934781> for a while

hiya i keep getting an [error when trying to build](https://github.com/libjxl/libjxl/discussions/3807) on windows 11 with visual studio 2022 (something to do with the `RunRow` function?)

could anybody help? (tho imma sleep now hehe)

after researching a bit more, is building with msys easier? i barely have experience compiling stuff and it seems libjxl is one of the harder ones

oh nice! yeah i'm not compiling for development, just want to try out a new feature

awesome, i wanted to try out [309b637](https://github.com/libjxl/libjxl/commit/309b637d8a2a78708a2b806d9523ae0de562a997), and i've successfully piped imagemagick output into cjpegli

the only caveat being that i have to use cmd

for some reason it doesn't work in powershell: ```powershell ❯ magick "cover (max).png" -colorspace RGB -distort resize 640 -colorspace sRGB -strip - | cjpegli - "cover.jpg" Failed to decode input image - ```

i might report this as a bug if there isn't anything obviously wrong i'm doing

If it works in one shell and not the other then it's probably not a bug

I find building with msys to be easier

The build system for libjxl is kinda stiff and obtuse in my experience.