JPEG XL

I only see a real advantage of resampling around d20-22+ (pic). But not at all on d10+. I disagree with that.

From the messages nearby I didn't understand what quality was used there

That was distance 10 with current and my tweak with different scaling

The basis was this old discussion around beating AVIF https://discord.com/channels/794206087879852103/794206170445119489/1305592634462437396

I wanted to check the distance they used, and enable resampling then. At first I thought distance 15, but that render was at distance 14 so I moved the threshold down to distance 10 to try and cover it

Ideally photos could use resampling at distance 10, and non-photo at distance 20, since that's when it's better for both

It's been 3 years since I first reported the "color fading issue" here, and the bug is still here https://discord.com/channels/794206087879852103/794206087879852106/1038517128610992159 https://discord.com/channels/794206087879852103/804324493420920833/1050034155464970322

Yeah, still an issue https://discord.com/channels/794206087879852103/794206170445119489/1351548537980321852

I have a feeling it might be due to the aggressive quantization on the blue channel

Perhaps it's overtuned?

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

This is exactly what <@532010383041363969> is doing since I have already reported to him many times about problematic pictures, I have hundreds of them https://discord.com/channels/794206087879852103/794206170445119489/1209542475258269766 https://discord.com/channels/794206087879852103/794206170445119489/1209821088272490517 https://discord.com/channels/794206087879852103/794206170445119489/1209539745450033282 https://discord.com/channels/794206087879852103/794206170445119489/1209537689632641074 https://discord.com/channels/794206087879852103/794206170445119489/1107310666597007451 https://discord.com/channels/794206087879852103/794206170445119489/1107304236942884894 https://discord.com/channels/794206087879852103/804324493420920833/1084402230544838736 But I have a feeling that this is somehow connected with the fact that artifacts inside one VarDCT block are literally transferred to all nearby blocks, which in my opinion contradicts logic. But it happens and I have proven it many times. https://discord.com/channels/794206087879852103/794206170445119489/1074355637221347418 https://discord.com/channels/794206087879852103/794206170445119489/1074362924484788306 https://discord.com/channels/794206087879852103/794206170445119489/1074359203763855390 https://discord.com/channels/794206087879852103/848189884614705192/1069924982571933756 https://discord.com/channels/794206087879852103/794206170445119489/1074364288921260134 **None of these problems exist with -e 3 where the block is fixed 8x8**

It's funny because jyrki Said he did a lot of changes around 0.8 and 0.9 that fixes that issue

But all it did was cause an image quality regression 😅

Only in photos, maybe. But otherwise, no, I would even say that even WEBP q0 would be better than resampling on -d 20

It was overtuning to your difficult images that caused the quality regressions since 0.8

They actually fixed it... and then I came and showed that now this problem arose where it had not existed before...

Show me proof that it actually was fixed

I see the color issue in basically every version

I don't believe that you can seriously say out loud: well hmmmm, on -d 20 jpeg xl is better than avif <:kekw:808717074305122316>

https://cdn.discordapp.com/attachments/794206170445119489/1210507187320000553/jxl_animation.gif?ex=67dbd52b&is=67da83ab&hm=87c8c4bf15274d4bcd5c8ff72ea800f294f5ddfa36b9cbfc48748078419bd108&

it has been partially corrected for dark and red colors

Can you show me examples?

<@207980494892040194>you can use my https://cdn.discordapp.com/attachments/794206170445119489/1209510866115100722/merged_image_color_sort.png?ex=67dc29c6&is=67dad846&hm=c88b274ade4fc336686eb9ce46b91a832ca0db63e6494b029e7e532d0d807d7f& data set and do color channel inversion, contrast -100 and overlay by difference on different versions of jpeg xl

That's only 548,352,000 pixels each

moreover - I found this error in other codecs too. in my personal fork of SVT-av1 to fix color problems I do 32 iterations of CfL instead of 1. getting excellent colors, better than in any original AV1 encoder that exists. But for other codecs like HEVC or AVC there is a quality offset setting for the color channel. WEBP has the so-called "sharp YUV" which actually just increases the quality for the color channel. And jpeg xl... has nothing. I can't set the quality for each XYB channel!

Damn, really, for some reason I took the number of iterations and not pixels, and I did 6 iterations per pixel, my mistake

https://discord.com/channels/794206087879852103/806898911091753051/1351905948901441587

For modular, of course, all this looks infinitely funny

Not modular, VarDCT https://discord.com/channels/794206087879852103/794206170445119489/1345199325172731905

I hope I'll see it done someday

3 years have passed...

I am more confused by the fact that no one wants to switch from webp anywhere, at all, even Google, the same Google that first introduced Avif into Google search and YouTube, they completely stopped supporting AVIF in YouTube, it is no longer there, now only WEBP and Jpeg...

Is that the full image or a crop?

Just make jpeg xl decoded 100 times faster. come on <:Stonks:806137886726553651>

crop

I've been trying to encode this picture to jpeg xl for an hour now, although I've already checked that it looks much better in AVIF, and not much worse in WEBP

-d 8.5 --gaborish=0 --epf=0 --resampling=1 -e 6

is there tools for making pixel art from album covers?

I don't know... I've been doing similar things for 3 years now through neural networks (chatgpt and others), just asking them to write code in python using Pillow. It's a microscopic matter, the main thing is to understand what and how you need. https://discord.com/channels/794206087879852103/794206170445119489/1209485581881450517

<@238552565619359744>Including because of "sharp-yuv" webp looks even better in places than jpeg xl. Although this comparison is at the limit of webp q 1

