JPEG XL

how old are we talking here?

I did a similar generation loss experiment with PNG, it did very well preserving the details as well as smooth gradients, even after 1000 generations

Very impressive and resilient format

PPM -> PNG -> PPM even round trips!

uhhh, IBM was still a thing old

I dont have exact specs on hand as I need to wire them up to a power source

I know one is a sandybridge and one is a ivy bridge tho

Gaborish is a 3x3 uniform smoothing at decode time which gets compensated by a 5x5 uniform sharpening at encode time. EPF is decode time only (not compensated at encode time) and is like a bilateral filter, not smoothing edges away. It is also not uniform but the strength is locally signaled. It can reach a 9x9 region around each pixel (but it's not a simple convolution like gaborish).

I feel like there are better ways of deblocking ||but they might be patent encumbered 💀||

I seriously wonder how much slower a 7x7 sharpening would be 😄 (or for that matter, whether our 5x5 sharpening is truly the correct inverse)

jxr has filters that are losslessly reversible

Not sure why though

Ideally encoder gaborish is only the true inverse as distance goes to zero, and does slightly more sharpening than just the inverse as distance goes higher, to compensate for the slight blurring caused by HF DCT quantization.

Yes, that would be even better, interpolating between sharper and true inverse as distance goes to 0

I think it was mentioned a long time ago, but having options interpolate with distance rather than hard cutoffs or being strictly enabled/disabled could help a lot. Similar thing with image resolution and encode effort/group size, ect

hf DCT quantization doesn't necessarily cause blurring though, right? It could also cause sharpness or noise

Depends on the rounding, but generally you have a large bucket around zero so a bit more blurring than noise/sharpening. But yeah, if you round heavily towards zero it's blurrier than if you round in a more balanced way

Could you emphasise sharpening and noise by rounding away from zero?

I feel like there could be some potential psychovisual optimization there

There definitely is. It's the basis for psycho rdo like in x264

Basically the theory is you avoid all the nasty blurring-smearing by using a more rough/course DCT quantization that tries to preserve more of the spectral energy, especially in the higher-frequency bins, rather than "rounding to zero" which results in a fugly smudge.

You end up with more sharpness, grain, and potentially unwanted noise, but at least it looks better and preserves more visual information than a blur or a smear that destroys the visual information behind it.

It's great for natural images but maybe not for synthetic flat high-contrast images.

Well, closer to "compute intensive" 🙂

with jxl is the quantisation weights defined per-frame? per-image? per-group? per-varblock?

per-frame quant matrices, and per-varblock quant strength (`HfMul`)

Is the quant strength a scalar that multiplies each value in the var block’s decoded coefficients

Like does a higher value = lower precision ?

higher value = higher precision it seems

whats the equation?

Section I.5.3: `Mul = (1 << 16) / (quantizer.global_scale * HfMul)`

i hope blender gets support for JPEG XL

it gets my image sequences down to 1/10th the size with microscopic changes

Someone actually already worked to add support... Then disappeared almost immediately after, twice https://projects.blender.org/blender/blender/pulls/118989 https://projects.blender.org/blender/blender/pulls/119257

And it hasn’t been merged?

Why?

That sucks

It wasn't finished, and marked as a draft

It can only merge on a major revision, due to requiring libjxl. So it's essentially forced to wait for both a propper maintainer and the next release cycle in a few months

Think there’s a way to get some attention towards it from the blender devs or no? I hope it gets into 4.4 but it probably won’t

They won't work on it themselves, someone else needs to do the work. It shouldn't be hard, since that PR already has the base made, and it's 'just' enabling JXL in the image library, then adding the option to the menus

tbh if JXL gets added to Blender it should really have an option to export with a depth channel

Well, it would likely use a lot of the hooks for EXR encoding, if I'm right it has all the same features, at least that Blender uses

With the tests I did for RawTherapee, maybe I should see what jpegli could do for JPEGs in Blender too... Though they just use an image library so they probably can't use it.....

using an image library should make it easier

kimageformats already supports JXL

Blender uses OpenImageIO which already supports JXL.

Yeah, like I said, it's 'just' enabling libjxl during compile and plugging the settings menu in

I would not trust kimageformats for the degree of quality necessary for something like blender

https://openimageio.readthedocs.io/en/v3.0.1.0/builtinplugins.html#jpeg-xl

You what

So, the decode speed setting is so horribly broken, people think it's a second effort setting

isnt this supposed to be "faster_decode"

lmao

this can be reported here https://github.com/AcademySoftwareFoundation/OpenImageIO/issues and very much should be lol

if you don't report I will lel

I was reading trying to find if it was limited to ints or anything, but nope. Seems it does have full support, so just need to plumb it into Blender

oiio is generally a fairly reliable tool, I had been using it to convert out of range EXR to JXL and had no issues

I'll write up a quick issue

https://github.com/AcademySoftwareFoundation/OpenImageIO/issues/4584

Other than cjxl itself, there's not many places mentioning faster_decoding, so maybe Jon or another dev can leave a comment in the morning to confirm it

As shown in my benchmarks, faster decoding is either bugged or a footgun for Modular images. There *might* be a case to made for VarDCT but honestly I find the decode speeds fast enough already.

one would think that naming it `faster_decoding` should have been enough

it works for me 🤷‍♂️

I like it a lot, as the size increase is marginal but the decode boost can be significant

That's true, a 2% increase in file size is worth it if decoding speeds increase by 20%.

But for modular mode its better to just use effort 1 rather than faster decoding 3

At least according to my tests, I should post my results in <#803645746661425173>

I only tested for VDCT

For VDCT I agree, using fd is a worthwhile trade-off

tbf effort 1 is much newer 🙂

Makes sense

I still need to bisect to see if the faster decoding stuff is just a natural progression or if there was a regression, that being said, as long as it's fast and good it doesn't matter much, ill probably test chimera for image sequence again

Lossy or lossless?

lossy

i used it for ediitng videos

It should be fine, my benchmarks show that fd is worth using

I haven't noticed a difference in decode speed

I have a jxl file which is a reconstructed JPEG

named `foo.jxl`

if I run `djxl foo.jxl foo-1.png`

and I also run

`djxl foo.jxl foo.jpg; djpegli foo.jpg foo-2.png`

should I expect to get identical pixel data between `foo-1.png` and `foo-2.png`?

I ask because I'm not. I'm getting a PAE (using magick compare) of 23/255, which is fairly large

i.e. not roundoff

(strictly speaking it reports 5911/65535 but these are 8-bit PNGs so I scaled by 257)

both PNG files have an iCCP attached, which is the same profile, one embedded in the original jxl/jpeg

(the iCCP chunks have the same crc32 and length so I'm assuming they're actually the same profile)

I don't think you should expect that, no (I don't think djpegli and djxl interpret the 8x8 DCT the exact same way -- the DCT is the same, but they do different dequant tricks AFAIU)

