JPEG XL

good to know

the stable release is stable though

quality wise it seems like it's in a really good position once the current PR gets merged. Probably the only stuff to look into further would be optimization related such as if the size of the LUT could be reduced while still being acceptable visually and what veluca was suggesting with trying a low memory integer representation

whats the conditions needed for djxl's `display_nits` to work? this image for instance has zero difference `--display_nits=40` vs `--display_nits=4000` with ver 0.11.1 ``` jxlinfo /tmp/test.jxl JPEG XL file format container (ISO/IEC 18181-2) JPEG XL image, 2560x1440, lossy, 32-bit float (8 exponent bits) RGB intensity_target: 1012.500000 nits min_nits: 0.000000 relative_to_max_display: 0 linear_below: 0.000000 Color space: RGB, D65, sRGB primaries, Linear transfer function, rendering intent: Relative ```

it’s possible that it relies on the signalled transfer function being PQ (for Rec. 2390 tonemapping) or HLG (-> OOTF)

with linear, you might just be getting the “scale 0-`intensity_target` to 0-1” behaviour

that would make sense, right now im just pointing people to use jxl-oxide,

Does anyone know why this PNG fails to encode with cjxl? cjxl outputs `Getting pixel data failed.` and nothing more.

> Warning : [minor] Trailer data after PNG IEND chunk could it be because of that ?

probably, last I checked it hard crashes on that

at least I get that with v0.11

Yeah, stripping out trailing data should make it work with libjxl

Makes sense, reading that data could probably increase chance of vulnerabilities?

I can't imagine it's a deliberate choice. if it was, the sensible thing would be to ignore trailing data, rather than crash

