Idea: libjxl in the Linux kernel

[ctrlcctrlv]

Btrfs has a compression feature—on my system it saves me (using zstd at level 3) ≈15GB on a 50GB root / partition.

I was thinking, why couldn't JPEG XL be used in the Linux kernel in much the same way, for JPEG and PNG images? It's fully transparent for both.

[malaterre]

Are you talking about v4l2 ?

[ctrlcctrlv]

Nope, I am talking about intercepting reads of JPEG/PNG files and recoding, and doing the same thing at write time, actually using JXL for the on-disk representation.

[malaterre]

You do not want to use fuse+libjxl ?

[ctrlcctrlv]

No, I want it to take effect on existing btrfs partitions.

[jonnyawsom3]

Jpegs it could make sense, since the transcode is almost instant, PNGs could significantly slow down reads/writes depending on the effort setting and the PNG compression too

[malaterre]

@mo271 this is not a possible enhancement. libjxl is currently written in c++, no way this will ever make into the linux/kernel in the near future IMHO. Fuse is the only mid-term solution AFAIK.

[mo271]

@mo271 this is not a possible enhancement. libjxl is currently written in c++, no way this will ever make into the linux/kernel in the near future IMHO. Fuse is the only mid-term solution AFAIK.

I agree

[ctrlcctrlv]

perhaps not the mainline linux kernel :-)

but DKMS exists… it's just an idea.

[190n]

BTW, I've been working on the fuse version of this idea. I don't have enough to share yet but it seems definitely doable if I can muster the effort to write all the glue code. It also might not ever meet particular standards for production-readiness, but I'm hoping to use it for my own photo library at least.

[190n]

why couldn't JPEG XL be used in the Linux kernel in much the same way, for JPEG and PNG images? It's fully transparent for both.

It wouldn't be transparent for PNG since when you convert JXL to PNG, the resulting PNG might not be compressed in exactly the same way. I also don't know whether JXL can exactly represent all the metadata in a PNG file. You'll get the same pixels, but not the same bytes, which I imagine might mess with some applications.

[ctrlcctrlv]

jxl can represent all png data

also, yes it can be done. jxl can intercept both reads and writes. it would need to know which PNG files it has control over, and then would lie to user applications showing a png. when a png is asked to be read.

this is only likely to screw with very esoteric software for writing png's, which is not what i care about for my use which would be on a server where i could test all the graphics processing software; file caps could also be used to say "never JXL this PNG".

[ctrlcctrlv]

another possibility to lower the chance of anything going wrong is to immediately unmark the file as JXL'able if the caller seeks at any point during the write.

[jonsneyers]

JXL can represent all PNG pixel data, but not all PNG bitstream data. So you can make a jxl file with the exact same pixel information, but that doesn't mean you can reconstruct the exact same png file — for that, you would also need to record how the data is represented in the PNG (e.g. indexed or full-color, one IDAT chunk or several, choice of filters, matching choices in DEFLATE, etc). It can be done, but the amount of additional information would get quite large since PNG/DEFLATE does leave quite some degrees of freedom in the entropy coding (this is why something like zopflipng is so slow). The overall compression gains would suffer if you'd try to do png recompression with bitstream reconstruction.

For JPEG it is different: JXL can represent both the pixel data and the bitstream data. It is still effective because the extra bitstream reconstruction data is quite small — JPEG entropy coding doesn't have many degrees of freedom (just the huffman tables and that's it).

Having filesystem-level support for jxl is an interesting idea, but I think the better approach is to just make all applications support jxl, and then stop using the older formats :)
What linux software does not yet support jxl at this point, and would benefit from filesystem-level jxl recompression?

[sandstrom]

Is it useful to keep this open. Seems like an issue that is likely to get tracking (I don't think the kernel has any image support built in, so why would they make an exception here?).

By closing some old issues we reduce the list of open issues to a more manageable set.