The JXL will use CfL by default. You can disable it and might get closer results, but the JXL is higher quality

is it?

the JXL spec includes a jpeg decoder stealthily built in, in the sense that jpeg -> jxl (losless) is fully specified, and jxl -> pixels is also fully specified so 18181-1 and 18181-2 contain a jpeg decoder that you can always leverage by using `cjxl -j 1 foo.jpg foo.jxl; djxl foo.jxl foo.png`

I was under the impression that djpegli was just, well, *this* decoder

so converting to JXL is higher quality? then why would I ever use djpegli instead of `cjxl + djxl`

You reminded me, I actually stumbled across this last night https://github.com/libjxl/libjxl/commit/538c77b59ca708a46e9a8045d6673108507e65e1

Suggesting at one point, they were identical

Differences aren't huge, but they do exist https://discord.com/channels/794206087879852103/804324493420920833/1301645879979282442

<@179701849576833024> since you're online... ffmpeg just got animated JXL encode support (via libjxl)

https://github.com/FFmpeg/FFmpeg/commit/f3c408264554211b7a4c729d5fe482d633bac01a

I merged it last night

``` ffmpeg -i video.mkv -c libjxl_anim -f image2pipe animated.jxl ```

https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/f3c408264554211b7a4c729d5fe482d633bac01a

I don't think it's higher quality than djpegli. Chroma from Luma introduces some small difference but I don't think there's reason to assume it will be towards 'better'. I am not sure where the other differences come from but I can imagine that the dequant or IDCT is not completely identical between libjxl and jpegli.

the patch is co-authored by Zsolt Vadász

I believe they are in this discord but I'm having a hard time finding their discord username

so if that's you plz lmk

yay 😄

What would happen if you don't specify -c libjxl_anim?

it'll automatically determine from filename and it'll try to encode it as still JXL images concatenated together

Does it do the same for GIF?

Are there any plans to further improve JXL decoding with FFmpeg? I noticed that using the -benchmark flag shows a significantly higher decode time than using djxl or jxl-oxide

Would there be any downside to defaulting to animated?

because single-image animations are legal but usually not what you want

e.g. if you use `ffmpeg -i input.png output.jxl`

Riight

codec choice happens before you know how many frames are in input

so you can't predicate it based on that

ngl, idk

long time no see bois

<:Poggers:805392625934663710>

Made a Reddit post announcing that, since no one else did yet https://redd.it/1htt3se

With a comment thanking you both for the commit

How would one explain rANS in simple mathematical terms? (simple being relative here)

suppose someone fully understands the concept of information entropy

explain to whom? 🙂

and fully understands stateless prefix coding (e.g. huffman)

there's a class at my uni for undergraduates that goes over these concepts

you prove things like Kraft's inequality, huffman's theorem, etc.

but it stops there. it doesn't have any discussion of Finite State Entropy

I'd probably try to explain "classic" arithmetic coding first, and then explain how rANS is similar-but-different

to *that* audience, how would you explain it? conceptually by preserving state you can achieve better results than something stateless

I personally find AC to be somewhat easier to explain *shrug* but I guess ANS without state renormalization is also fairly simple

Prefix coding requires at least one bit per symbol, and an integer number of bits for each symbol. That means that if you have 90% zeroes, you still have to use 1 bit for them which corresponds to 50%. AC/ANS overcome this limitation basically by not encoding one symbol at a time but by modifying state and flushing only when needed. That means that in case of encoding a symbol with 90% probability, the state will only require flushing rarely. In AC, the basic idea is that you divide the unit interval according to the symbol distribution, and then recursively subdivide each subinterval again in the same way. Then every sequence of symbols corresponds to a small interval. The bitstream signals a single number with enough precision to know which interval it is. The result is that more probable numbers will cause less of an interval reduction, so you need to signal fewer bits for those. In the edge case of two symbols with each probability 50% this boils down to the same thing as just signaling them using one bit per symbol, but if you e.g. have 0 with probability 90% then after writing 6 zeroes the interval is still only reduced to [0, 0.9^6=0.531...] meaning that if the bitstream starts with one 0 bit, it implies that at least the first 6 symbols will be zeroes.

To relate prefix codes with tANS (FSE), there is this fast Huffman decoder with buffer of fixed number of bits - just shifting the unused bits of the buffer, while tANS would additionally include fractional bits in this shift (modify newX). tANS is defined by symbol spread: assigning a symbol to each position in such buffer, spreading them is power-of-2 size blocks we would get such Huffman decoder (bottom right)

This is still fundamentally stateless though, isn't it?

I'm confused about the mathematics behind FSE. The concept makes sense, but how does the math behind it end up working?