or at least error with a message that says the PNG contains errors, mentioning the trailing data (I'd prefer that actually, because allowing slight non-compliant-ness in your input, like allowing trailing data, seems great on the surface, but the bigger picture is that the more software does that, the lesser people are discouraged from outputting incorrect PNGs)

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

Huh, the embed didn't fill in the issue info. But display_nits is broken and has been for a while

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

I could probably look into making that a warning only

Does cjxl parse data after IEND tag and then fail, or does it instantly stop parsing any more data? Or is it actually libpng which refuses to decode the pixels thus libjxl/cjxl never gets any actual pixels? The printed error would make perfect sense in that case

interesting

my only contribution to the AV1 (and consequently to the AVIF) format was to get per channel quantization tables, there, too :-D, it has them

Big difference and possibly a design mistake (or at least a feature) in JPEG XL is that the AC Strategy is the same for luma and chromacity. This makes it rather expensive to model sharper changes in chromacity through smaller transforms, because then those smaller transforms will increase the cost of the inherently more expensive luma information ((it was my decision back in the day, it has plusses and minuses))

Oh, you mean seperate DCT sizes for Luma vs Chroma?

yes, AVIF has it

it makes encoding much easier

Also, I consider the JPEG XL images are most often viewed at a distance of more than 1000 pixels -- and this allows for psychovisual optimizations that relate to chromacity. When zooming in more, those optimizations fall apart and color transitions look funky. The same can happen with pixelized textures or even in highly noisy images.

The Dithering Saga Continues...

I should get back to tuning the AC strategy again, but I think it makes more sense to target accepable quality instead of smaller size. Distance can always be increased and quality lowered, but raising quality also 'wastes' bits on the areas which already looked fine

could you elaborate on what AC Strategy means here? you can signal different quant tables per component, right? so that's not it

you can always compose two frames, one with just the luma and the other one with just the chroma 😛

when an area is 8x8 or 32x32, it is that for all components, cannot be 8x8 for luma and 32x32 for X and B

ohh

fascinating

so it's "blocks have channels" rather than "channels have blocks" basically

I can see why that's a lot faster

the same integral transform selection decision affecting X, Y and B, where Y and B are masked by Y, makes an interesting world for the encoder developer -- heuristics will be very close to minimizing maximum error, but not quite, often 8th power of 16th power or similar works the best

I thought it could be made faster and simpler, but that was likely a fantasy that doesn't realize in real life given the 256x256 buffering is needed for threading in any case

ah dang, that's unfortunate

well, it's hindsight, what can ya do

aside from quietly making an itty bitty change to the bitstream :3c

AVIF moment

when JPEG XL matures, it is possible that we will mostly be using various kinds of 8x8s (perhaps 2x2, 8x8 with some 16x8s added into the pool), and this question is not that important -- I don't think the future world will use low quality images

about half the transforms (by transform type) are 8x8 sized, so JPEG XL is well prepared for the world with smaller transforms

libjxl tiny only uses dct8x8 and dct8x16

Obligatory block diagram

we love the block diagram ✨

128 and 256 aren't used at all yet, I think even 64 only got 'enabled' in v0.9 so still lots of room in both the high and low quality range

AFV-transform, I like to call it the corner-cutting-transform

related. so I've been thinking... you can represent slow gradients fairly cheaply with a few lower frequency HF coefficients. but does the encoder consider that it's possible having just that single LF component in combination with adaptive LF smoothing, could result in a gradient that's about equally correct, while saving on having to encode the gradient explicitly?

it is complicated

the cosine waves are 'wavy', and LF doesn't get spatially interpolated in the 8x8 transforms, to get proper interpolated we need 16x16 at least, and then it is in that cosine-interpolation mode that is not so good

in Pik we were able to solve it better because only 8x8 DCTs, we could solve the frequency lifting much more thoroughly

I do sometimes wish we'd have specified some form of smooth interpolation of DC values, and figured out what that would do to DCT coefficients on the decoder side, but I suspect it'd be quite slow

We do have adaptive LF smoothing in the spec...

Honestly, I'm surprised it's the HF that gets hit in the quant table so hard when LF is so resilient with the adaptive smoothing. I think we could get away with a lot more there and use the spare bits to stop the HF bleed/saturation issues. Not sure how hard that'd be to do though...

not going nearly as far as "upsample the DC 8x by some fancy upsampling algo and code the residuals with DCT" 😛

(although I guess that can be emulated with two layers)

Couldn't a theoretical encoder do that already? Do the non-seperable upsampling and subtract it from the original image, then hand the residuals to the DCT pass

yes, with multi-frame you can do a lot in principle, not sure if it's a good idea though for decode speed

changing the ratio spent on LF/HF could make sense, probably we are being too conservative on LF (but "better safe than sorry" does apply to LF imo)

hydrium just encodes LF losslessly using gradient

it was much simpler than trying to quantize

plus squeeze is awful for memory

doesn't *need* to be

doesn't it require you to buffer all the blocks to the top and left

hydrium doesn't buffer more than a single LF tile at once

IIRC no, just the one exactly on top or exactly on left (and even there just the last row/column thereof)

A random thought, I wonder if using 128x128 groups instead of the default 256x256 for fast lossless would give a speed bump and a bit lower memory usage

thanks for doing this 🙏🏻

this is super useful for 4:4:4 stuff

I tried to add more QM goodness to AV2, but parts of the proposal had to be reverted due to `[redacted]`

knowing nothing, I am going to bet that `[redacted]` is related to some hardware vendor 😛

this makes sense... AV1 uses flat QMs by default, so encoders overspend bits in chroma for 4:4:4 content

btw <@297955493698076672> any thoughts about trying to do whatever magic you did to AVIF heuristics with JXL? 😛

very good guess, but it wasn't hardware this time... the teams were shockingly very enthusiastic with the proposal

> flat QMs hm not sure what that means

you have no idea how surprising this is for me 😛 (and the next guess is some patent)

oh, quantization matrices

yeah

you might be onto something here 😉

and it was actually not due to our proposal even

but an integration issue

so it's using the same matrices for chroma as it does for luma, you mean? and that's why there's no color bleeding?

"flat" here means "same quantization factor for all the AC coefficients"

(both for chroma and for luma)

IIRC that (used to be) the default

well, JXL is already doing the right things

it was AVIF was actually so PSNR-maxxed that they didn't even enable basic coding tools for still image coding

but certain heuristics related to screen content coding in AV1 can definitely be translated to JXL

<:Thonk:805904896879493180> so it's like: every square here as the same number? all coefficients are quantized by the same amount?

correct

oh what, I never considered that that would result in anything good

fascinating

it's good in a sense that your chroma will look *really* good relative to luma

I figured, but too bad that there aren't easyish free wins 😛

IMO, if JXL can make 203 intensity the default that'd be awesome

the current defaults are crushing blacks too much

[Hmm](https://cdn.discordapp.com/emojis/1113499891314991275.webp?size=48&name=Hmm&lossless=true)

~~make it 80~~

I noticed that too and brought it up, unfortunately upping the intensity target doesn't just improve compression in dark areas, it actually makes the image brighter in PQ for example

what's the current default?

thats to be expected no?

I assumed it didn't, because in sRGB the intensity doens't change

If you go back to v0.8 then yeah, but right now there's still a lot of work to do between re-weighting the block selection and figuring out new quant tables without desaturation

when encoding a file you are telling jxl what luminance 1.0 is, so jxl would map that to PQ

yeah, I'd say fixing these two regressions is important, so y'all are doing the right thing

The current default is 255...

huh

I would say the inverse is a bug then

255

maybe an --luminance-bias might make sense

~~though never forget mastering nits for sRGB is 80~~

so it sounds like there might be a regression with the underlying AQ heuristic that takes in the brightness number?

there's *something* going on that's causing libjxl not spend as many bits as it should in dark areas

Right now "y'all" is just me unfortunately, and I've been busy the past few months with holidays and health so haven't made any progress. I'm a lot better at finding problems and suggesting solutions than I am actually fixing them 😅

Fixing blue noise the other day was a very nice surprise though, silky smooth dithering for all

the "all modern infrastructure" xkcd but it's JXL encoding quality and you're one of the blocks

yeah, fixing nontrivial issues usually takes longer, unless you're like the author of the software in question

but even trying is super commendable, because making changes to codecs isn't easy

we do have the paper proposing better block merging heuristics for JXL that we haven't implemented yet. that's probably a low hanging fruit one, given that the logic is already there. they just didn't contribute the code back

I do want $eventually to write an encoder in jxl-rs and have fun with heuristics

but who knows when xD

It mostly takes ages because I still don't know how to code fully. Most of the fixes/improvements the past year have been me finding something via cjxl, reading the code to find what went wrong, then asking <@207980494892040194> to help me try various ideas until 5am. The spaghetti code is a blessing and a curse, because generally I can just reference the surrounding code to eg, force a predictor or enable LZ77. Libjxl is surprisingly modular but very brittle.

AFAIK it seems to have been done for a paid product and I don't know if it's patented or not

[Improvement of JPEG XL Lossy Image Coding Using Region Adaptive DCT Block Partitioning Structure](https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=9505599)

Some papers display psuedo-code or even have the example code in a repo, but AFAIK they only gave a very high level explanation

we later found out this was implemented in a commercial JPEG XL encoder, but iirc there was nothing preventing us from implementing it too

... there are commercial jpeg xl encoders?

there is at least one... that one

I remember finding the website for the product/encoder but I don't remember the URL

last time I mentioned this paper, Jon mentioned that they remembered seeing one of the authors at a JPEG conference. we dug deeper, and found the encoder that uses this algorithm

ahh that was you, yeah

iirc they actually advertised this better quality per byte over libjxl on that page

it might have been jonny who found it? my memory is a bit rough

https://doublebench.com/doublebench-software/#db-software-tabs|0

there are patents listed on the site, should probably check them against the paper just in case

also semi surprisingly the paper and encoder are seemingly from 2021

https://sejong.elsevierpure.com/en/persons/oh-jin-kwon/ <@179701849576833024> I think you may have been at the meeting where Oh Jin or one of his students were presenting their block segmentation approach, or was it Jan back then? It's from quite a while ago

I have some vague memories of this

it seemed to be just some master thesis project or something back then, didn't know they were going to try to sell that stuff

I doubt there's a market for commercial jxl implementations tbh, except in hw

> Our $500 Evaluation License allows you to evaluate DoubleBench for up to 6 months wew

I was gonna say we could try it out and see if it's actually any good, but...

> DoubleBench’s JPEG XL software partly uses JPEG XL reference software (https://gitlab.com/wg1/jpeg-xl/) under Apache License 2.0 (http://www.apache.org/licenses/).

their legal page makes me think it's probably violating the libjxl license

it's probably a derivative work of libjxl rather than a client

It says it's apache but it's actually BSD 3clause

``` thread 'api::decoder::tests::compare_pipelines_alpha_premultiplied' (260492) panicked at jxl/src/util/test.rs:125:9: assertion failed @(2311, 41), c 0: `(left ≈ right)` left: `0.030203538`, right: `0.0302206`, abs error: `1.7061829566955566e-5` max_abs_error: `1e-5` ``` _sigh_

... should we have a jxl-rs channel?

<:YEP:808828808127971399>

(that was literally an off-by-one)

When batch encoding pictures, is it faster to just encode several pictures at once using single-threaded encode, or one picture at the time using multi-threaded encode?..

Singlethreaded. The multithreaded overhead shouldn't be much, but if you're not limited by memory usage then running in parallel should be fine (And you could run effort 10 without the singlethreaded penalty, since you already are. Though maybe add `--patches 0` if they don't have text)

multiple pictures using multi-threaded encode

but surely a test on a sample in your environment would inform best about details

is there anything stopping the following PRs from getting merged? https://github.com/libjxl/libjxl/pull/4559 https://github.com/libjxl/libjxl/pull/4561

it seems like they are ready to get merged but either haven't been fully accepted yet or are maybe getting stopped from the failed Bazel test that's unrelated to them

Is this extreme banding in the works of being fixed? Both 0.11.1 and a pretty new main build shows this. I find this impacting quite a lot of my screenshots with dark gradients to the point of being a showstopper currently. `-d 0.7 -e 7`

could you send the source file/image you are encoding from and also a sample of the JXL you are getting out as well?

Assuming the screenshots are 8bit, the banding is baked into the image, so JXL will try to preserve it

Forgot to enable auto-merge

"forgot"

Well it got approved a few days ago

libjxl maintainers are professionals, it is more likely intentional than unintentional

hm? auto-merge is enabled

I imagine it's blocked by the bazel issue

Only checks marked as `Required` block merging, and auto-merge has to be enabled per-PR One of them you approved but didn't set to merge, the other Eustas set to merge but didn't approve

Looks like a nice test image, can you share the original so we can play with it?

I should've checked with more software, the banding only appears in Affinity and not in ImageGlass. I can only get the banding to appear when opening the JXL, no problems with the PNG. Affinity recognizes the PNG as `RGBA/8 - sRGB IEC61966-2.1` (the original document setup) while it loads the JPEG XL as `RGBA/8 - RGB_D65_SRG_Per_SRG`. I don't know if this could be a hint to the cause? As said ImageGlass has no problems with displaying the file. I can paste `jxlinfo` output below

```JPEG XL image, 2000x3143, lossy, 8-bit RGB Color space: RGB, D65, sRGB primaries, sRGB transfer function, rendering intent: Perceptual Brotli-compressed xml metadata: 563 compressed bytes```

I also ran into a memory usage problem with some screenshots and the original test image I created and sent here, but that's a side note. The JXL seems to use an enormous amount of memory to load compared to the PNG

I can still provide the sample images if it's relevant

I thought the image you sent yesterday was a screenshot of the JXL since I can see noticeable banding in the dark?

yes this would be helpful so others can test this as well

It's a screenshot of the image open in Affinity 3

The original PNG is huge as I thought the problem might've been resolution dependent as I only noticed the problem on huge images, but I think this was a coincidence

I needed to split up the archives because of Discord upload size limits

The JPEG XL images are made with cjxl v0.11.1 and parameters -d 0.7 -e 7

out of curiosity did you create the source PNG yourself or did you find it somewhere? if you created it yourself, I'd also be interested in a 16 bit per channel PNG of the high-res one. given that these gradients are so slow, it might even compress a bit better with JXL which I'm curious about

> a 16 bit per channel PNG of the high-res one or a lossless JXL, since then it might actually be small enough to send on Discord :p

I'm comparing the PNG and JXL and they look almost exactly identical

I guess some software is just handling JXL incorrectly

That kind of banding looks like it went through 8-bit linear RGB

The 16bit variants become huge, but I can upload the .af file? Affinity 3 is free, but only for Windows and macOS

It's just a simple gradient I made on a fill layer with mesh type fill

huh, are they huge in lossless JXL as well? I thought for images like these a higher bit depth would lead to better compression because the predictors would be more effective

thanks though!

from a discussion in <#1464417869470371912> -- any thoughts about making cjxl by default buffer the _output_ in memory (at least by default)? that's most often not a lot of data, and lets one do the more "usual" group order

If this fixes chucked encoding ordering groups in a way that doesn't work well with progressive then yes. currently when adding `-p` to encode a image with extra/full progressiveness it disables chunked encoding in the main branch as a workaround and in 0.11 it uses chunked encoding and results in a file that can barely be progressively decoded

https://discord.com/channels/794206087879852103/1464417869470371912/1466221239856271719 Is there a resolution limit for when the non-progressive images go from loading fuzzy groups to blank groups? From my limited testing smaller images seem to load almost in a progressive manner even when not encoded progressively, but at some size that changes and complete chunks/groups are instead loaded one-by-one

Windows users rejoice! Libjxl is finally using clang! Roughly a 50% performance improvement over MSVC.

where?

https://github.com/libjxl/libjxl/commit/8ce9537c989cfc7adff034556c8a4b9469e874d6

oh

We're going to have to wait for v0.12 of course

Well, now https://artifacts.lucaversari.it/libjxl/libjxl/latest/ will have the speedup too

To jxl-rs' dismay

Sorry for the late reply, that'll be 2048 pixels in either dimension

Thanks

Isn't this this required to write jxl to nonseekable media without using hydrium-style frame tiling

Yes, I think so

Moving from https://discord.com/channels/794206087879852103/1464417869470371912/1466609238183776462 So on very large images, it does have a *slight* memory impact `PeakWorkingSetSize: 1.974 GiB` vs `PeakWorkingSetSize: 2.532 GiB` The actual JXL was 70MB, so I think buffering the output and reordering there would be a lot more flexible and efficient

Hmm, that image might've been an edge case, it didn't load progressively either

`444.6 MiB` vs `457 MiB` on another image, only a 3% increase to get the LF at 20% instead of 99% loaded

... 500mb?

what's that image xD

I'd expect something between 70 and 150mb of usage, not 500mb, from buffering in memory

suspicious

It's a Minecraft map screenshot, so pretty much all HF, but... It should still *have* an LF right? It's 83MP so definitely not patches

I imagine that's not full resolution

Here's the full res

nice, and how did you compress it?

`cjxl -e 5` to save a bit of time

with `--num_threads=0`?

No, just default settings

I get ~1.5gb of memory with 0 threads

the memory increase _could_ be due to the multithreading

as in, MT can make memory usage significantly less deterministic

In my experience threading didn't impact memory usage noticeably. I did try with 4 threads instead of 16 but nothing changed

interesting

wonder why you're using 400 to 1000 more mb

Figured it out, there was a second map image in the same folder and I picked the wrong one xP Here's the *actual* image, though both have the same behaviour. Using the same amount of memory single or multithreaded and use a few hundred megs more with your PR

ahhh I think I see why

<@238552565619359744> try again now 🙂

That minecraft map actually uses 2MB less than main now, and other images are nearly identical, so if we don't find any issues I think it'd be fine to merge

Eh, I still would prefer the flag to be wired up to keep the old behaviour in case you need it for some really huge image

and for that matter, another thing that could use some improvement is the documentation of the "BUFFERING" setting xD

Is there anything I can do during encoding to reduce decoding memory usage for large resolution jxl files?

There's `JXL_ENC_FRAME_SETTING_DECODING_SPEED`, but it controls speed, not memory.

I've already set it to 4

The reason why i need this is that iOS seems to have memory issue during saving high res JXL. When my app uses over 400mb memory, saving high res JXL by using `PHPhotoLibrary.shared().performChanges` will fail. When the app take less than 100mb, it can save the high res jxl. There's no problem with high res JPG and high res AVIF.

I also assume that streaming encode would result in streaming decode, but I'm not sure on that front

Thank you for giving the idea, i'll have a try

I tried to enable `progressive_dc` but the encoding process using too much memory with this mode which cannot work on ios

it doesn't work, by changing `JXL_ENC_FRAME_SETTING_BUFFERING` to 2, it still fails to save the high res jxl

That's because 2 doesn't do anything https://discord.com/channels/794206087879852103/1464417869470371912/1468282242974486692

Thank you for metioning that. It seems there is no way to prevent the failure.

I assume you're doing lossy encoding?

yes

There is no memory problem during the encoding part, the issue is caused during saving the JXL to Photos on iOS.

Strange....

I don't know how Apple deals with the decoding process...

With high res AVIF(same resolution), it even works up to 1.5G memory consumed. Maybe Apple has optimized the AVIF decoder a lot.

What resolution crashes for example?

48M, it won't crash, it just returns the error said, failed to save the JXL

PHPhotosErrorDomain 3301

curious could you share code snippet? AFAIK saving jxl to photos is not supported and should fail returning something like this ```findWriterForTypeAndAlternateType:132: *** ERROR: unsupported output file format 'public.jpeg-xl' CGImageDestinationCreateWithData:5573: *** ERROR: CGImageDestinationCreateWithData: failed to create 'CGImageDestinationRef'```

I save the jxl binary by using `PHPhotoLibrary.shared().performChanges`

``` PHPhotoLibrary.shared().performChanges({ let creationRequest = PHAssetCreationRequest.forAsset() let options = PHAssetResourceCreationOptions() options.originalFilename = name + ".jxl" creationRequest.addResource(with: .photo, data: data, options: options) }) { success, error in print(success) } ```

the `data` is JXL binary

so nothing special

I didn't know this way it would work 🙂 I'm getting the same though. It seems photos service just panics ```Connection to assetsd was interrupted - assetsd exited, died, or closed the photo library Error getting remote object proxy for -[PLNonBindingAssetsdPhotoKitAddClient sendChangesRequest:reply:]_block_invoke: Error Domain=NSCocoaErrorDomain Code=4097 "connection to service named com.apple.photos.service" UserInfo={NSDebugDescription=connection to service named com.apple.photos.service}``

I wouldn't be surprised if Apple just decodes jxl to full buffers in float32 and then takes it from there, while for other formats it probably decodes to uint8 or uint16 buffers, or maybe even something like 10-bit yuv or whatever.

I hope I chose the right channel. Does anyone have an idea why the libjxl perceptual metrics tools cannot open PNGs round-tripped through AVIF via `avifenc` + `avifdec`? ``` +++ +++ While converting /home/intelfx/tmp/big/sync/{jxl-images-phoronix-2/800x534/source.png -> jxl-images-phoronix-2.svtav1:tune3.L0.q30.s4.out/800x534/source.temp.avif}: +++ Decoded pair /home/intelfx/tmp/big/sync/jxl-images-phoronix-2/800x534/source.png -> /tmp/decoded.JDbudi.png: +++ Metric tool ssimulacra exited with 1 +++ JPEGXL_TOOLS_CHECK: jxl::SetFromBytes(jxl::Bytes(encoded), jxl::extras::ColorHints(), io[i]) +++ +++ While converting /home/intelfx/tmp/big/sync/{jxl-images-phoronix-2/800x534/source.png -> jxl-images-phoronix-2.svtav1:tune3.L0.q10.s4.out/800x534/source.temp.avif}: +++ Decoded pair /home/intelfx/tmp/big/sync/jxl-images-phoronix-2/800x534/source.png -> /tmp/decoded.908ZuM.png: +++ Metric tool ssimulacra exited with 1 +++ JPEGXL_TOOLS_CHECK: jxl::SetFromBytes(jxl::Bytes(encoded), jxl::extras::ColorHints(), io[i]) +++ +++ While converting /home/intelfx/tmp/big/sync/{jxl-images-phoronix-2/800x534/source.png -> jxl-images-phoronix-2.svtav1:tune3.L0.q30.s4.out/800x534/source.temp.avif}: +++ Decoded pair /home/intelfx/tmp/big/sync/jxl-images-phoronix-2/800x534/source.png -> /tmp/decoded.JDbudi.png: +++ Metric tool ssimulacra2 exited with 1 +++ Could not decode distorted image: /tmp/decoded.JDbudi.png +++ +++ While converting /home/intelfx/tmp/big/sync/{jxl-images-phoronix-2/800x534/source.png -> jxl-images-phoronix-2.svtav1:tune3.L0.q10.s4.out/800x534/source.temp.avif}: +++ Decoded pair /home/intelfx/tmp/big/sync/jxl-images-phoronix-2/800x534/source.png -> /tmp/decoded.908ZuM.png: +++ Metric tool ssimulacra2 exited with 1 +++ Could not decode distorted image: /tmp/decoded.908ZuM.png +++ +++ While converting /home/intelfx/tmp/big/sync/{jxl-images-phoronix-2/800x534/source.png -> jxl-images-phoronix-2.svtav1:tune3.L0.q30.s4.out/800x534/source.temp.avif}: +++ Decoded pair /home/intelfx/tmp/big/sync/jxl-images-phoronix-2/800x534/source.png -> /tmp/decoded.JDbudi.png: +++ Metric tool butteraugli exited with 1 +++ Failed to decode image from /tmp/decoded.JDbudi.png ``` (avifenc parameters are encoded into file names in the log above)

It's got something to do with the metadata, I got ssimulacra2 to read the PNG when stripping it all out. Not ideal.

Metadata after IEND?

Nope, seems like the color metadata is throwing it off. Still fails after `oxipng -s output.png`, `--strip all` works.

OK, I built libjxl with debug and this is enlightening: ``` $ build/tools/butteraugli_main ~/tmp/big/sync/jxl-tests/in.png ~/tmp/big/sync/jxl-tests/out.libaom:iq.L0.q30.s6.png ../lib/extras/dec/apng.cc:222: Unsupported transfer function specified in cICP chunk: 2 ../lib/extras/dec/apng.cc:1074: JXL_RETURN_IF_ERROR code=1: DecodeCicpChunk(payload, &ppf->color_encoding) ../lib/extras/dec/decode.cc:178: JXL_FAILURE: Codecs failed to decode ../lib/extras/codec.cc:48: JXL_FAILURE: Codecs failed to decode Failed to decode image from /home/intelfx/tmp/big/sync/jxl-tests/out.libaom:iq.L0.q30.s6.png ```

judging by H.273, 2 is "unspecified"

not entirely incorrect, I guess, but how do I make stuff work?

Well, if it's an sRGB image, stripping the metadata will make ssimulacra2/butter treat the PNG as sRGB by default.

Looks that way — the original PNG image has no cICP chunk, only cHRM, but photographic metadata says sRGB, so I guess avifenc is just not smart enough to figure it out

Avifdec is tagging the file with illegal color metadata. You can override it with a tool like umbrielpng without stripping all

Yeah, I just locally patched libjxl's PNG loader to ignore a partially "unspecified" cICP when other colorimetry chunks exist

Ye, tho check out umbrielpng in the future. It is a png filterer that doesn't touch the IDAT chunks unlike most of them

(which means it's very fast)

It is legal, it's just that libjxl doesn't support it Should file a bug on the libjxl repo

cICP chunk should take precedence per PNG spec, so that may not be a good solution

It should, but if it contains an "unspecified" in one of the fields, then what is the proper semantics of such a file?

Just use sRGB and ignore other chunks I guess

I wouldn't call "unspecified" legal....

Isn't that strictly worse than using the best fully unambiguous colorimetry chunk? Like, cICP is optional, so it should be valid (internally consistent, at least) to cosplay as a decoder that just is not capable of parsing that chunk, otherwise what's even the point of the precedence rules in the standard?

It's the encoder's responsibility to keep color chunks consistent, but that's not guaranteed (or not feasible in some cases). Actually I'm surprised you get an unspecified cICP and a valid cHRM, what's the CICP of the AVIF?

is the "unspecified" in the matrix coefficients and/or tv range field?

just the transfer curve I think

well, then kinda hard to do anything with that CICP...

I'd say we should interpret "unspecified" as being some crazy tf, say some extreme gamma that will make the image very bright, and if someone complains we just say "well you didn't bother to specify so we picked something"

bonus points if chrome also does that

When converting PNG to JXL via libjxl's API, which things I should be aware of? There's a color profile, but there's also gamma, color space, white point and stuff separately?.. Is that even exposed in image loading libraries?

depends on the image loading library, but I think many don't fully get it right, e.g. only supporting ICC profiles but not the various other ways to signal colorspace in PNG.

to load a PNG in something like PIL or whatever with an actual correct colorspace, you need to manually check for the various chunks and implement the precedence logic of the PNG spec, i.e. first check cICP, then ICC, then sRGB, then cHRM/gAMA, iirc. And you need to manually interpret all those chunks. So it's basically pretty messy and not very surprising that many applications get it wrong.

Things would be a lot more straightforward if png decoders would do the libjxl/jxl-rs thing and have a function that just always gives you an ICC profile that corresponds to the colorspace of the decoded data, regardless of how that colorspace was signaled in the file (i.e. it produces an ICC profile from more compact representations if needed).

I figured out why it still wasn't progressive, Alpha delays the LF from loading. Setting it to lossy Alpha lets the LF load, so I *think* we could re-order the lossless frame before the VarDCT data, would give a nicer progressive image too as the edges would be sharp while color data loads in

I suppose we were going to interlace Alpha with Color for jxl-rs to display ⁨`-p`⁩ progressive images anyway, but it would bring back the 'inherent' progressiveness too if it's not too hard

I've been thinking of doing something like this for unspecified pixel data in jxl files, e.g. from overlapping a bunch of splines like slow flashing between fully transparent and red or something

Gmod Error as JXL art embedded as a background frame

lmao

the freaking 3d model

Give me more context please? It's all out of cache 🤣

Is the buffer overflow which is getting fixed in past versions too seen as a security problem, or is it a "safe" crash?

I'm taking a crack at improving the buffering settings, namely adding the logic so `JXL_ENC_FRAME_SETTING_BUFFERING` actually does something, and defaulting to group buffering so there isn't a discrepancy between 1080p and 1440p images. Also trying to add an option to cjxl to control the level, but getting a little bit overwhelmed.

will give that a look eventually

probably not this week, I'm quite busy

<@811568887577444363> I noticed you're doing a new minor release, I don't suppose this is worth including too? https://github.com/libjxl/libjxl/pull/4027

It fixes a bug that caused effort 1 lossless images to not actually be lossless, which while not a security issue, definitely is quite severe https://github.com/libjxl/libjxl/issues/4026

let's put it this way: not including it incentivizes us to make a 0.12 sooner 😛

0.12 has been a looong time coming although tbh there's still some nice improvements that haven't been finished to be merged in yet...

for example I wonder what the failing testcase on this is? https://github.com/libjxl/libjxl/pull/4296

the runs are so old that the logs got deleted

would anyone be willing to re-run/re-trigger the Conformance tests on this PR?

I think I might need to rebase first; trying that

my rebase drops a slight change to `jxlinfo` (it was changed more extensively in the meantime), so just to be safe, I’ll push the rebased version as a separate PR

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

thanks! after doing some looking around with <@207980494892040194> for a while I think I might have found the culprit for the failing case. It seems like there aren't any decoded pixel values getting changed for the lossless test, I think it's calculating the error between two ICC **files** that are slightly out of sync metadata wise (profile description and profile id) but otherwise have all the exact same color transformations and curves. I *think* to fix this the hash on this line in this file for "reference.icc" https://github.com/libjxl/conformance/blob/4bf053529c7cefd2951be453475bb3dccc7e7be8/testcases/lossless_pfm/test.json#L21 would have to be changed to `87948CDB39DC5FE2044FA8A340B09B27AD06A3A0795F6EED5B8EF4CBCF6EA051` and the icc file attached to this message needs to be uploaded to replace the old one on the Google storage server (however that's done): https://storage.googleapis.com/storage/v1/b/jxl-conformance/o also going to ping <@794205442175402004> for this.

sorry for the possibly poor formatting of my message I have been awake for a bit too long

`ColorEncodingDescriptionImpl` used to take rendering intent into account, that icc has a relative (instead of perceptual) rendering intent so it didn't get the sort name before

The conformance tests checking ICC profiles are too strict: we should only require bit-exact ICC profiles in case of have_icc instead of also requiring that in case of synthesized profiles.

I’m not sure it’s actually checking the ICC profiles bit-exactly here; I think it’s just failing to skip the CMS so there are small numerical errors in what should be an identity transform

There are https://github.com/libjxl/libjxl/tree/main/tools/conformance and https://github.com/libjxl/conformance, which should be the source of truth?

ah, wait, we already have https://github.com/libjxl/conformance/commit/4bf053529c7cefd2951be453475bb3dccc7e7be8 for this (and the ProPhoto pull request updates to this)

I don’t think we use the former much

Isn't that what used in CI

as far as I’m aware, no, it’s the latter

https://github.com/libjxl/libjxl/blob/4867d7bb0853a557dbc53659c0485e6b7c856947/.github/workflows/conformance.yml#L148

that doesn’t seem to actually be used for much

as opposed to https://github.com/libjxl/libjxl/blob/4867d7bb0853a557dbc53659c0485e6b7c856947/.github/workflows/conformance.yml#L43-L48

I think it will download that later in https://github.com/libjxl/libjxl/blob/4867d7bb0853a557dbc53659c0485e6b7c856947/.github/workflows/conformance.yml#L227 and https://github.com/libjxl/libjxl/blob/4867d7bb0853a557dbc53659c0485e6b7c856947/.github/workflows/conformance.yml#L262 runs the conformance.py from the base dir?

… oh

that would certainly explain why “skip color transform when expectation is lossless” didn’t fix it

Also it should just error out if it was using the fixed conformance.py https://github.com/libjxl/conformance/pull/47

Why aren't libjxl libraries included in the Windows build on GitHub?

oh meh

It seems the release assets failed to upload due to expired PAT

For some reason, I was completely unable to unbind brotli libraries when compiling use msys2 (They weren't compiled natively from the source code of the downloaded Brotli itself, but were taken from the msys2 bin), but I will still send this for myself from the future (possibly) libjxl.dll v0.11.2

https://github.com/libjxl/libjxl/blob/main/doc/developing_in_windows_msys.md ? git clone https://github.com/libjxl/libjxl.git libjxl-clean cd libjxl-clean git submodule update --init --recursive mkdir build cd build bash nuclear_build.sh (It does **rm rf in the folder where it is located, don't screw up all the files**, it was more convenient for me to just clean up build with it)

would it be better to try removing the local copy of the testing scripts and have it use the actual ones from the conformance repo that gets downloaded? or for now is it just fine to update the local copy and hope it doesn't cause issues again in the future?

Quick question, every release of jxl i've found says the release is for evaluation purposes. Is there a version meant for actual use or will that not be a thing until version 1.0?

Yes, JPEG XL isn't fully ready, it has artifacts that shouldn't be there. They're small, but they're definitely there. In some scenarios or archiving, this may be unacceptable. BUT there's good news: it's only about the lossy VarDCT codec. If you're only interested in lossless Modular compression, you can safely use JPEG XL now.

Great to hear! Thank you!

as long as you do usual verification, since libjxl can fail to produce files or produce files which decoders refuse to decode

I'm thinking of converting GIF and APNG to JXL with libjxl losslessly. I don't want to rely on optimization of initial files (they could be unoptimized), so I should do optimization manually. Looking at API, bounding box of changes seems easy enough, but I want to encode only differences (including alpha differences). Initially I wanted to do it with XOR, but it seems like only ancient formats from Amiga era support that blend mode. Subtraction is the next best thing, but: 1) Would JXL_BLEND_ADD support negative values if JxlBlendInfo.clamp is False? How do I even input negative values if it usually accepts only unsigned integers? 2) I don't see any way to blend Alpha independently, how do I encode Alpha differences in this case?..

Any way to interrupt encoding? I know I can just stop feeding frames when encoding animation, but what about static images?.. Also, any way to keep track of the progress (percentage)?

One idea I have is to have chunking encoding and feed squares filled with black pixels into it when I want encoding to be interrupted, but I heard that effort 10 disables chunking, so...

Is it something to worry about? https://issues.oss-fuzz.com/issues/461519874

I've been through the same struggles. You can provide negative samples to the encoder, and it behaves how you would expect, but you have to use a floating point data type in the `JxlPixelFormat`. You can still set the image header bit depth to your original bit depth, and it will roundtrip losslessly at that bit depth.

Every extra channel, including alpha, can have its own blend mode/source (`JxlEncoderSetExtraChannelBlendInfo`). I think if you don't set it, it defaults to the blend mode used by the color channels.

What I found wild was the fact you can losslessly store the result of subtracting two 8-bit frames as an 8-bit JXL, even though there's an extra ~1 bit of information due to the range being [-1,1]... which I assume is because the header bit depth defines the *precision* but doesn't put hard limits on the actual range.

Correct.

Isn't that just modular arithmetic?

One thing that is pretty different between jxl and other image formats is that jxl doesn't require byte-aligned or even bit-aligned sample ranges; as long as it fits in float32 (or in case of Level 5, also in int16), it can be represented.

PNG, WebP, TIFF etc are all byte-based so if it's 8-bit, you literally get 8 bits and that's it. While in jxl, "8-bit" means the nominal [0,1] interval gets quantized to 256 values but you can still go outside that interval if you like.

And you can just as effectively do 7-bit or 9-bit if you prefer that, while that's awkward and inefficient in most other formats.

There's no wrap-around, so it doesn't really behave like modular arithmetic. It was just a slight mental gear shift coming from other image formats, to realize that an (uncompressed) sample can require more bits to represent it than the nominal bit depth of the channel it belongs to.

Does libjxl do any global pallete detection/color counting when chunked encoding is enabled? Was thinking of switching to LZ77 only when the amount of colors/bitdepth is very low (This could probably be done per-group too, but group/channel level compression parameters aren't implemented yet)

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

Lossless scales near-linearly with groups and threads, but I can't remember how VarDCT scales. Would it make sense to switch between 4 and 8 groups for lossless and lossy respectively? Then lossless still gets at least a 4x speedup for larger group sizes and density is sometimes better with chunked too

Currently common screen resolutions fall below thresholds too due to not being perfect powers of 2. For example, 8 groups with a 1080p image at 2,073,600 pixels 256x256: 524,288 pixels - Chunked 512x512: 2,097,152 pixels - Not-chunked 8 groups at 8K with 8,294,400 pixels 512x512: 2,097,152 pixels - Chunked 1024x1024: 8,388,608 pixels - Not-chunked Nevermind all of that, I forgot groups can be partially filled at the edges too, it should all work fine 😅

<@604964375924834314> if you get the time could you try replacing [conformance.py](https://github.com/libjxl/libjxl/blob/main/tools/conformance/conformance.py) within the [prophoto test run PR](https://github.com/libjxl/libjxl/pull/4619)~~ with the one from [here](https://github.com/libjxl/conformance/pull/47)~~ to see if doing so fixes the failing testcase?

If it does then IMO it might be worth it to just do that for the prophoto changes in the short term even if it doesn't fix the core issue of the libjxl repo not fully/properly using the files from the conformance repo

err wait it seems like the copy of conformance.py within the libjxl repo is quite different from the one in the conformance repo and I'm not sure if the libjxl repo one was changed away from the conformance repo one or if the one in libjxl is just that old

might be a combo of both.?

how about just this instead then: ```patch --- conformance.py +++ conformance.py @@ -35,12 +35,14 @@ return Failure(f'Expected shape {ref.shape} but found {dec.shape}') ref_frame = ref[frame_idx] dec_frame = dec[frame_idx] num_channels = ref_frame.shape[2] - if ref_icc != dec_icc: + if ref_icc != dec_icc and peak_error > 0: # Transform colors before comparison. + # Skip this if we expect fully lossless, since it introduces tiny errors + # (even in the case where ref_icc and dec_icc are equivalent so it's a no-op) if num_channels < 3: return Failure(f"Only RGB images are supported") dec_clr = dec_frame[:, :, 0:3] dec_frame[:, :, 0:3] = lcms2.convert_pixels(dec_icc, ref_icc, dec_clr) ```

``` /** Enables or disables preserving color of invisible pixels. Use -1 for the * default (1 if lossless, 0 if lossy), 0 to disable, 1 to enable. */ JXL_ENC_FRAME_SETTING_KEEP_INVISIBLE = 12,``` What if we extended it to also handle redundant alpha? Level 0 to remove empty alpha or overwrite invisible pixel color, 1 to only remove redundant alpha and 2 to always keep alpha

The thing is that you can have multi-frame images (layered or animation) where the first frame is fully opaque but the rest isn't. If you want to remove alpha completely, you need an image header that doesn't signal that extrachannel, but you need all frames to know if it's redundant, and the current API design is frame-by-frame...

Hmm, right...

hmm maybe redundant alpha removal/detection could just be handed/done by cjxl and maybe restricted to non-multi-frame images as well depending on how the input file type is handled/buffered?

we _could_ in theory do the "remove alpha" thing for single frame images

not sure how well the current code can deal with that

If we could get it working and enabled by default, it would mean a free bump to density, encode and decode speed along with better progressive loading

I just noticed a one-line edit that should significantly speed up progressive lossy encoding of images with transparency. Will test it in a bit

Around 30% faster with a first test, but going to investigate some more

A few hours of staring at an if statement later and I still can't get it working properly. It *should* be as simple as changing this to `ModularPartIsLossless` <https://github.com/libjxl/libjxl/blob/main/lib/jxl/enc_frame.cc#L1672>, but the `buffering < 3` check messes it up as it will always be true by default. Regardless of how I arranged it, tests would always fail if I linked the two together `(!(cparams.responsive && cparams.ModularPartIsLossless()) && cparams.buffering < 3)` Broke `if (!enc_state.streaming_mode && (!(cparams.responsive && cparams.ModularPartIsLossless()))) {` Broke even harder It's not a huge deal, as it only impacts progressive VarDCT images with a lossless alpha, but it is still a free 30% encoding speed boost ripe for the taking if we can figure out the conditional nightmare

create a table with every condition and desired outcome, it's usually easier to encode the if statement from that

The problem is it also depends on other encoder choices, so it's easier to rerun the tests in the background than try to backtrack the heuristics fully. It *should* have worked with both examples above, but something was causing it to fail

Is this what you are trying to do?

I think I tried something like that and tests still failed. I might keep trying another day

Well, it is mirroring your "Broke even harder" example (the others I could not interpret), but ensuring responsive is set. In this case there are no test failures, which were all size constraints without. It does allow speed ups, but not freely as there are size tradeoffs.

Hmm, interesting. I'll take another look when I'm on my computer, it's hard to read on mobile. I was seeing around a 0.1% size increase on my test file

It captures progressive lossless, which can get much larger and faster (e.g. >5% larger, >3x faster with 4 threads). Avoiding that, progressive VarDCT can still get both larger and slower.

Progressive lossless was already working, progressive VarDCT with Alpha was the target since it defaults to lossless

Yep, this is why I point it out. To target more specifically, you'd need to check against the lossless parameter and alpha information.

<@794205442175402004> I was thinking and had an idea for how crude preview frame generation could work with chunked encoding. no clue how bad or good of an idea this is or what the quality of the outputs would look like but here it is: What if when working on each chunk a downscaled version is generated and then kept around in memory until the end where each downscaled chunk is then recombined/restitched into a full image and inserted as a preview frame? would the output of this introduce unacceptable visuals/artifacts and does it even seem sound from a implementation perspective?

this is somewhat assuming that the intended resolution(s) of preview frames would be pretty low like an LQIP

I mean, lossy needs the LF anyway, so you already have a 1:8 downscale of RGB and 2048 x 2048 pixels in memory. Could just downscale it further

I was thinking mostly about lossless since well AFAIU you don't really get any progressiveness with it unless you use squeeze which would require the full image in memory

One fancy thing jxl-rs could do is switch to the main image when it's progressive resolution exceeds the preview resolution

Assuming you mean streamed input and not just chunked encode, per-group downsampling should work, since it's not defined anywhere and it should only be a preview anyway

10000 iterations of -e 5 compression at -d 1 In between decoded it with 16 bit per sample, and brought it back down to 8-bit per pixel with imagemagicks -depth option He's apparently trying to escape, can't blame him. -# (and yes, it do by one of my own drawings)

interesting, I wonder why the top survived but the bottom didn't

I'm not sure sure either, but the bottom part did got stronger variance in chroma sooner than the top part- Thing is, the background down there is basically as calm as on the top, but over iterations the artifacts spread-

Iteration 6561

the new web

Hmmm... I wonder if boosting the blue channel would also help generation loss. It's definitely noticeable in the last image

You mean like saturating the blue channel a bit more?

I mean increasing the accuracy of it during the encode. It's why the chroma error is almost entirely yellow and blue

ahhh. I'd not know how to do that, lol

Unfortunately if we could do it easily, we already would have

I know- I mostly wonder if there was a way to circumvent the spread. But hey, non of this shows up at 10k iteration using `-e 7` At least not in this image. There was another one that did develop such black and white waves earlier- at 1000 iterations- but I need to find an alternative image so I could share.

Huh, interesting. I can't think of anything specific that would make e7 any better

You mean why e7 would perform better?

Do you have pics for all iterations? You can use ffmpeg to glue them into a video

I do not as of now- I'd want to make my script more asynchronous or use a thread to store the images- as right now it is kinda slowest part of the whole thing- How ever, I do export images in (I think) logarithmic intervals- currently 3^x, so `[1, 3, 9, 27, 81, 243, 729, 2187, 6561]` I probably want to do a clip with 1.5 as a base. Right now, I'm doing tho another run to 10k, using e1 and --gaborish=1; Holds up very well so far- But I assume that is because there is nothing that changes in-between iterations. Okay, between iteration 3 and 729 are changes, but between 729 and 2187 there are none. Gonna do an e5 run with base 1.5 now and stich it together-

I know generation loss used to be a lot better years ago, but I can't remember if it was just Gaborish that regressed or the lossy quality itself

I mean Gaborish seems to not make it worse- e1 does not seem to use it, iIrk, but I turned it on and it stood steady there. So probably is something else. I mean, I can test e5 and force Gaborish off later and see how it differs.

Yeah, Gaborish forced off did do something- Both at the same iteration of 7481- First is encoder chooses (default), second is Gaborish forced to off-. Does the encoder choose to enable and disable Gaborish per 'Tile' / 'Chunk' / Area? Or is it still a hard on off for the whole image, when the encoder chooses?

gaborish should be per whole image AFAIK

weird that it makes that area so much worse, I wonder what is about that area specifically that makes the encoder stumble

I know that in the other image, which I can not share completely, the encoder stumbled over a 2.5-3 pix thick line with some soft sharpening applied to it- Which it seems to amplify again and again. -# I gotta touch some grass for a second

Gaborish is on for lossy above distance 0.5, so usually always

Well that isn't good... Just had cjxl make a file that fails to decode on main

it's a thing

worse, it can produce out-of-spec files

(for some definition 'worse')

Not exactly a common use case, but strange it fails regardless https://github.com/libjxl/libjxl/issues/4653

it is invalid?

Fails to decode in libjxl, jxl-rs and Oxide

😭

https://tenor.com/view/bro-hell-sus-gif-4640953859587921843

of course i manage to get the library to crash lol, trying to save downscaled thumbnails to disk for an image viewer im making, though it works just fine when i disable downscaling the image lol

apparently my app was getting the jxl functions i used from the FreeImageRe dll lmao, no wonder why it didn't want to step into it for debugging lol, but it didn't fix that crash

ok i got it lol, i never updated the frame_size argument i had for the size of the frame after downscaling lol

is that JPEG XL with a hyphen in your profile <:CatBlobPolice:805388337862279198>

oops i guess i never changed that lol

I can't find the code, but are you using the built-in 1:8 downsample in libjxl too? (though it tends to only work for lossy)

if it's not the default, then probably not, i took the code from the encode_oneshot example and modified it for my use case, disabled multithreading, as it's called from a multi threaded thumbnail generator, and set effort of 6 and distance of 3 for now

not sure how jxl's downsampling works though

Ohh right, you're making thumbnails *as* JXLs, not thumbnails *of* JXLs

yeah

i imagined using lossy jxl here would be a good use case for it

tiny file size, great quality, and hopefully fast enough encode and decode time, haven't set up loading them back yet still lol plus if i feel like it later on, i may experiment with animated thumbnails, so i can use animation in jxl too

though alpha is messed up here in my thumbnails still, it's like 1 bit alpha or something

i know nothing about openexr, is decoding this file expected to fail using the `exr_to_pq` tool from libjxl? ```sh $ ./exr_to_pq.exe --luminance 'white=203' screenshot.exr screenshot.png JPEGXL_TOOLS_CHECK: jxl::extras::DecodeBytes(jxl::Bytes(input_bytes), jxl::extras::ColorHints(), &ppf) ``` ```sh $ file screenshot.exr screenshot.exr: OpenEXR image data, version 2, storage: scanline, compression: piz, dataWindow: (0 0)-(1919 1079), displayWindow: (0 0)-(1919 1079), lineOrder: increasing y ```

imagemagick can convert it so the file isn't broken at least

```sh $ cjxl screenshot.exr screenshot.jxl JPEG XL encoder v0.11.1 0.11.1-4 [AVX2,SSE4,SSE2] Encoding [VarDCT, d1.000, effort: 7] Compressed to 343.9 kB (1.327 bpp). 1920 x 1080, 4.457 MP/s [4.46, 4.46], , 1 reps, 12 threads. ``` ```sh $ ./cjxl screenshot.exr screenshot.jxl JPEG XL encoder v0.11.2 332feb1 [AVX2,SSE2] Getting pixel data failed. ``` seems to be a dependency issue with the windows build from github? guess that should say i'm missing a dll or that it's built without exr support instead of just failing with a generic error

i noticed there isn't `cjpegli.exe` build on `<https://artifacts.lucaversari.it/libjxl/libjxl/latest/jxl-x64-windows-static.zip>`

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

This is likely due to <https://github.com/libjxl/libjxl/pull/4657>. See also: https://discord.com/channels/794206087879852103/805176455658733570/1481390243939745874.

hey i need some help, i am writting a proposal for GSOC "Adding JPEG XL import support in libreoffice" i am not an expert but i wanna know more and learn hooping to find someone who will mentor me

Was the separate repo updated with changes from this? I heard there was desync issue

I think so, but PRs still aren't merged

Hmm, seems like something might've broken with the butteraugli AQ? Filesize went up massively while visual quality got much worse https://github.com/libjxl/libjxl/issues/4689#issuecomment-4137194862

I noticed the same with all screenshot content

Effort >7 is not recommended for lossy

It's been bad as long as I can remember