Original cjxl 0.11.1 -d 16 -e 3 cjxl 0.7.0 -d 16 -e 3

color just die

It's strange, because I would've assumed quantization would mean less total colors, not less *of* the color

this is a macro effect, because of the tiny fading of colors on the border of each block, everything is very bad

AVIF has a similar problem (pic) but it's not nearly as strong... **webp** doesn't have this problem at all, even on q0

I'm surprised considering WebP's forced 4:2:0

And limited TV range

original | webp q 1

yes. the difference is about zero. if you compare it like that, then jpeg xl is extremely bad, and has had this problem for many, many years

What makes you say that exactly, btw?

the results I get

the main problem I have is it's applying noise on a per-pixel level, but if you look at actual grain (e.g. from negative scans or digital sensors) that's basically never the case

there will of course be some noise on a per-pixel level, but as pixels have to be grouped together for debayering and lenses aren't perfect, it will look different from what JXL does

You mean real noise is smaller than a pixel?

This looks like the same color problem mentioned recently, the one that strongly affects yellows, orange and reds.

The one where Jyrki said iirc that at low quality settings the scaling for the color quantization is too aggressive

Even at d=1 it's pretty bad

https://discord.com/channels/794206087879852103/794206170445119489/1351931487863181384

it seems libjxl is tuned within the d = 0.3-1.0 range

generally larger due to the bayer pattern

I spent a lot of time emulating film grain in blender which could demonstrate this better than just words, but that file is at home and I won't be back there until 2 weeks from now

A visual example would be nice, yeah

well remind me in two weeks <:YEP:808828808127971399>

I thought the jxl devs really agonized over grain synthesis.

TBH I think the grain synth in AV1 is much better, though of course quality depends on which encoder you're using, and there's no real option for doing it in the "proper" way yet (unless grav1synth magically started working)

Just forgot to add grain detection to the encoder

much of this was ensuring the absence of a low-frequency component

Well theoretically what's the difference between jxl's iso noise and "ideal" grain synth?

and then we retrofitted photon noise in whatever mechanism we had

(and also in libaom)

https://aomedia.googlesource.com/aom/+/refs/heads/main/examples/photon_noise_table.c

but this version also doesn’t really make use of AV1’s capacity for more advanced spatial correlations

also, the scaling of the ISO value is somehow different from libjxl’s (and I think libjxl’s is more likely to be wrong)

I have a command-line tool that can take a noisy image and its noiseless version and estimate the ISO parameter to pass, but one thing that made me hesitate to publish it is that the values it gives match libaom’s scaling, not libjxl’s

I wanted to fix that first

I see...

I wonder if there's anything I can help with. I like geeking out over jxl in my free time sometimes...

(to fix that by fixing the probably-wrong scaling in libjxl, not by making the tool also wrong)

https://github.com/libjxl/libjxl/blob/798512a9e83c5b36d4e6a097c11bf122d30c1b8f/lib/jxl/enc_photon_noise.cc#L85-L86

You can't be wrong if you delete all the evidence!

this would be an encoder-only change, i.e. new images would need to be encoded with a different `--photon_noise=` to produce the same results, but existing images would still decode to visually the same amount of noise since they already have the previous mapping baked into their LUT

which is part of why it didn’t feel so urgent to fix

but maybe it would still be good to do so before people get too used to using specific values

(another reason is that no functionality is actually lost – it’s enough to just scale the parameter to taste)

I think there needs to be distinction between grain and noise. AV1 is for grain, from old film or digital recreations of it. JXL is photon noise, from digital cameras and post process filters

I thought AV1 could do both grain and photon noise and possibly more, idk where I got that

you can do photon noise with AV1's grainsynth, aomenc added support a while ago iirc

https://aomedia.googlesource.com/aom/+/refs/heads/main/examples/photon_noise_table.c

more specifically, I did