looks like everybody has a different understanding ( https://encode.su/threads/2078-List-of-Asymmetric-Numeral-Systems-implementations ), here is the original:

Hello, I have a JPEG image which cjxl successfully converts to jxl, but which isn't viewable in Safari or Preview. Where's the best place to trouble shoot what's happening? I'm happy to upload the image.

If I use image magick, then it successfully creates a jxl - using `magick 19617.jpeg -define jxl:lossless=true 19617_mk.jxl`. For cjxl, I'm using version `cjxl v0.11.1 0.11.1 [NEON]` And magick reports it's version as `Version: ImageMagick 7.1.1-41 Q16-HDRI aarch64 22504` I'm on a Mac using MacOS 15.2

magick uses normal lossy/lossless encoding, while cjxl uses JPEG Transcoding, so it sounds like there's an issue with the JPEG itself that's causing the JXL to not load. Could you zip the JPEG and the cjxl JXL file then send them here?

Huh - If I use ImageMagick to convert the 'not working' jxl back into a jpeg, it seems to be visible again.

Doesn't `-define jxl:lossless=true` actually make it lossless?

Again, that's because it's not doing JPEG Transcoding, it'll just be making a new file instead

magick turns the jpeg into pixels, and then feeds that to the JXL encoder. cjxl reads the actual JPEG file itself, and reuses the data inside. The first *is* lossless, but you can't get the same JPEG back out and it'll usually be larger and worse quality if you turn it back into a JPEG. The cjxl and djxl way will give you exactly the same file as you first put in, down to the same bit

It's... Annoying, to say the least

Yeah, that's confusing. The way that option's defined `jxl:lossless=true` makes it feel like it's doing the transcoding thing.

Most stuff like Magick, FFMPEG and CDN stuff always turns things into pixels so the different encoders can always open it, but that means libjxl can't get the original data

cjxl flat out refuses or at least errors if it can't generate a **truly** lossless JPEG Transcode, so it's frustrating the others don't at least warn about it

A lot of pipelines work with pixels, not bitstreams, and it would be very nontrivial to change that. But yes, it would be nice if ImageMagick would add a special case that makes `convert foo.jpg foo.jxl` do the right thing.

<@350116203190157314> can you try opening this file in Safari/Preview?

Yep - works fine

Seems like the issue is the ICC profile then, since all I did was remove it

Though... Could you try this one too?

Doesn't work.

Okay, it is the ICC colorspace then. Wanted to make sure it wasn't just a dodgy cjxl version

So - what do I do? Can I detect weird ICC colorspace issues? I'm converting tb of images from jpeg -> jxl - do I need to remove the ICC profile prior to converting? Or is this something cjxl can fix?

Well... I think I found the problem https://photosauce.net/blog/post/making-a-minimal-srgb-icc-profile-part-1-trim-the-fat-abuse-the-spec

(Also - thanks for your help! )

That specific image is literally using an ICC from a blog about abusing the specification to make the smallest one possible xD

Haha. Any time I've had troubles converting to jxl, it's because of icc profiles.

Interesting thing is, in that blog they mention MacOS specific data that they skipped. So I wonder if that's why it fails for you but not for me on Windows

Right, so, ... I should strip the ICC if it's TinyRGB prior to conversion to JXL? Wait - why does the JPG work on Mac?

Personally, I'm unsure what you should do. The others here have better knowledge on color handling and ICC, so I'll let them give suggestions. Though, if you are converting TB of JPEGs, then I'm glad I cleared up the difference between Magick and cjxl JPEG decoders tend to be a lot more loose, with rules relaxed over the years or never enforced. JXL was made a lot more strict and accurate, so it's had to be relaxed a few times when 'valid' JPEGs on the web have been invalid as a JXL. This could be another instance of it, hard to tell without debugging MacOS itself

Even if they just gave a warning when the input is JPG and the output is JXL, saying "JPEG Transcoding Unsupported" would help a lot

<@350116203190157314> It might be worth making a [Github issue](https://github.com/libjxl/libjxl/issues/new?assignees=&labels=&projects=&template=bug_report.md&title=) if you have an account. Then it's logged and the devs can check if it's a libjxl issue or an Apple one before you start stripping data

Stripping it out with `exiftool -icc_profile= 19617.jpeg` makes it all work fine. What's confusing to me is that, MacOS can display the jpeg - cjxl converts it to a JXL which isn't viewable, but them Macgick converts it to a viewable JPEG.

It does happen that some things are less picky than others about invalid input. Generally viewers tend to still show corrupt jpegs (incomplete ones, bad ICC profiles, etc) while being more picky when decoding more recent formats.

Is it possible to detect and remove it from the jxl after it's. been transcoded to jpeg?

So, the Jpeg is viewable on the mac, cjxl -> jxl and the image is no longer viewable, djxl -> jpeg and the image is viewable again.

No, you would have to strip or replace the bad ICC profile before converting the jpeg to jxl.

Zero Loss Compress automatically tests each image to make sure it's reversible.

Haven't used it but it looks cool

Works for me on my iphone

Probably because new codec libraries are not designed to deal with malformed input as well as libpng/libjpeg/giflib

Nah in this case I think it's not related to the codec library but some difference in application-level logic where a jpeg with a bad profile is treated like "ok we will just assume it is sRGB then" while a modern format with a bad profile is treated like "it's bad, throw an error". The latter behavior is actually better imo since it gives more incentive to encoder implementations to do the right thing and not produce bad files, but the "let's be forgiving" behavior tends to happen over time because users complain when the bad file doesn't render while some other viewer does render it.

The same kind of logic has led to browsers having to deal with very malformed html syntax to the point that specifications get written specifying how to deal with it, etc.

I see...

I love this guy. I hope this crazy bastard is on the jxl team.

https://photosauce.net/blog/post/making-a-minimal-srgb-icc-profile-part-3-choose-your-colors-carefully

You reminded me, I found a nice surprise at the bottom of this page https://glq.pages.dev/posts/high_quality_gifs/

https://github.com/saucecontrol/Compact-ICC-Profiles

This could be useful for libjxl

IIRC something similar is already being/has been worked on by Jon

This guy is a great writer

Really well written blog

https://github.com/libjxl/libjxl/pull/3446

Oh, actually, <@350116203190157314> I wonder if that would've fixed the ICC in that image

[happy NY!] ^ this is cool! Is there something that works in reverse? “Oh, I can see what you are doing, honey, and you, and you, you are all just sRGB, I will shrink you even further – turn you into a metadata flag!”

It kinda blows my mind that the color primaries are wrong in most srgb images

My first thought is this will complicate the process of automatically determining the intent and simplifying a color profile

I don't think the simplified icc profiles libjxl generates are similar to the ultra minified profiles from saucecontrol

It would be cool if some of his icc profile innovations could be incorporated into the icc profile generation code in libjxl, and then maybe a thank you could be added in the credits for his impressive and cc0-licensed work

<@718245888069468230> is that you? :o

They seem *similar*, but libjxl doesn't sacrifice accuracy and can compress the ICCs in JXLs too

His super tiny profiles don't sacrifice accuracy either. And of course the jxl file format allows the profile data to be compressed or omitted entirely

I was seeing the mini and magic versions

I wonder if it's possible to have a lossless non-xyb file using enum color space...

it is, either with a CICP PNG or with a PPM + `-x color_space=...`

why does the e9 use 10 times more memory for encoding than the e7 ?

What image resolution?

can confirm that iacobionut's gallery with A15 works fine

yay, now we have 2 usable galleries

still doesnt make jxl images show up by themselves

on A14

does A15 recognize jxl as an image?

my file manager thinks they are images but it still doesnt show in the gallery

yup, you still need a gallery app that supports jxl, LOS' gallery just gives me black 0x0 pictures

i have iacobionut's gallery but i didnt give it all files permission, maybe that way it shows?

it will show on A15 but not on A14. I already made an issue and it's an issue with how the gallery app queries files, apparently changing it would break API stuff that allows them to be on the google play store.

alright ill keep waiting for samsuck to figure out how to do A15 even though android made it easier to port than ever

10000x14000

For lossless images e10 disables chunked encoding which increases ram usage

Why do people use e10...

Should probably put it under "expert options"

And that should be renamed "idiot options"

Oops misread "10 times" as "e10", what are the settings used here?

Anything higher than e7 is really weird, has really bad multi-thread scaling, but usually has tighter compression somehow, but it's using a really inefficient algorithm with a lot of room for improvement.

lossy

just -d 1 -e 9 uses 9 gb ram -d 1 -e 7 uses ~1 gb ram 10000x14000

It's just a situation where the e7 is pretty good, but if you want to compress it harder, then just don't have the memory

I see, for lossy, chunked encoding is disabled at e9. If you are using 0.11, you can add `--streaming_input` if you are memory limited

well, for lossless there's a big jump in memory use at e8, though that was in an old version of libjxl that I tested

e8 lossless uses about twice the RAM when encoding vs e4 though 7

e1 uses a trivial amount though, which is one of the reasons I like it <:BlobYay:806132268186861619>

I should update both my lossy and lossless tests again

That was because of Patches

The biggest concern going from effort 7 to effort 8 is encoding times. RAM increases by 1.25x and encoding times increase around 3x.``` wintime -- cjxl smal.png smal.jxl -d 0 JPEG XL encoder v0.12.0 2368781 [AVX2,SSE2] Encoding [Modular, lossless, effort: 7] Compressed to 20893.3 kB (6.561 bpp). 4371 x 5828, 4.460 MP/s, 12 threads. PageFaultCount: 656378 PeakWorkingSetSize: 353.2 MiB QuotaPeakPagedPoolUsage: 33.11 KiB QuotaPeakNonPagedPoolUsage: 16.99 KiB PeakPagefileUsage: 395.1 MiB Wall time: 0 days, 00:00:06.120 (6.12 seconds) User time: 0 days, 00:00:01.750 (1.75 seconds) Kernel time: 0 days, 00:00:56.218 (56.22 seconds) wintime -- cjxl smal.png smal.jxl -d 0 -e 8 JPEG XL encoder v0.12.0 2368781 [AVX2,SSE2] Encoding [Modular, lossless, effort: 8] Compressed to 20832.3 kB (6.542 bpp). 4371 x 5828, 1.471 MP/s, 12 threads. PageFaultCount: 1522027 PeakWorkingSetSize: 441.6 MiB QuotaPeakPagedPoolUsage: 33.11 KiB QuotaPeakNonPagedPoolUsage: 25.62 KiB PeakPagefileUsage: 495 MiB Wall time: 0 days, 00:00:17.720 (17.72 seconds) User time: 0 days, 00:00:02.156 (2.16 seconds) Kernel time: 0 days, 00:02:55.218 (175.22 seconds) ```

Chunked encoding is turned off with patches. This causes a 11x increase in encoding time and a 4x increase in RAM relative to default effort 8.``` wintime -- cjxl smal.png smal.jxl -d 0 -e 8 --patches 1 JPEG XL encoder v0.12.0 2368781 [AVX2,SSE2] Encoding [Modular, lossless, effort: 8] Compressed to 20600.9 kB (6.470 bpp). 4371 x 5828, 0.126 MP/s, 12 threads. PageFaultCount: 80647359 PeakWorkingSetSize: 1.939 GiB QuotaPeakPagedPoolUsage: 33.11 KiB QuotaPeakNonPagedPoolUsage: 114.3 KiB PeakPagefileUsage: 1.95 GiB Wall time: 0 days, 00:03:23.320 (203.32 seconds) User time: 0 days, 00:00:20.125 (20.12 seconds) Kernel time: 0 days, 00:03:38.312 (218.31 seconds) ```

I hope patches can be made compatible with chunked encoding one day.

We should have a public jxl Wishlist to keep track of these things. 😅

I'm surprised it's only 25% more for you, though maybe memory use has improved in recent versions

If you mean major (minor) versions, patches is disabled until effort 10 (unless the image is under 2048) since the addition of chunked encoding in 0.10

The issue is it needs to reference the entire image to find matches. It could probably be done cheaper, but also much slower. LZ77 patch detection was one idea

Possibly only store the last 2-3 chunks to reference from?

Then if one patch is used often store it for the entire encode?

Groups maybe, chunks could mean it empty's the patch cache before it sees the next if it's a complex tile/sprite, ect

0.10.0 is the latest version I've tested, so that shouldn't be the issue

What resolution were you using?

4K UHD

Diff between group and chunk?

Chunk is just 'an amount of data' group is 128 to 1024 squares of pixels, as I understand it

So if the image is higher bitdepth, ect. The chunk has less pixel data

Sorry I meant groups then

I use chink,group,tile interchangeably

Streamed and chunked get confused often too

Can you clarify the difference between the two?

Streamed is reading the input file without buffering in memory, chunked is only submitting segments of data to the encoder at once PPM Input Full: 630 MB Streamed: 583 MB Chunked: 282 MB (Current Default) Streamed and Chunked: 236 MB PNG Input Full: 617 MB Streamed: 617 MB `Warning PPM/PGM streaming decoding failed, trying non-streaming mode.` Chunked: 267 MB (Current Default) Streamed and Chunked: 267 MB `Warning PPM/PGM streaming decoding failed, trying non-streaming mode.`

Currently there isn't a streaming PNG decoder, so only PPM works for that

Oh... Wait... `--disable_output` doesn't use `--streaming_output` and crashes when used

So PPM is actually Streamed: 561 MB Streamed and Chunked: 213 MB

``` /** Control what kind of buffering is used, when using chunked image frames. * -1 = default (let the encoder decide) * 0 = buffers everything, basically the same as non-streamed code path (mainly for testing) * 1 = buffers everything for images that are smaller than 2048 x 2048, and * uses streaming input and output for larger images * 2 = uses streaming input and output for all images that are larger than * one group, i.e. 256 x 256 pixels by default * 3 = currently same as 2 * * When using streaming input and output the encoder minimizes memory usage at * the cost of compression density. Also note that images produced with * streaming mode might not be progressively decodeable. */ JXL_ENC_FRAME_SETTING_BUFFERING = 34,``` Well, that's what the code says

and how exactly does this option work? are the 256x256 chunks encoded like scan from top to bottom?

Idk, but I would assume that is a safe guess

The chunks can be in absolutely any order at all

A middle-out spiral, centered on a point of interest is sometimes used. But most common is for the chunks to be ordered from top left, to right, to bottom.

In theory I think the order can be losslessly rearranged without changing the size of the file

jxltran time

Correct. Besides a few extra bytes for a funky TOC permutation.

Yes, completely foxlessly

Have a GUI tool that lets you re-order groups based on number. Then play an animation while your file downloads haha

Honestly a jxl progressive viewer app would be awesome

You mean a viewer that loads progressively, or a way to see the progressive scans/percentages to see what it looks like

For the second one, jxl-oxide has a progressive video mode, you have to enable it when building but it’s there

<@206628065147748352>

Yeah, I know. I can't build it though so I've just been truncating and saving PNGs instead

There is a website that lets you see any image loaded progressively

Google jxl saliency demo

that only allows you to progressively decode in browser and most browsers use libjxl which doesn't progressively decode as much as jxl-oxide

Yeah, no LQIP and poor control over the percentage

Still strange libjxl disabled that...

Maybe just to save cpu

I just realized that if cameras shot in JXL natively, they could do vignetting correction by putting the correction gradient in a Modular mode layer and blending it with the image

... I'm not sure what the benefits of this would be yet, apart from being able to get the uncorrected image back more easily

It might be worse? The encoder might see the darker peripherals and think it can get away with reducing the information there somewhat, and then the brightness is brought up again. Unless you can tell the encoder to apply blending before using heuristics like that

Cameras would presumably use a custom encoder so they could just make it work

Hmm you'd still have the problem that any compression artifacts are multiplied along with it I think

Don’t really think most people would need / want the uncorrected image when shooting in JPEG/JXL. if they wanted that control they would be shooting in RAW already

You could just increase the intensity target to increase the quality of the blacks, not to mention you'd already have higher bitdepth than a normal JPEG too

Though, you could do JXL RAW with a correction layer... Using the channel type Adobe completely ignored for bayer images

you mean this? `kCFA = JXL_CHANNEL_CFA, // Bayer channel`

What does it do?

Aren't bayer patterns just encoded by using one layer per photodiode like R,G,G,B

Oh is it just for identifying that a layer/channel is part of a bayer image?

> kCFA (for Bayer data, e.g. the second G), Ah, that explains it, it's just the one extra channel you need <https://redlib.nl/r/jpegxl/comments/rmo3ea/jpeg_xl_for_pbr_image_textures/>

Close, this is what I was thinking of https://discord.com/channels/794206087879852103/804324493420920833/1230846934596718622

Ah neat

So it'd be, RGavgBGdif to get 'an image' without wasting data on storing a preview

You know what, all lens corrections except distortion correction could be output to a channel and then you could easily disable/enable them in your editing workflow without having to rely on your software to apply those corrections itself (which it may do worse than the camera if your lens isn't in the database or something)

So basically JXL raw without needing to even be a special raw

Pretty much. Most of DNG is just metadata describing the camera, which JXL can also brotli compress the EXIF

I wonder how bayer sensor data can be efficiently compressed with jxl

If it even can be

Some bayer filters have 4 colors

2 different greens

What would be the most efficient way to represent all that data in lossless or near-lossless jxl I wonder

Is there a nearly lossless/reversible method to debayer and convert to xyb, even for bayer filters with 4 different colors?

I would just use a lossy debayered and otherwise processed image redundantly (just like the preview jpeg in DNG) and store the Bayer data as 4 CFA channels where Modular RCTs can help to e.g. subtract one G from the other.

That's what I was talking about with the Avg Green and Difference Green

Is there a (near-)reversible debayer algo?

It would be cool if the bayer sensor data could be mostly derived from the xyb image

you can always guess at what it would be based on the resulting image

I think it would be cool if there was a specified and reversible or near-lossless way of deriving bayer data from a multi channel image (with maybe 1 or 2 extra channels of reconstruction data)

So you could reliably reconstruct the original bayer sensor data while still storing it in a format that's ready to view, without wasting space on storing redundant information

Well this is what that would look like

And the normal DNG

You could probably achieve something similar but not quite as good using RCTs, as I understand. Bayer sensor data and final pixel color will be highly correlated even if advanced demosaicing is used, so I think just storing the residuals of some RCT operations referencing the final image and previous bayer filter channels should compress them fairly well

Like it's effectively just storing the R,G,B channels _again_ except you're storing just the differences between what the sensor data was and what it was interpolated to be during demosaicing

Though you'd need to be able to downscale the bayer channels since every bayer channel will be half the size. If that's not possible, you can do the reverse and use the free upscale op on the bayer data and encode the demosaiced image's channels as the residuals of it minus the bayer channels

Yeah, there's no technical reason why it can't be done afaict, the hard part is specifying it as a repeatable, reliable, reversible, reuseable standard for different types of bayer filters

But hacking up a quick and dirty proof of concept shouldn't be difficult at all

Then it just needs to get polished and generalized and homogenized and standardized

chromatic aberration correction is also spatial

that leaves only vignetting correction, I think? but that one is also rather easy to *un*do

Chromatic aberration correction isn't something where you can just blindly apply the same channel to any image taken with the same camera configuration, unlike vignetting correction, yeah. But it's still easy to compute it for that specific image, and put the residuals of the corrected vs uncorrected image into a channel

I think distortion correction would also work in theory but with particularly strong correction you basically lose *all* correlation around the closer you get to the edges, so at that point you're effectively storing like, two, or 1.5 images worth of data and it would not be worth it to use that approach

I mean that the residuals would be of the same nature as with geometric distortion

Ohh yeah you're right

This is the base image I took (with a pretty bad lens) and the diff between that base image and the CA-corrected one

(the second one is only really clear if you 'open in browser' and zoom in)

I opened a raw in Darktable and exported a png both with and without CA correction (not using lens data since that wasn't available, just its own guess at it from the CA correction module). And then added them as layers in gimp and subtracted the corrected one from the uncorrected one

That seems weirdly... Normal... I would've expected slight distortion around the edges at least, but only the sky has major difference as if it were compressed

Then again, I don't know much about *real* cameras

There's definitely a border around the branches against the bright sky, but I can't really explain why CA correction did something to the sky itself

lateral (a.k.a. transverse) chromatic aberration (3 in https://en.wikipedia.org/wiki/File:Comparison_axial_lateral_chromatic_aberration.svg), i.e. the correctable kind, is due to different wavelengths landing on the sensor at different distances from the center

correcting that involves rescaling them

I wonder what spline encoding could do with this image...

(2 = “axial” or “longitudinal” chromatic aberration and is much more annoying/tricky to fix https://www.lenstip.com/526.5-Lens_review-Canon_EF_85_mm_f_1.4L_IS_USM_Chromatic_and_spherical_aberration.html)

Ahh that makes sense, I never thought about it that way. So that type of CA correction is effectively kind of like doing geometric distortion correction on specific wavelengths?

So they all line up

Also, here's the diff of vignetting correction - though I assume vignetting correction is multiplicative and this is was a subtract operation, so that's probably why you see any resemblance of the original image at all. None of the layer blend modes gave me something that looked like what I would have expected, but this one gives you an idea

It'd be nice to have some hand-coded JXL files again. One demoing Splines, one Patches (but more thorough like Monad's build), Delta Palette, 'Modular bit-packing' (Described in theory by Jon). I suppose I'm just re-creating the conformance test files, but real images and examples of the features instead of exclusively that function

What's modular bit-packing?

(I say that with the assumption that things already aren't byte aligned and thus it probably means something specific)

You know how PNG can do 4, 2 and 1 bit images, putting 2, 4 or 8 pixels into 1 byte? (Or something like that) Currently JPEG XL can't do that, but Jon mentioned an idea to do something similar using modular mode

So like encoding 8 1bit pixels as 1 8bit pixel?

I remember seeing somewhere using a string of Squeeze+Palette could achieve that effect

that sounds so cursed

but fun

<https://github.com/libjxl/libjxl/issues/3775#issuecomment-2317324336> > The trick here was to apply one squeeze step followed by a palette step, which has the effect of turning the 1-bit image into a 2-bit image of half the size. This image compresses better since the MA tree gets a larger effective local neighborhood for context, etc.

Huh... That gives me an idea. Currently Squeeze is enabled with `-R 1`, so what if we allowed the number to control the amount of Squeeze steps

https://discord.com/channels/794206087879852103/794206170445119489/1084937919220957244 Intruiging. Yet more secrets of the format <https://www.reddit.com/r/jpegxl/comments/11p0edq/comment/jc3mdot/> > I don't think bit packing is still as useful as it used to be except for niche use cases like pixel art that intentionally uses low color count. In general people generally don't do things like scanning documents as a 1-bit black and white image anymore. > > But theoretically jxl can still kind of do it: you can apply a combination of Squeeze and Palette transforms in order to achieve something similar (but not quite identical) to bit packing. One interesting thing is that it's not limited to packing 2x1 4-bit, 4x1 2-bit or 8x1 1-bit pixels per byte like in PNG, but you could also e.g. do 2x2 3-bit pixels using ~12-bit palette indices applied to 4 channels of squeeze residuals, and other funky things like that. Currently totally unexplored in libjxl, but the modular nature of jxl's modular mode would allow this kind of thing. > > Another funky way of effectively doing bit packing is by using e.g. a redundant (2n+1)-color palette for a 1-bit image to represent n pixels at a time, where index i always corresponds to pixel value i%2. The first 2n indices are the ones used for the first value of a group of n pixels, and this value completely determines the remaining n-1 pixels through the MA tree (technically the remaining n-1 pixels end up in a context with a singleton distribution so they get entropy coded down to nothing). Again, this can be made to work for non-horizontal bit packing and for non-power-of-two packings (e.g. packing 3x3 1-bit pixels in a single 9-bit symbol).

Also the ability for palette to be arbitrarily ordered opens up some opportunities for learned palette ordering allowing for stronger correlation and better ma trees

I believe it is about demosaic process. Moving planes changes data fed to debayer algorithm

Yeah that makes sense. I assumed how Darktable did it was by trying to detect fringing and just correcting for it by changing the color values in those specific areas, but if it's morphing the planes then you would expect some amount of difference everywhere when subtracting it from the original

isn’t debayering done first?

I can't provide proofs, but I believe no

ah, in fact the DNG specification says you’d use the distortion correction opcode to correct chromatic aberration https://helpx.adobe.com/content/dam/help/en/photoshop/pdf/DNG_Spec_1_7_1_0.pdf#page=106 > This opcode can be used to correct lateral (transverse) chromatic aberration by specifying the appropriate coefficients for each image plane separately.

I'm assuming that's not what happened in my case, it was Canon's CR3 format and for that Darktable seems to rely the lensfun database for lens correction, and it didn't have any CA data so I had to use the built-in module to correct CA without any correction information

> This also allows processing steps to be specified, such as lens corrections, which ideally should be performed on the image data after it has been demosaiced, while still retaining the advantages of a raw mosaic data format.

oh, I think that module does work the way you described (desaturating edges)

That is neat though. I wish cameras would just shoot in DNG already

the warping approach is the one taken by the lens correction module (the one that uses lensfun)

oh, wait, there are _two_ other modules than the lens correction one

[non-raw](https://docs.darktable.org/usermanual/development/en/module-reference/processing-modules/chromatic-aberrations/) and [raw](https://docs.darktable.org/usermanual/development/en/module-reference/processing-modules/raw-chromatic-aberrations/)

I used this one

As you can see the 'real' lens correction module is only able to do distortion and vignetting correction, it has no data for anything else

Both the raw and non-raw variants seem to shift the image a bit

I thought about developing a raw to a lossless and lossy jxl, and then subtracting them in GIMP, to see where in the lossy image the most detail is lost. But since pixel difference isn't necessarily representative of visually noticeable differences, that got me thinking: would it be useful if SSIMULACRA 2 or a similar tools could effectively output a heatmap of the quality over the image? I've thought about this and I think if encoders are tuned for these metrics you should expect a pretty homogeneous heat map after lossy encoding. If it isn't homogeneous, then that's an indicator the coder is making incorrect decisions (as judged by the quality metric) which result in it dropping visual quality in different amounts across the image

I feel like that could be a pretty useful tool?

This is the first time I've looked into how it works but it seems like SSIMULACRA 2 internally uses error maps, if that means maps over the image, it might be pretty easy to get it to output an error map instead of a weighted sum, or calculating the weighted sum over small blocks of pixels to create the heat map

I'm not sure if it's right that you should expect a homogeneous heat map, you can save a lot of data in a solid color plane and lose barely any quality, compared to a more detailed area of the image, but I think it might still be useful to see if you're getting equal degradation where you do expect there to be

That's actually what libjxl does internally. Benchmark_xl is broken for me, but I did have an old example I sent to a friend on Telegram

It's butteraugli based rather than Ssimulacra2 though

....I'm a fool

The standalone butteraugli executable has the heatmap as an argument

Here's what an image looks like after lossy JXL

Oh! Cool

Butteraugli can visualize the heat map already indeed

For ssimu2 I should add something like that, it's not hard but there's some artistic choices to be made in how to put the 3 error maps and various scales in a single visualization 🙂

Well, you don't necessarily have to. Could just output 3 error maps

So these heat maps are used internally in libjxl. Does that mean if some better quality metric came around, you could effectively swap butteraugli with that one to basically improve the encoder tuning for free?

Using the quality metric heatmap in the encoder itself is pretty clever, I thought there was a painstaking manual process of trying to match it - though I assume there's still a lot of manual tuning done

IIRC me and <@207980494892040194> thought about trying to swap butteraugli for Ssimulacra2, but it'd be a speed penalty and we wouldn't know where to start

If these quality metrics are expensive, I wonder if you could save a lot of encode time at the lower end of effort levels by switching from a perceptual quality metric to something super basic, like straight up pixel value difference weighted by brightness for how noticeable they are 🤔

Actually only for vardct e8+ there are iterations to optimize for a metric, and yes you could replace it with any metric afaiu

For e7 and lower, no metrics are computed, it is all heuristics that were tuned offline

Oh, interesting

Hi all, could anyone point me to a scientific explaination how JXL avoids generation loss? I know all [cool videos from Jon](https://www.youtube.com/results?search_query=generation+loss+jxl) with comparisons between different formats, but I still didn't get how it's that JXL's lossy compression with "the same or higher" quality always falls into the same... result

Unfortunately the whitepaper doesn't clarify that? I have found a mention [here](https://www.jpegxl.io/faq#generation-loss-resilience), but it's still mostly black magic to me. Any help will be appreciated, thanks!

This paragraph here is weirdly phrased (it almost reads like it's AI generated), but I think it's talking about lossless transcoding, which effectively losslessly recompresses the original JPEG into a JXL, reducing its file size, but retaining the exact same pixel data, and even allowing you to transform it back into the original JPEG file, bit-for-bit. It's a completely lossless operation and as such doesn't suffer from any generation loss at all. This is different from decoding a JXL's pixel data, and then lossy encoding it into a new JXL, and doing that many times over, which is what causes generation loss. I don't know what specifically makes it so resistant to this, so I can't answer that (someone else here probably can though)

A very simple way of putting it is, it doesn't do anything addative. Other formats usually blur or sharpen the image to make higher compression look good, with JXL that's (Gaborish) disabled at distance 0.5 and below (Quality 95~) since you're probably using it in a workflow like Krita, ect

Black magic voodoo

Alien technology from the future 👽

Next gen alien technology from the future

Is jpeg xl banned in China

The JXL format doesn't fundamentally avoid generation loss. It just so happens the old encoder demonstrated in those videos behaved in a resilient way. The current libjxl encoder doesn't maintain such claims, except in the mentioned case of JPEG transcoding which is cleverly a lossless transaction by default.

It will only become banned in China once JPEG XL becomes an official religion

J||ailing|| X||i the|| L||eader|| Oops

noooo

再见 😭

which website is this?

<@384009621519597581> thinking about the space image yet again... The exposure adjustment could probably just be done by requesting different nits from libjx right? Since it has color management built in and lossy is always float 32 anyway

https://viewdns.info/chinesefirewall/

just wondering who is running this Twitter account? https://x.com/JpegXl ||i refuse to call it X||

I do, have been neglecting it a bit lately tbh though

J𝕏L

or even 𝕁𝕏𝕃

Oh hmm, that would certainly simplify creating a viewer

it might be worth creating another account on BlueSky as well

𝕏 has been on shaky ground lately

IMO it's best to cross post as much as possible, JXL should be on twitter/x, bluesky, and the fediverse as well if it is not already

fediverse = mastodon and friends?

correct

I'm thinking about games with CRT filters, film gain or other overlay effects. I wonder if screenshots from games like these would compress better if they stored the filter(s) in a separate layer. I think it might not because you're storing one RGB and one RGBA image instead of just one RGB image, but I also think it might because predictors would probably work better on both of them separately (especially on the filter) compared to on the combined image

For example this CRT filter on Balatro would make it so most predictors that look up perform poorly, limiting which ones are useful, whereas separating that allows you to pick the best predictor for the base image, and then picking a 'west'-like predictor is going to be even more effective for the CRT filter

Then you could also store the tile of the filter, since it's usually if not always a repeating texture overlay

Oh yeah that'd make it even smaller

I'm considering buying balatro to see if I can extract the crt texture and then test this

But I don't know how I would even manually construct a JXL with the CRT filter and base image as separate layers

if it is possible to deactivate the filter in the game settings, you could export a jxl with the aforementioned specification using krita

probably

A friend of mine that has the game generously offered to look through the files and send me the CRT texture when they get home

Just gotta hope it's not a shader

If there's such a thing as running a second predictor on the residuals of the first predictor, it might be pretty easy to predict out the CRT in the first pass? First run 'west' to subtract out most of the CRT pattern and then use your other predictors of choice on whatever is left, but it's going to probably destroy some of the patterns of the base image, making them harder to predict

It's a shader :(

Can you send the file?

<@167354761270525953>

Thanks

WestWestWest

the balatro CRF effect seems blurry enough and simulated phosphor size is large enough that prob the regular predictors can cope with to a reasonable degree

we did some testing in <#803645746661425173>

exciting stuff for sure!

<sound:794206087879852103:1141847636865982554>

Short summary is that, like JPEG, it quantizes the higher-order coefficients to integers before entropy-encoding them. however if you decode and re-encode using the same settings you'll get pretty much those same integers back, so not much will be different. A better question is "why doesn't this happen with traditional JPEG" and that's more because traditional JPEG doesn't have specified decoding. theoretically with a well-engineered jpeg decoder and encoder you could avoid this as well. since the process of encoding a JPEG could be seen as an inverse problem (i.e. figure out what coefficients decoded to this image) rather than a forward problem (convert pixels to coefficients) but most JPEG encoders don't do that

Is there anything JXL could do to make use of the fact that pixel art is resampled such that 1 pixel in the image is actually 3x3 pixels?

https://discord.com/channels/794206087879852103/794206087879852106/1239238259784024117

If you turn the image back to 1:1, you can use the custom upsampling to do 2x, 4x or 8x scaling

Those were effort 11 too

This is about Noita in a convenient 'low resolution rendering' mode. It renders pixels that make up the world to 3x3 pixels and UI elements are commonly 2x2 pixels so that they can be a bit more detailed

So most of the the image can be downscaled as 3x3, but not everything

Another case of 'if only JXL were integrated to the rendering'

How would that work if one layer is scaled by a factor of two and another is scaled by a factor of three

Hold on

Okay never mind, the game just roughly fits pixels into 3x3 but not strictly always

Still does much better than PNG regardless :)

The game renders some pixels to 2x2 tiles, some to 3x3 and some to 4x4, which is interesting. It also seems the seam in that image above is the game's way of simulating sub-pixel movement by basically moving the pixels up and down along a 'scanline' grid

Anyway - Noita is a great game for benchmarking, with this low resolution rendering, high resolution rendering, optional pixel art anti-aliasing and dithering to avoid banding there's a lot of different things to test 👀

Sorry if that is a little of topic, but who made that? I've seen this style somewhere.

https://www.pixilart.com/art/habitat-sr28bef949d0baws3

Thank you 🦦

That's quite a useful website for benchmarking

what the go to software to download for convert? only found this https://github.com/JacobDev1/xl-converter/releases

libjxl

or just use imagemagick

libjxl seem to be CLI, i can't into that

oh, you wanted a GUI app? I know GIMP has support, and I think Affinity Photo does too, but that's commercial software (and I think it has more than a few bugs with JXL support)

If there is already libjxl installed, you can do bulk conversion with simply dragging to a .bat that contains the code of cjxl

I wrote some for cwebp and OxiPNG but I haven't tried libjxl on Windows

I've used this, it's pretty nice :)

I want to do some basic setting with a GUI than to suffer and be a pro CLI user

Both editing software though. I think irfanview is supporting jxl in a limited manner, so I might play with that if all else fail

How is it?

I'm not a pro at all

it works well

Just pitiful that winget doesn't include libjxl

though iirc it had some defaults I didn't like, consider checking the settings before you batch convert everything

For cwebp it looks like this `@echo off setlocal for %%f in (%*) do ( set "inputFile=%%~f" set "baseFileName=%%~nf" cwebp -lossless -m 6 -q 100 -mt -v -progress "%%~f" -o "%%~nf.webp" ) pause`

Thx boss

U finish converting or still considering

I don't understand

If you use KDE you can use service menus in dolphin to allow converting images via the context menu

A bit similar to Quick Action on macOS

Create "/home/USER/.local/share/kio/servicemenus/" ands put this file there

Yes

I have an example posted yesterday

It uses AppleScript this time

I would test it, but no MacOS xd

A window (or tab) will pop up like this

The codes are largely helped by ChatGPT with trial and error

I've tested running it for hundreds at the same time

nice

This is a universal method so other codecs can be used with that as well

pretty much the most accessible one (a gui that behind the scene uses libjxl). just make sure youre confortable with the parameters selected, afaik its set to *wipe existing metadata* out of the box (barely decreases filesizes but may mess management of curated image collections)

there's https://github.com/kampidh/jxl-batch-converter but its mostly libjxl wearing a differently colored ski mask. not as good, new versions can be swapped in, easier to mess if you fiddle without understanding the parameters, displays helpful logs

handles jpegli encoding (cjpegli) and decoding (djpegli) as well

Thanks boss

Sorry typo, was asking if u finished the move to jxl or still thinking

I'm stuck in the consideration phase at the moment. Not sure if it time to move yet. There seem there be quite good traction supporting it but there is also so many (format) Competition at the moment

I finished the move

I used lossless jpeg transcoding, so they take up 20% less space, and I can always get an exact copy of the original files out of them if I want in the future

JPEG XL is the only image format that can do lossless JPEG transcoding. That mode works basically like putting a document in a zip file: it becomes smaller but still contains the original file

So you don't lose any data, even if JXL completely flops, you can turn them all back into the original JPEGs

Yeah, i be going with this mode for sure

U read anything about "clashes"? Where anyone run into a bug where Lossless isn't reversible? For example (not a good one here) Similar to MD5 hash where two different files result in same hashsum

There are certain situations where lossless transcoding (currently) isn't possible or may fail, like I think if there's more than 4 MB of metadata attached to the image it won't do it. I'm not sure if XL Converter verifies that every file was 100% successfully transcoded, but I do know that for some images it doesn't work and it just ignores those and keeps them as JPEG Also, I would recommend making a backup of your original images before doing the conversion, or if that's not an option, testing it first on a few copies of the files you want to convert.

>more than 4 MB of metadata <:monkaMega:809252622900789269>

Imagine how many people you could kill based on *that much metadata*

i hid the government secrets in an Exif comment

is there a specific reason why 4 MB metadata is a limit?

probably because 2²² has some significance?

maybe the spec simply limits it because 4MB is already insanely huge and anything more is almost certainly in error

4MB metadata would probably be a just another file written into the metadata block

Most books aren't even 4MB

IIRC the methodology was: If something is appended that's more than 4MB, you probably want to be treating it differently than just storing it as metadata anyway