(https://aomedia-review.googlesource.com/c/aom/+/145301)

https://cdn.discordapp.com/emojis/867794291652558888?size=64

there is an imposter among us

improving av1

<:CatBlobPolice:805388337862279198>

the default of cjxl should be to do lossless JPEG transcoding when given JPEGs as input

the only other option that matters I guess is `-e` since bumping it up does result in smaller final files

whats the conditions for a jpeg image converted to jxl to be recompressibke to jpeg without reencoding?

as long as it still has the reconstruction data I guess? I forgot what the box for that is called, i think it might be `jbrd`?

is that some cli tool i should use instead of cjxl?

uhh

wait what is it that you are asking for exactly?

if it's how to get back an original JPEG from a JPEG that was losslessly transcoded to a JXL then the answer is to use djxl. there might be some third party tools that support reconstructing JPEGs but for the most part a lot of software doesn't

yeah, just doing `cjxl`/`djxl` should get you the originals back (but maybe check before deleting them)

JPEGs are reconstructed to be bit identical, so yes the ICC profile will be retained

No, that's one of the very special features in Jpeg XL, all the data can be represented without loss, ensuring backwards compatibility

The original data is still there, the tiny difference you see is the because of how the data is interpreted. The original JPEG spec has some leeway in how to decode the image, resulting in different decoders having slightly different outputs. But if you use `djxl` you can recover the original jpeg, completely unchanged

Also, it's worth noting that libjxl's JPEG decoder is more accurate than the JPEG decoders used in other programs

TLDR; JPEG to JXL using `cjxl` is lossless and actually higher quality than the original thanks to an improved decoder, which `djxl` can reverse back to the original JPEG

I wouldnt call it higher quality, but rather more consistent

It does score higher though, both in metrics and visually

Most likely due to CFL and the higher precision decoding

best way to support jxl is to keep using it, and report to companies when it doesnt work, phone support forums are a great place for users to ask for support

For jpeg conversion, distance or quality are not necessary. It's a separate process from the lossy/lossless modes in libjxl which do require those settings.

The effort setting `-e` is meaningful but I would recommend sticking to the default of 7

If you have the spare time to leave your computer running, then higher efforts are fine.

But effort 7 is a good sweet-spot for speed and size

Also effort 9 is usually is smaller than effort 10

Don't ask me why, I'm still trying to figure it out

for jpg->jxl, efforts higher than e7 dont actually generate gains worth the massively longer duration for a half kilobyte. Can be worth considering if youre maximizing single or avatar-sized images but if youre doing a library conversion its the difference between finishing everything in an hour or spending 3 days to save an extra 12 megabytes total

Across ~99% of the images the community and I have tested, effort 9 is smaller

how long ago? cause I remember there was something slightly setup wrong in libjxl with effort 9 or 10

So yeah, pretty unanimous

ever since effort 10 was a thing, so like 0.10?

no I mean like where there any real recent tests done

I was testing the new jpeg recompression tweaks <@794205442175402004> has been working on two weeks ago. Across my smallish test set, effort 9 was consistently smaller than effort 10, both with the tweaks and without.

That's what I thought, but I didn't find any obvious bugs so far.

<@207980494892040194> I was asking cause I was thinking about this https://github.com/libjxl/libjxl/pull/3910 although after finding the page for it and looking it might not be so relevant as I thought it might have been although idk

Yeah, libjxl is the only lossless jpeg -> jxl encoder

That was for lossy, and I didn't find any other simple logic errors in the source code. So the issue is more complex unfortunately.

Cjxl is a part of libjxl, can you rephrase your question?

The transcoding to and from JXL is lossless. There is no *additional* data lost from the jpeg

Jpeg is lossy, so you would want to prevent more unnecessary loss for archival/future proofing

Limited internet speeds and hard drive space means that lossy compression is necessary and it always will be. In a perfect world everything would be lossless.

Lossy compression is really good for natural images from sensors.

True lossless only exists for synthetic images, and even then, sample values do get quantized which is also a kind of loss (especially when quantizing to 8-bit)

Sensors are not perfect, and even if they were, there is a sampling of photons which introduces sampling noise.

Which is why I think it's good if lossy compression is designed with editing/production and generation loss in mind from the beginning

Lossy formats that are designed to be high quality enough to be used in the production process

Like JXS

And theoretically JXL too if the encoder is tuned for that

"Raw JXL"

Like what Apple is doing

That change is due to the slight differences between JPEG XL decoding and JPEG decoding, as JXL decoding is well defined to specific limits where JPEG decoding is more loose. If you compare different JPEG decoders you will get slightly different images

I thought effort 10 was a joke setting

You were using `-e 10` and not `-E 10` right? The capital is a separate option And yes, the decoded image is different. It uses Chroma From Luma and 32bit precision instead of 8 to get higher quality results than the original file. It's subtle, but it is closer to the original

Ideally, I wish lossy codecs produced artifacts that were closer to natural sensor noise, rather than jarring artifacts that can completely add or subtract visual features

Sensor noise is easy to recognize and hard to mistake for part of the image.

Blocking/banding/blurring/smearing is more annoying and at the same time harder to separate from the image.

If lossy image codecs focused on being as close to natural sensor artifacts as possible it would be easier/safer to use lossy codecs in production and editing without worrying about amplifying artifacts as much, and "too much noise/grain" is a better and more honest and consistent signal of low-quality compared to typical artifacts like blur, color shift, banding and blocking...

It would be nice if lossy formats could completely replace the use of lossless for natural sensor data, but I don't think lossy formats are designed to be a good or acceptable replacement. They smooth and blur too much instead of preserving natural grit.

Or have obvious blocking or other artifacts

what is this? at the beginning of the file

Days without asking for high frequency image artifacts: 0

A very cheap way to do it would be increase ISO noise with distance, that'd get noisy :P

the problem RN is they're too high freq

or rather, they're not mixed with slightly lower freq

That would at least help to mask/hide all the blurring, so yeah

`--resampling 8 --photon_noise_iso 250000`

Even effort 6 is around 3-4% less efficient compared to 10.

As you can see, they almost overlap

No, it's a 100% reversible process and the exact same JPEG image data... but different JPEG decoders have different precision when decoding, and libjxl uses high precision floating point calculations throughout the process when decoding a file, so usually it looks slightly better when decoded by libjxl after being transformed into a JXL, than it would look like using an ordinary old JPEG decoder that uses lower precision calculations.

yes, decoding is when the image is converted from a compressed image into pixel values

They talk about lossless compression.

From JPEG to JPEG XL

Yes, that is a lossless process, as in you can do JPEG -> JXL -> JPEG

however JPEG -> JXL -> Output is different from JPEG -> JXL -> JPEG -> Output

So a lossless to lossy image won't look better with JXL obviously [kekw~5](https://cdn.discordapp.com/emojis/1167690816010059817.webp?size=128&name=kekw%7E5)

It would be magic

yes, qView most likely uses libjxl to decode JPEG XL files, where it would use something like libjpeg-turbo for JPEGs

The added photon noise might make it a bit harder to notice the other, more atrocious looking artifacts, and will also replace some of the high-frequency energy that was probably lost and smoothed over, so it would actually be a visual improvement... although it would be very lazy, to not also tune the quantization matrices for better psycho-visual characteristics and better RDO at the same time. You wouldn't need as much noise to mask artifacts if there was less artifacts to mask in the first place.

theoretically if you added something like jpegquantsmooth in the pipeline it may end up looking btter

but then that would negate the filesize reduction

The color desaturation problem still needs to be fixed, and the early-avif-esque smearing/vaseline artifacts... Adding a bit of extra noise can help make those problems slightly less obvious and noticeable and I would argue would still be better than nothing, but the root problem can be solved by smarter quantization.

If the encoder doesn't remove as much noise, then you don't need to add as much noise back in.

Currently the encoder removes a ton of noise but does not replace it, leaving images looking unnaturally smoothed and blurred, which is the worst situation.

what version of Windows are you on? if it's recent Windows 11 then you could use the Microsoft store addon: https://apps.microsoft.com/detail/9mzprth5c0tb OR you could use this which works with Windows 10 and 11: https://github.com/saschanaz/jxl-winthumb/

The encoder only needs to replace the same amount of noise it removed from the original. Currently the encoder does not attempt to measure how much noise it removed and does not automatically try to signal/replace it with the iso-noise feature

Ideally the encoder should compare the original with the lossy result and measure how much noise was actually lost after encoding. So it can signal exactly how much noise should be added back in.

It sounds so trivial when I put it that way, that I'm really surprised that's not the existing behavior

"No, it looks slightly better" So, yes....

<https://github.com/libjxl/libjxl/issues/1470#issuecomment-1156242387>

Pretty sure you have to restart the computer

And put the DLL somewhere safe, it can't be deleted after registering

libjxl uses a technique called chroma from luma which gives more color detail. If you don't like how it looks you can disable it in cjxl with this flag `--jpeg_reconstruction_cfl 0`.

Also using that very image you posted, effort 9 was smaller than effort 10.

```cjxl in.jpg out.jpg -e 9 25158 bytes cjxl in.jpg out.jpg -e 10 25182 bytes```

Different versions?

It's highly dependent on the type of image you are compressing. I don't know what kind of content is your folder, but in this case effort 10 is ever so slightly smaller. I usually compress photos and memes, so in all of my use cases effort 9 is smaller.

I mean it doesn't change the data, but it just interprets it slightly better...

Yeah, that's what we're saying

I was talking about the paper fundamental jpg you posted here, not the content in your folder. The benchmark numbers show that for that one jpg, effort 9 is smaller.

arch's openimageio doesn't have jxl support https://cdn.discordapp.com/emojis/720670067091570719?size=64

do we submit bug reports to jpegli repo or the libjxl repo?

I think the jpegli one as the libjxl repo is the legacy place for jpegli issues afaik

Issues *should* go to jpegli, but merges tend to be into libjxl and then pushed to the new repo

Something makes me doubt this is 3 bits per pixel

```jxlinfo -v IMG_20250101_172355-9.jxl box: type: "JXL " size: 12, contents size: 4 JPEG XL file format container (ISO/IEC 18181-2) box: type: "ftyp" size: 20, contents size: 12 box: type: "jxlp" size: 24, contents size: 16 JPEG XL image, 3960x2968, lossy, 1-bit RGB num_color_channels: 3 num_extra_channels: 0 have_preview: 0 have_animation: 0 Intrinsic dimensions: 3960x2968 Orientation: 1 (Normal) Color space: RGB, D65, Rec.2100 primaries, sRGB transfer function, rendering intent: Perceptual```

🤨

2.x BPP compressed, rounded up?

the fact that it's detected as "8 colors" is hilarious though

Realised it's because VarDCT is always float32, so bitdepth is quite literally 'just a number' and IrfanView doesn't request any values from libjxl other than '8bit sRGB'

`cjpegli` not able to accept JXL really pisses me off

Which version are you using? ``` Usage: cjpegli INPUT OUTPUT [OPTIONS...] INPUT the input can be JXL, [...] ```

It says that, but fails when I just tried

It works for me. cjpegli is part of the libjxl package on Arch for me

Either I am older than you, because not compiled from master, or newer than you, if you use the binary releases

Mine is from December, 2.14 MB

Mine is from a few days ago

Although I cannot really tell from when the source is, because cjpegli does not show version or commit. for me at least

5.21 MB now, so I guess static building was broken or it wasn't being included at all

I use the independent `jpegli` repo on macOS

jxl input works for me on arch

Does the jpegli fork even work?

How was that jxl file produced? It's not invalid to do this, but theoretically it means you are recommending to use 1bpc for the image, which is clearly not actually a good idea. Maybe for hi-res scans of bitonal images it could be a sensible header bitdepth, but not for photos...

1 bit RGB

Yep that's weird

Technically 3 bits, 1 per channel, so 8 unique colors

What's the average bpp for lossy images on the web? 1.5 bbp?

this meme still true?

AV2 (called AVM) does compress better (for now), but its super slow, if AV1 is a snail, then AV2 is like a tectonic plate.

av2? 🤨

oh yeah just looked it up damn nice

I'm assuming AV2 is going to be used in AVIF 2. Unless they want to have the avif container contain different codec payloads (which would be a nightmare to handle)

Either way it doesn't make sense to make new image formats every 5-8 years. Adoption is hell, even with Google's help ham-fisting WebP down our throats it took forever for it to become mainstream.

Image formats should not (and cannot) be replaced like a new iphone or car

You don't need any incompatible bitstream changes to improve on jxl

Maybe that sort of thing is slightly less pointless for video formats with motion estimation

But even then it doesn't make much sense because av1 is already so damn slow, it can't get much slower. There's diminishing returns

Anyways the jxl bitstream format already has plenty of "alien artifacts" and untapped expressiveness so the RDO isn't anywhere close to its potential right now

It's stupid to thoughtlessly pump out new formats rather than design formats very carefully and thoughtfully, and then build better encoders within those bounds of compatibility

Just set `-e 10 -E 4 -I 100 -g 3` by default and call it JPEG XL 2

Does JXL have intra block copy?

I think that's just called delta frames and yes, even gif has that

Intra block is when you take something near the top and use that as a prediction for somewhere below it

Sort of like patches but part of the core coding instead of as an after-decode feature

Patches can be used in that way

Doesn't sound like there's a difference

I had a 10bit camera RAW exported to 16bit PNG, so I tried --override_bitdepth 10, but it made no difference. So I tried lowering values down to 1 with no difference at any point

lol

It clearly works as intended though

What difference were you expecting?

It's lossy mode. So the output depth is only a recommendation

.

It reads the input file, converts it to DCT, then sets the "original bitdepth" to 10

What differences were you expecting to see though when setting the bits to 10

From 16 bit png

Converted from 10 bit raw

None, a slight density improvement like in lossless. Then lowering the tagged bitdepth to lower the output colors, but irfanview only goes down to 24bit for JXL

There is no guarantee that decoders follow the recommendation in the tag

av2 isn't out yet

Confirmed that `cjpegli` of libjxl Windows binary can process JXL to JPEG

In contrast to `cjpegli` of the standalone Jpegli repo

Why does the separate jpegli repo even exist still? Most of the code is shared code, so isn't it just confusing to keep track of which one is canon or up-to-date??

The Jpegli repo now looks somehow simplified actually

It's a fork

Almost all the code is shared code

2 versions of the same thing

That's not simplification.

Simplification would be moving some of the `lib/extras` files to the `tools` folder

Separating and simplifying the essential, library code

does the JPEG XL codestream orientation have the same meaning as the value in EXIF?

like do they translate 1-to-1

I could check the spec and check each one but I'm wondering if it matches up off the top of your head

Yes

It matches

In general we tried to match existing enums if it made sense

for my EXIF overhaul of ffmpeg what I'm planning on doing is, if EXIF orientation is present, setting the codestream orientation tag on encode to equal it, and then *removing* the tag from the EXIF block so that way there' no risk of a decoder conflict

being not present is by spec equal to default-1 but this way libjxl will just autorotate on decode

(also cicp values for primaries and tf match the jxl enum values)

the real reason this is important is if the linesize is negative in ffmpeg (which you can do in AVFrame, but not in libjxl) the current method of handling it is sending the image mirrored and setting the exif orientation to vertically mirrored

Negative linesize is how BMP and PFM work, right?

they're bottom-to-top yea

no idea about BMP

but PFM ye

but now that I have to take into account account an additional matrix, what I'm doing now is composing the two matrices and converting it back to an orientation flag. which still works, but I was wondering if I had to map an orientation -> orientation thing or if I can just use my utility function as-is

I suppose we could allow negative strides in libjxl too, it shouldn't really complicate the code much, right?

like suppose there's a negative linesize *and* the image is tagged as rotate-and-flip

it requires you to be very careful about the ABI change because `size_t` is your current linesize and it's unsigned

`ssize_t` is non-standard, and `ptrdiff_t` isn't guaranteed by C spec to equal `ssize_t` in size

there's some unusual configurations in which they aren't the same (generally not anything you'd see regularlly with clang or gcc) but it's a possible cause of issue

Oh we use size_t, not int? That's annoying

well you shouldn't use `int` anyway cause `size_t` can be larger (and often is)

size_t is better than int, in this regard

Yeah, I suppose int32 should be enough usually, but for an image near the max width, it might not be enough

Anyway I think the exif orientations are closed under composition so it will just be a headache-inducing exercise to make the composition table without errors 🙂

That's because the separate jpegli repo was haphazardly ripped out and depends on a lot of shared code with libjxl... since it's missing the jxl decoder code it makes sense that jxl input doesn't work properly. How long is it going to be in a separate repo for? :/

Ah whoops I was scrolled up too high

Is there an obvious way to tell if a JXL file was a JPEG transcode, Modular, or VarDCT encoded? Say I have a library with a mix of JPEGs, PNGs, and HEIFs and I convert them all with with their respective methods, how could I tell them apart without looking at them or naming them?

`jxlinfo` tells you that information

Lossy = VarDCT Possibly lossless = Modular Jpeg Reconstruction Data Available = Jpeg Transcode

Thanks this is helpful, I'll give it a try

At a deeper level, it checks `keep_original_profile` in the header. If it's true, it's probably lossless. If it's false, it's lossy. Then if there's a `jbrd` chunk, it can be reconstructed into a JPEG Pitfalls are lossy modular, which uses the original profile flag, and JPEG transcodes with reconstruction disabled, since there'll be no `jbrd`

but a JPEG transcode without reconstruction data is effectively just a JXL encoded with a low effort

Reconstruction and Transcoding are separate flags. You still get the size reduction without the reversibility

no i mean like it can be treated like a generic jxl file

Does anyone have an example of a JXL that has intensitytarget, minnits etc etc for ToneMapping? Trying to find an example to help debug my code...

ahhh never mind. Found https://github.com/libjxl/conformance/tree/master/testcases which is awesome 🙂

<@794205442175402004> a quick question, can Squeeze use different predictors per level? <@207980494892040194> figured out progressive lossless is so large because it's not using any, possibly due to only seeing the smallest level and basing decisions on the handful of pixels there. I wondered if it could get even better density by examining each level separately as opposed to using one predictor for all

Yes, Squeeze creates new channels per step so every level of residuals has its own channel id, which can be used in an MA tree to select different predictors/contexts per level. Lossy squeeze works by selecting different multipliers per level, which is basically the same as quantizing the residuals with a factor that depends on the level (high freq gets quantized more coarsely than low freq).

Since squeeze is using MA trees, can you use x and y selectors to do sort of adaptive quant for lossy squeeze?

By selecting different multipliers for different leaf nodes in the channel

Is there any theoretical reason why dct should be any better or faster than squeeze?

They both seem similar in a lot of ways. Squeeze seems conceptually even simpler.

Is it possible that Squeeze can be tailored to the Bayer pattern of a raw photo sensor for better compression?

Bayer shouldn't really be stored in a single plane, we already have the kCFA extra channel for the extra green

Unless... Can Squeeze synergize well with Bayer data?

I'm thinking maybe because of the way that Squeeze works it might accidentally separate the bayer channels anyways

Or it could be intentionally tailored to

I don't believe squeeze works well with channels that have high variance

like bayer data

the tendency function will fail to predict well in those scenarios

nvm, I was wrong,

The fact that the jpegxl.info uses png images is really misleading

not really too many other options as wasm decoders are kinda... rough.

Just use "This browser doesn't support jpeg xl" placeholders

what's wrong with https://github.com/niutech/jxl.js/

slow

like, uber slow

But it works. Is there a better alternative at this time? Other than getting Jim Bankowski's decision overturned somehow

a better alternative? yeah not using it lmao. failing that jxl-oxide's wasm support is better I found, performs marginally better while not almost crashing your browser on harder to render webpages

What is your alternative for serving images to non-safari users?

Just don't use jxl then?

I think it's good enough that people can start serving jxl regardless of browser, and thus put even more pressure on chrome team to reverse their childish decision.

yes, for now I simply wouldn't use jxl since it often is a fairly net negative experience. sometimes it can be better or even necessary which is why I did wasm stuff in the first place. but it doesn't suit all use cases

In a showcase about why you should use JPEG XL, having every demo say "JPEG XL not supported" may not be the best way to improve opinions

Yeah I think it's better to enable jxl with js fallback.

"It's slow" is not an issue. I don't notice any slowness even on old and embedded hardware.

People should start using jxl yesterday.

the files in the showcase should always have been downloadable. people need premade files they can try in galleries even if current browser doesnt display them

If everyone starts using it then browsers with good support will have better performance than browsers that need to use a fallback

It will give browser vendors more reason to quit dragging their feet and inventing asinine excuses

<@703028154431832094> Don't you have a website using a WASM jxl decoder? I remember you said it ran well enough.

I think the key here is, for comparison the images need to be lossless. So using the WASM on lossy JXLs might actually be faster than downloading the PNGs instead

The "web platform" (cringe) needs a standard way to re-use common shared libraries without downloading them over and over again for each site.

Like with blake hashes or whatever it takes.

Maybe browsers are already smart enough to hash js libraries and avoid redownloading identical files...

ipfs? afaik brave already supports that to some extent, but afaik between ipfs and regular web there's no reuse or caching

Yeah one of my pages I forget which

Is libjxl-rs functional?

Is it worth using it in a new project?

last i checked sure if you don't mind gpl

wasm has literally crashed my computer on Firefox from <@288069412857315328> 's jxl manga page

now, this is because Firefox is shit but even on chrome is slowed my PC to a crawl

it worked well on the jxl page with the csgo bench which iirc was the xyb page, it had to be disabled on the corupus page because it was crippling PCs

lmfao. well if a web page makes a browser crash then that's a browser fault.

Also image decoding should probably be deferred until the image comes into view...

if there's a really long web page with lots of images it should wait until you scroll before decoding...

sure but that doesnt detract from that fact that it is universally a bad experience

https://niutech.github.io/jxl.js/

This page works perfectly fine on any browser

Even on ancient hardware

Even on firefox

Do you notice any problem with it?

I don't

jxl is ready to use right now

It will be even better when browsers stop sleeping on it

its one page with three images on it

It's not finished yet, I recommend using jxl-oxide, it's a complete and fully functional decoder in rust.

Is the API the same?

this page https://giannirosato.com/blog/post/corpus-lossy/ is not so light

How many images does it take before it's a problem?

hard to say, I have a fork of this some where one sec

its been a while

It doesnt need to be perfect in all situations, it only needs to be good enough in most situations.

the rest will solve itself when firefox and chrome stop being stupid

but no progress will be made if people are afraid to use what we have right now

don't let perfect be the enemy of good

https://github.com/Quackdoc/gianni-rosato.github.io/commit/b7337cf216b07b46958f62ebd9aecb57031bb51a

I dont have the one with jxl-oxide which did perform much better

its old now but the jxl-wasm stuff for jxl-oxide is here https://github.com/Quackdoc/jxl-wasm

tirr's demo was not a drop in solution IIRC

I think no

When I scroll on a phone the images load and unload

But it doesn't work in firefox

My phone doesn't load any images

Works fine with Thorium on my phone

Oh, I thought this was about WASM decoding

You don't have an iPhone?

I guess that page doesn't have a JavaScript polyfill?

Works fine on my iPhone but not on firefox on my desktop

Is this accurate enough? https://chatgpt.com/share/67ea3217-be30-8009-a5f0-5a45a7a16767

I can't find many about JXL vs EXR

JXL supports 32-bit float

Random number generators tend to be inaccurate unless their output is tuned for a well-defined purpose.

ChatGPT is tuned to generate plausible-seeming randomness

> 8, 10, 12, 16 bits per channel Feels like it sourced that from the half finished Blender PR with the same options

That was a demo of compression artifacts and a crop of the original image, lossless wouldn't have any artifacts to show

ChatGPT users: lol JPEG XL sucks as it lacks deep color features and is not precise enough!

~~AVIF~~ OpenEXR looks better

How do people convert ProRAW DNG to JXL while maintaining the same colour depth all the time?

No. About 1/3rd of the information is wrong or misleading.

that is very generous lol

All my homies use <:JXL:805850130203934781>

finally Mjxl.avi

any tips on installing jxl on a really simple board that doesn't even have apt install?

or any package manager

a good step would be to take a look at what other package managers are doing

Yeah, just download the static binaries from github? they work good.

aren't those only for windows?

No? There are linux binaries too

Bonus: Answers from Gemini and Grok https://g.co/gemini/share/422b7119438c https://x.com/i/grok/share/QHt46KxSMHLsDfZQ1QEunhv1b

what is with these and HDR?

that being said the gemini one isnt bad

grok isnt as offensive as the other one, but its not super great

Gemini provides the least details so being more accurate

DeepSeek-R1 **Comprehensive Comparison of JPEG XL and OpenEXR** 1. **Primary Use Cases:** - **OpenEXR:** Dominates in professional environments like VFX, animation, and film production. Excels in high dynamic range (HDR) imaging, storing layered/composited data, and handling deep data for complex scenes (e.g., volumetric effects). - **JPEG XL:** Targets general-purpose use, including web images, photography, and archival storage. Balances high-quality lossy and lossless compression, suitable for HDR photography and efficient web delivery. 2. **Compression & File Size:** - **OpenEXR:** Offers both lossless (e.g., ZIP, PIZ) and lossy (e.g., DWAA/B) compression. Prioritizes preserving detail over file size, leading to larger files. - **JPEG XL:** Advanced lossy (VarDCT) and lossless (Modular) compression. Achieves smaller file sizes with minimal quality loss, ideal for bandwidth-constrained applications. 3. **Bit Depth & HDR Support:** - **OpenEXR:** Uses 16/32-bit floating-point per channel, essential for precise HDR workflows (e.g., avoiding clipping in extreme brightness). - **JPEG XL:** Supports up to 32-bit integer HDR, sufficient for most HDR photography but lacks floating-point precision, making it less suited for VFX compositing. 4. **Features & Metadata:** - **OpenEXR:** Rich features include layers, multipart files, deep data (per-pixel depth), and arbitrary metadata. Critical for frame-by-frame compositing and VFX pipelines. - **JPEG XL:** Supports animation, transparency, and basic metadata. Lacks deep data/layers, focusing on simplicity and broad compatibility. 5. **Adoption & Compatibility:** - **OpenEXR:** Industry standard in film/VFX, supported by tools like Blender, Maya, and Nuke. Limited browser/consumer software support. - **JPEG XL:** Growing adoption in web/consumer applications (e.g., browsers, image tools). Not yet mainstream in professional VFX.

6. **Performance:** - **OpenEXR:** Slower encode/decode due to high bit depth and complex compression. Optimized for accuracy, not speed. - **JPEG XL:** Designed for efficient streaming/decoding, faster performance in web contexts. 7. **Licensing:** - **OpenEXR:** Open-source (BSD-3), widely adopted in commercial software. - **JPEG XL:** Royalty-free, encouraging broad ecosystem adoption. **When to Use Each:** - **Choose OpenEXR** for VFX, film, or HDR workflows requiring floating-point precision, layers, or deep data. - **Choose JPEG XL** for web, photography, or archiving where smaller file sizes, HDR support, and broad compatibility are priorities. **Overlap:** JPEG XL may replace OpenEXR in non-critical HDR scenarios (e.g., consumer photography) where file size matters. However, OpenEXR remains irreplaceable in precision-demanding professional workflows.

what is the openexr licensing? royalty free is only part of it

Modified BSD License

> JPEG XL: Supports up to 32-bit integer HDR, sufficient for most HDR photography but lacks floating-point precision, making it less suited for VFX compositing. Really?

> JPEG XL: Supports animation, transparency, and basic metadata. Lacks deep data/layers, focusing on simplicity and broad compatibility. 🤨

> OpenEXR: Industry standard in film/VFX, supported by tools like Blender, Maya, and Nuke. Limited browser/consumer software support. Is there any browser supporting OpenEXR???

Give me anything that OpenEXR can do but JPEG XL can't do

Bizarre that it says jxl is for integer sample data

I don't think there is anything. Feature parity with EXR was intended when we designed jxl, iirc.

Why are we asking random number generators to tell us things again?

wb itd be interesting if you made comparisons like this but with real information

I guess nobody has done it so LLM can't really answer with correct information

maybe Gemini’s “Deep Research” would handle that better, let me try

here is its research plan

> My initial understanding is that they likely serve different primary purposes, given their distinct names. flawless reasoning

here is its final report https://docs.google.com/document/d/e/2PACX-1vQlB8KzjFhcW2JbjHfA5Pt4sUQ_T9B4Ew1Un3S0skIG_1hS80MDCcHwRUkC20JrWarbWR8AbfO0yiro/pub

it seems to be more words and tangents for ultimately the same conclusion

ooh, it considers jxl an “emerging” industry standard 😎

maybe I should ask it to write a report making the case for JXL in Chrome

They keep saying JPEG XL for web and general usages, and OpenEXR for professional usages

Good luck with that

this actually looks quite reasonable

> Despite Chrome's initial assessment of limited ecosystem interest, the support for JPEG XL has been steadily growing. Apple's integration into Safari, alongside backing from Adobe, announced support from Samsung, and various open-source initiatives, indicates a significant and increasing level of industry buy-in. This growing ecosystem challenges the "lack of interest" argument previously cited by Chrome. […] > > Given these factors, it is recommended that Google Chrome reconsiders its decision and reinstates support for the JPEG XL image format.

(I didn’t ask it to reach that conclusion)

what I asked was exactly this: > Should Chrome add support for JPEG XL, given that it has already added support for AVIF?

Gemini would run significantly slower on future Chrome versions😤

Google is also known for its internal sabotages

iirc there are some differences, but no major ones I can remeber off hand

In terms of features?

yeah like openexr has no limits on image channels

Does the industry require more than 4,099 channels?

yes!!! we need 2147483647 channels!

no idea, I would assume in some niche cases probably

Everyone wants 4,100 channels and more

My board is 32-bit and I think the binaries are only 64-bit, right?

`jxl-x86-windows-static.zip` is for 32-bit

they are not on Windows

High layer counts would only make sense for niche uses (abov/underground mapping, 'action as a layer' raster editing, collaborative editing of a single image) but even if its not actively used with .jxl files at least its futureproof. The high limit enables specialized file formats (like proprietary ones) to replace their limited ancient implementations and not need new implementations for a very long time

I didn't realize. It looks like they are 64 bit only.

Your only option is to compile it yourself, which I or someone else here can help you with, or find a package/ports manager to do it for you, like maybe Linuxbrew

Makes me wonder if there's a way to consolidate one predictor across multiple contexts... Or just cull contexts based on identical node results

I assume either this is necessary or the impact is negligible, but makes me laugh nonetheless seeing such a huge tree always pointing to seeminly the same thing

It’s entropy encoded so most likely wasting 50-100 bytes at most

The actual distributions are clustered so it’s not like there are that many actual ANS contexts

I was thinking of tree traversal too, lots of branching for the same results

Tree traversal should still only be as slow as the depth of the tree

Yeah, but this is one of the deepest parts too. Around 50% longer than the rest, or 5 nodes deeper out of 10

Do we simplify the tree to cut decision nodes that lead to the exact same two leaves after ctx clustering? I don't think this is implemented and it should be a no-brainer since it can only speed up decoding and reduce signaling overhead.

How does it pick when to split?

Does it start off with a more descriptive tree but then cluster similar distributions together?

Growing a tree and then pruning it does sound like a very organic way to do it Is there a way to limit tree depth currently? It could be useful for faster decoding levels too

is it the <:JXL:805850130203934781> spec that doesn't support CMYK, or just `cjxl`/libjxl that doesn't?

e.g. when transcoding a CMYK JPEG I get this: `Error while decoding the JPEG image. It may be corrupt (e.g. truncated) or of an unsupported type (e.g. CMYK).`

CMYK transcoding is not within the spec

3 channels for VarDCT

VarDCT has a hardcoded 3 channel limit, the 4th (Alpha or K in CMYK) has to be modular encoded

You can use -j 0 to disable the transcoding, though you'll probably need to do lossy for any space savings. Would be nice if we could store the CMY with transcode and the K lossless anyway for the savings

You wouldn’t be able to do bit identical reconstruction but it would be nice for it to be able to at least copy the dct coefficients

cmyk jpeg is very inefficient for storage compared to normal jpeg

It's only meant for a specific printer

Whichever printer and inks it was made for

It's much larger than a normal jpeg

It's recommended not to use them at all and find the original file before it was converted to cmyk

easier said than done

Hello, I am trying to convert my photo library to JXL. Does anyone know an effective way to keep HDR from iPhone photos (in HEIF format)? I am using XnViewer to do batch convert but it seems like the result does not preserve that (I can tell by opening the photo on my Mac, with the original the photo is displayed with a very bright screen, the JXL shows darker).

Good question. Need something that can decode HEIC with gainmap properly. Anyone know if magick or vips can?

Looks like almost nothing can decode Apple's dumb HEIC into a normal HDR file. your best bet is maybe https://github.com/johncf/apple-hdr-heic but it's not very easy to use. You can decode HEIC to EXR or AVIF and then use vips to convert to JXL. `apple-hdr-heic-decode input.heic output.avif -b 12 -y 444` `vips jxlsave output.avif output.jxl --distance=1`

Will take a look, thanks!

Another example. This time using the same decision nodes, which then lead to the same leaves

The black is no predictor

It's the combination of predictor and context that matters

Yeah, I just realised it's probably because a decision tree can only link to 2 nodes, so to use all the contexts in specific channels, it needs to create new nodes for the leaves to link to

It's part of a lossless squeeze tree. I was trying to figure out what predictor works best, then realised it's almost always 0 until it hits the residuals and then requires more predictor types

10 layers deep

hi! I just tried this, apple-hdr-heic managed to convert the HEIC to avif (a very heavy file if compared with the source) preserving the hdr, but using vips to convert from avif to jxl makes a grey-ish photo

I don't really know how to deal with HEIC to (with many steps) JXL

especially if that's 10-bit HEIC to 10-bit JXL

Maybe converting to EXR would be better, but be sure to keep track of and specify the color primaries and transfer curve etc

cjxl takes exr input

That would be 10-bit to 16-bit which would be meaningless

And all HEIC pictures taken by iPhone are lossy

If the purpose is simply archival I would just leave them alone

that makes sense 😅 I was just looking for good compression without sacrificing much quality, but since iphone's heic are not that heavy, I think I can live with that