JPEG XL

It was originally introduced in server processors and it does not have a benefit unless your scheduler is the bottleneck.

So unless you are actually starved for available CPU threads, you are lowering your core performance.

It makes sense to me because you cannot get anything for free. 1 core is still 1 core.

It's a tradeoff that only makes sense in a very specific scenario

And yet it's 30% faster https://discord.com/channels/794206087879852103/804324493420920833/1417402872093605948

Is it still possible to see the release of v0.12 this year?

I hope it releases this year

unequivocally false - having SMT enabled it at most a minute drop in performance in wast majority of workloads unless you're having another thread using the same core. And even then, you're commonly gaining overall system performance with it, it only makes sense to disable when you have programs that can and do utilize most of the cores resources - which essentially is only HPC. Otherwise, having SMT off only helps if you're single-thread bottlenecked and you don't want said thread to compete with some other thread with core's resources - but that's not what's happening with JXL, because you wouldn't see much of a performance uplift with extra cores if that was the case

Depends. There's a lot of pending things, including a spec change that needs to be resolved, and quite a few tests I need to run before making PRs to squeeze in

That last statement might not be true for djxl as we found out, but certainly still holds for cjxl. Perhaps since decoding is already so optimized, there's no spare instructions for the second thread in the core while the encoding is much more dynamic and branching

I would be surprised if it's not still faster with 8 threads and SMT disabled in the BIOS.

Like I said, I only get a small boost when going from 12 to 13 threads on my 12 core SMT2 machine, and going from 13 to 14 threads yields no benefit at all.

And the energy use of the CPU actually seems to go DOWN when I keep adding more threads.

My CPU is drawing LESS power, which indicates that it's tapping into LESS available hardware resources.

It gets the hottest when I am using only 12 threads.

This is just my personal experience so far.

And it makes sense to me.

I don't expect SMT to be magic

The CPU only has 12 physical cores.

It's just a hardware scheduler.

Decoding fits the template of "math heavy code with little branching" so I would agree that it probably doesn't gain much from SMT. But I doubt it loses much either

CPU time doubled, but user time stayed the same. Probably because more threads *were* in 'use', but SMT had to wait for the main cores anyway so half the registered CPU time was just idling

Do you mean "wall time" instead of "user time?"

Yes

Even with 24GB of memory I still can't encode a 64000x64000 image in jpeg xl <:PepeSad:815718285877444619>

*For encoding in jpeg cjpeg (mozjpeg) I use the "-revert" flag, encoding uses two megabytes of memory*

Windows.

4 Gigapixels.... How much memory does that use to load?

to open and show 12 gb

Screenshot.

Windows.

Windows user saying something about ram usage..

Ragebait trolling

🤣

yeah, libjxl and jxl-oxide memory optimization isn't quite there for decoding sadly.

<:FeelsSadMan:808221433243107338>

jxl-rs will save <:Stonks:806137886726553651>

i wait [PepeHappy](https://cdn.discordapp.com/emojis/654081052012314643.webp?size=48&name=PepeHappy)

How's jxl-rs looking for object size?

no clue, but also not super relevant for now 😛

Does anyone know of a source for Float16 and Float32 JXL images? I looked through the conformance repository and didn't see any.

I was converting to PFM and then encoding myself, or exporting from Krita using Blender renders/EXR test files

Also, this may be noteworthy https://github.com/libjxl/libjxl/issues/3881

I managed to create Float16 and Float32 documents by creating new documents in Krita.

All of my tests with existing JXL HDR images were being saved as 16-bit integer, even though Krita was loading the documents as 32-bit float. No idea why Krita was doing that, but I found the behavior confusing.

I assume the images were lossy? Krita always loads lossy JXLs as 32-bit float since that's the internal VarDCT representation, the original bitdepth (16-bit int) is purely metadata. Lossless maintains the original bitdepth

Yes they were lossy. Is that just a performance optimization on Krita's part or are there other advantages over asking libjxl to output an integer format?

Could ask <@274048677851430913>, I always assumed it's because float is more accurate even when the original file is int. IIRC creating a canvas first will have libjxl decode to the current format instead

iirc Krita always load any HDR images to linear F32, whether it's JXL, PNG, or AVIF

That does raise a point though, <@794205442175402004> shouldn't there be conformance and regression tests for floats? Could even have one of half stored in full, such as converted .HDR files

https://github.com/libjxl/conformance/tree/master/testcases/lossless_pfm

That one is supposed to test lossless float32

I missed that in the readme. Out of curiosity, what are the sourcetree files? The testcases/blendmodes/sourcetree file looks like it is used to generate the matching test image, but I didn't see any code that uses that file.

It's <#824000991891554375>, handmade MA trees using the lossless mode of JXL for ultra small images. You can try them here https://jxl-art.lucaversari.it/

uint32_t bits_per_sample; < what you call a sample is a triplet RGB, or is it considered 3 samples?

Sample is per channel, combined is per pixel (I think)

Thanks 🙂

In RGB, every pixel consists of three samples. In grayscale there's just one sample per pixel, in CMYK there are four.

How do I give a float32 buffer so that it is losslessly compressed as if it was 16bits precision?

because in c++ there's no float16 type (yet)

just changing JxlDataType to JXL_TYPE_FLOAT16 doesn't seem to be enough

afaik once compressed, everything is stored as float32 anyway, so, I just want djxl to read my jxl as a 16bits image

Do I need to manually feed actual 16bit float? or should I convert to 16bits by multiplying by 65535 on the fly and casting to uint16_t?

Lossy VarDCT is always float32, but lossless stores the original bit depth. Not sure how best to do it though

either would work, but with different results

Ah, so lossless does care about bit depth then, that makes sense... wouldn't be lossless otherwise. I'll convert it to 16bits then and we'll see ! My data is normalized [0,1], so I assume it'd make more sense to use uint16_t since I'd keep more precision than with float16 [0,1]

depends on your exact data (f16 has higher precision for very small values), but for sensor data, I would expect integers to be perfectly fine (the data from the sensor is likely uniformly quantized itself, and too noisy to warrant the small-value precision anyway)

I did try to see if any cameras output float, but apparently not

I doubt there would be much of a point

No but it's the result of a stacking of many camera raws x)

So it's quite a lot more precise than 16bits

(but I need 16b output)

I was thinking of a theoretical world going from the analogue sensor values to float values above 1, to basically remove over and under exposure. But anyway

Anyway, I succeeded in making the float becoming uint16_t on the fly, it works, but it doesn't behave at at all like the lossy one on decompress

Lossy would've been decoding to the requested format and color space, lossless will be whatever profile it was encoded with, so it could be a viewer issue

It's the android libjxl port that was fine decoding the lossy as float16, but now that I do lossless, it's complaining it's not 16bits There's something wrong with either GIMP's plug-in, or my export parameters/flags I think: I made the test, I created a JXL file from my buffer (float32 [0,1] then stretched to 16bits). When opening it in gimp, I got some bad quality artifacts like it had less bins to go with ( as shown by the histogram ). But then I converted the jxl to a tif, so 16bits to 16bits, I also dumped the value representation, and they are nearly identical.

JXL

TIFF

Note that the tiff is created using the jxl (I decompress it with libjxl, then export a tif)

Is it a problem of specifying linear vs perceptual ? Is that what you mean <@238552565619359744>

Indeed, that's it. I have the exact same histogram as the TIF when using `JxlColorEncodingSetToSRGB` vs using `JxlColorEncodingSetToLinearSRGB` -> why does it matter for lossless? also the filesize has reduced quite a bit... from 122MB to 95MB

(good news for me hehe)

you can do some integer tricks

the representation of fp32 is quite similar to fp16

you just need to cut some part

https://tenor.com/view/monster-naoki-urasawa-kenzo-tenma-surgery-gif-6268996817967018326

(edge case: some normal f32 become denormals as f16)

(all f16 denormals are normal as f32)

(and all f32 denormals round to 0 as f16)

useful website: https://float.exposed/

Nice !

Is there any performance impact with respect to using linear sRGB or plain sRGB?

for lossless? not as far as libjxl is concerned

Yes for lossless 🙂 Thanks for your answer

But then why is the filesize smaller?

I’m not sure at all – is it really the only change, and the compression 100% confirmed to be lossless?

maybe <@794205442175402004> might have an idea?

are you talking about same sample data, different color space tag? or sample data converted to different color space before encoding it losslessly?

More info above

Yes but I still don't understand what the workflow is here. What's the original data and how is it getting encoded?

https://drive.google.com/drive/folders/11xCyipF-Dx1BGXKKec6Ye8Xr5LQiEiSY?usp=sharing Image in 16bits covering 0-65535 -> compress losslessly (distance 0 + `JxlEncoderSetFrameLossless`) When using `JxlColorEncodingSetToLinearSRGB` -> 122MB When using `JxlColorEncodingSetToSRGB`-> 95MB The input data is the exact same binary uint16_t

Using streaming encoding: chunking and outputprocessor

that is weird, it should not make more than 1 byte or so difference (just the header should be different)

I was very surprised as well, so I'm wondering if I'm doing something wrong somehow

and both are actually lossless?

well, almost, compared to my tiff output there are very minor differences

there should not be any difference at all if it's lossless

I thought the same and yet here we are ...

I thought that for lossless, distance 0 + setFrameLossless were enough, but maybe there's more ?

``` $ compare -verbose -metric pae Original_stack.png converted_sRGB.jxl null: Found a generic profile, type exif Original_stack.png PNG 6643x7526 6643x7526+0+0 16-bit TrueColor sRGB 102.625MiB 0.830u 0:00.841 converted_sRGB.jxl JXL 6643x7526 6643x7526+0+0 16-bit sRGB 91.1145MiB 2.830u 0:00.442 Image: Original_stack.png Channel distortion: PAE red: 12 (0.000183108) green: 7 (0.000106813) blue: 45 (0.000686656) all: 45 (0.000686656) Original_stack.png=> PNG 6643x7526 16-bit sRGB 102.625MiB 8.230u 0:01.152 ```

``` $ compare -verbose -metric pae Original_stack.png converted_linear_sRGB.jxl null: Found a generic profile, type exif Original_stack.png PNG 6643x7526 6643x7526+0+0 16-bit TrueColor sRGB 102.625MiB 0.840u 0:00.839 converted_linear_sRGB.jxl JXL 6643x7526 6643x7526+0+0 16-bit RGB 116.902MiB 3.050u 0:01.043 Image: Original_stack.png Channel distortion: PAE red: 18 (0.000274662) green: 10 (0.00015259) blue: 63 (0.000961318) all: 63 (0.000961318) Original_stack.png=> PNG 6643x7526 16-bit sRGB 102.625MiB 8.070u 0:00.978 ```

``` bash-3.2$ cjxl Original_stack.png converted-cjxl.jxl -d 0 JPEG XL encoder v0.11.1 0.11.1 [NEON] Encoding [Modular, lossless, effort: 7] Compressed to 72892.0 kB including container (11.664 bpp). 6643 x 7526, 6.387 MP/s [6.39, 6.39], , 1 reps, 12 threads. bash-3.2$ compare -verbose -metric pae Original_stack.png converted-cjxl.jxl null: Found a generic profile, type exif Original_stack.png PNG 6643x7526 6643x7526+0+0 16-bit TrueColor sRGB 102.625MiB 0.830u 0:00.828 converted-cjxl.jxl JXL 6643x7526 6643x7526+0+0 16-bit sRGB 69.5153MiB 8.610u 0:00.908 Image: Original_stack.png Channel distortion: PAE red: 0 (0) green: 0 (0) blue: 0 (0) all: 0 (0) Original_stack.png=> PNG 6643x7526 16-bit sRGB 102.625MiB 8.350u 0:01.013 ```

``` $ jxlinfo converted_sRGB.jxl JPEG XL image, 6643x7526, lossy, 16-bit RGB intensity_target: 64000.000000 nits min_nits: 0.000000 relative_to_max_display: 0 linear_below: 0.000000 Color space: RGB, D65, sRGB primaries, sRGB transfer function, rendering intent: Relative ```

It's considered lossy ?

I'm not sure I understand why

probably using XYB

I never set XYB though

you have to set `uses_original_profile` to true when setting the BasicInfo

otherwise the image will be converted to XYB

I need to do that only for lossless I suppose

yes

IIRC doesn't it throw an error now if you try to do lossless XYB?

that would probably be a useful thing to do

Woow, just activating this line gives me this: `lBasicInfo.uses_original_profile = JXL_TRUE;`

Very nice 😄

that doesn't look right

indeed x)

as float 16 that's what I get

but as uint16 I get what's expected and I also get smaller file even

and jxlinfo says (possibly) lossless

looks like something is broken, can you open a github issue with how you got to that glitchy image? could be some combination of settings that causes chunked encode to break

sure, I will try to do that next week as I need to wrap things up for today

Thanks for your help ! very nice to gain a few MB

Ah, I was thinking of this https://github.com/libjxl/libjxl/pull/4238, but it only sets `JxlEncoderSetFrameLossless` when distance is set to 0, not `uses_original_profile `

Almost looks like a decoder issue, some of the groups are overlapping or completely off-grid

I would be surprised if it's a decoder issue, to me it looks like an encode-side buffer management/lifetime issue that could be either caused by inappropriate API usage or some bug in libjxl. This kind of thing is what you get if a buffer is overwritten while it is getting consumed.

Very strong guess, when setting the runner to 1 thread this issue disappears.

during encoding or decoding?

Encoding. Because I was setting a buffer in getColorChannelDataAt (the callback) that corresponds to the desired area, converting on the fly my float32 to float16 so that I don't need an entire copy of my image But this buffer isn't thread-safe, and there is no notion of thread id in getColorChannelDataAt

So right now I just new[] something inside this function, I will benchmark whether using some more sophisticated memory management makes sense.

Apple dev and AOM head is having some trouble, think they might be mixing up streamed and chunked encoding, but I don't want to give them incorrect info https://github.com/libjxl/libjxl/issues/4459

Hi, I'm analyzing the code of CfL and this line is very suspicious for me: https://github.com/libjxl/libjxl/blob/2a4f12b6ef22672e0f4a399df3b8589856ebace2/lib/jxl/enc_frame.cc#L1012 Effectively on JPEG DCT coefs here quantization table is applied in transposed form, while the coefficients themselves are not transposed. Is it some clever trick or just misprint?

Even more suspicious this line makes the fact that earlier to find CfL coefficient https://github.com/libjxl/libjxl/blob/2a4f12b6ef22672e0f4a399df3b8589856ebace2/lib/jxl/enc_frame.cc#L884 this quantization table is applied in non-transposed form

It is very well possible that there is some bug in there — though jpegs do roundtrip, so I'm not sure if it's possible that there's something as bad as incorrect coefficient order is going on

IIRC isn't CFL a JXL only decode feature? So the roundtrip shouldn't be effected. I do recall disabling CFL was better in our tests a long time ago, maybe that's why

no, the point of cfl is to change the quantized dct coefficients that are actually stored, and it can also be applied to recompressed jpegs but only if they're 4:4:4 (cfl is not defined in the subsampled case iirc). I remember we did have to be careful to make sure the original quantized coeffs could still be reconstructed though

something else, looks like we need to update something in the gdk-pixbuf stuff: ``` /Users/jonsneyers/dev/libjxl/plugins/gdk-pixbuf/pixbufloader-jxl.c:85:15: error: 'gdk_pixbuf_animation_iter_get_type' is deprecated [-Werror,-Wdeprecated-declarations] 85 | GDK_TYPE_PIXBUF_ANIMATION_ITER); | ^ /opt/homebrew/include/gdk-pixbuf-2.0/gdk-pixbuf/gdk-pixbuf-animation.h:48:54: note: expanded from macro 'GDK_TYPE_PIXBUF_ANIMATION_ITER' 48 | #define GDK_TYPE_PIXBUF_ANIMATION_ITER (gdk_pixbuf_animation_iter_get_type ()) | ^ ```

libjxl does integer cfl directly on quantized coeffs during reconstruction, to make sure the original coeffs are recovered exactly

I wonder if 18181-2 spec has the pseudocode of integer cfl

Yes, this is indeed a misprint, but earlier: quantization is in transposed form already, https://github.com/libjxl/libjxl/blob/2a4f12b6ef22672e0f4a399df3b8589856ebace2/lib/jxl/enc_frame.cc#L811, so the correct is to use transposed `scaled_qtable` everywhere (on line 884, specifically). It also slightly helps with JPEG compression ratio on files with non-symmetric tables (e.,g. 18559200 -> 18550162), as now correlations are closer to real ones 🙂 I'll prepare an MR to fix

Effectively it appears that correlation coefficients were off, but it does not affect reconstruction as they are stored in the JXL file and allow to reconstruct JPEG again bitcorrect

Made PR https://github.com/libjxl/libjxl/pull/4477

Nice! There are probably more of such minor encoder bugs, stuff that doesn't cause anything to break but that is still suboptimal.

I wonder why non-symmetric quantization tables are used in JPEG, at least for 4:4:4 images (for 4:2:2 images I can understand why)

that is, why treat horizontal signals different from vertical signals? it doesn't really make sense to me, especially considering that often the actual image orientation is modified in Exif

If the tables are fitted to the image, some asymmetry is expected. Also `Table K.1 – Luminance quantization table` from JPEG standard is asymmetric

does any encoder fit quant tables to the image? seems tricky

I know the Annex K tables are asymmetric but I always wondered why

I think as we have eyes placed horizontally, we are more sensitive to horizontal changes: standard tables are less grained along horizontal direction

yeah but if you rotate your camera, the orientation of the encoded image data does not match the actual/rendered image orientation

Wow, CI is failing on skcm https://github.com/libjxl/libjxl/actions/runs/18405468224/job/52449627594?pr=4477

I've experimented a bit: if I use an average between the first and last max bin index for CfL, JPEG compression is even better, that makes sense in view of the statistical modelling applied. Performance is effectively unaffected, so should I prepare a PR for such an improvement?

Or there were some obscure reasons to use the first max bin index?

No, go ahead, just make sure to check if the improvement is consistent across jpegs from various sources

Are there currently any Android apps that can play animated JXL files on mobile devices?

You already asked in <#794206170445119489> and Reddit

oupson's jxlviewer says it explicitly supports animated images as well. just tried on recent android, it works (iinm old android versions may lack the mime for jxl) you can get it from github, google play, and fdroid/izzydroid

however its not a gallery app. with specific images (ie from file manager or another gallery), you can choose to "open with" jxlviewer

https://github.com/oupson/jxlviewer

It does work as a gallery now, with in-app file selection etc.

But it is pretty slow

didnt show all folders for me, only 2 with missing images. no configurable options either

fossify and poc had an issue before that a folder with jxls HAD to have at least one image in another format before the app would show that folder. maybe related

yeah, it was very slow the first time it plays them. But then it suddenly crashes.

Have you turned a video into a JXL?

An APNG to JXL

Done https://github.com/libjxl/libjxl/pull/4480

nice!

I wonder what was/is causing the failing testcase on [#4296](https://github.com/libjxl/libjxl/pull/4296)? apparently the logs for what the conformance tests run expired so they can't be viewed anymore

I dunno, maybe the change caused the synthesized ICC profiles to be different (in the name field only but still) and then the conformance script is applying no-op color conversion from one to the other, which should not change anything but probably lcms2 is still doing something that causes it to not really be a no-op.

I'm not sure what's more surprising to me, someone using effort 11, or someone using effort 11 so much that they noticed a 6 byte regression a few days after a PR https://github.com/libjxl/libjxl/issues/4483

oh, but that’s our very own <@688076786525143117>

Everything must be tested.

Related to [this](https://github.com/libjxl/libjxl/issues/4482) issue (about lossless & gaborish). There is this note in the spec: > NOTE 1 Fully-specified noise generation has the advantage of allowing encoders to compensate for the noise that a decoder will add. The latitude (maximum deviation) between decoders is smaller than the largest magnitude of the generated noise. How is that implemented (if it is) in practice?

It is not, we don't currently have an encoder that will automatically use noise generation. You can manually add noise but it will just be signalled on top of the image as it is, the encoder is not trying to do noise reduction before encoding or anything like that. But we did want to make it fully specified so at least in principle, an encoder can know what the decoded image will look like and if needed compensate for it if the generated noise makes the image look weird in some region or whatever.

Make sense, thanks

<@1346460706345848868> would you be able to investigate this? https://github.com/libjxl/libjxl/pull/4232#issuecomment-2854414759

in the past you had [mentioned](https://github.com/libjxl/libjxl/pull/4154#issuecomment-2815265621) looking into trying to reduce the size

Yes, I unfortunately moved to other things lately. If you are interested, I move it to the next thing to do in priority list

At some point, could we get these pending PRs merged? <https://github.com/google/jpegli/pulls> The repo hasn't had an update in 8 months, with significant bugs present in the current version discouraging adoption by some (Empty DHT, APP14, Static builds)

The drop-in compatible jpegli .dlls aren't compatible. Also, compiling jpegli .dlls are disabled by default on windows for reasons I don't quite understand.

There's a PR which re-enables compiling DLLs, suggesting it worked for them, but all programs either crashed or errored when we tried replacing the DLLs

(Namely Krita, RawTherapee and cjxl)

hello, will there be a new release soon ?

Soon™

thanks

how could this be done? could JXL apply noise generation selectively by creating an empty frame with synthesized noise, creating another frame that works as the mask, and selectively subtract-blending the noise frame with the original image that has noise synthesis applied?

No, generated noise can only statistically look like real noise, it will be different on the pixel level. But an encoder could apply any kind of denoising algorithm on its input and encode that as the image, estimate the amplitude of the noise (comparing original to denoised image) and signal that amount of noise to be generated decode time

ah, then with this noise being luma-modulated (iirc) there's no real way to for example dial back the noise in a certain area to avoid that specific part of the image looking weird?

I assumed applying noise selectively would be theoretically possible by subtracting another noise frame that was multiplied by a mask

well regardless, I'm hopeful for a noise replacing feature in the encoder in the future, that sounds great

You could selectively apply noise by first encoding the image without noise as the first frame, then patch-copy it to a second frame and add noise to it, and then alpha blend them and use the alpha to modulate noise locally. Comes at a cost in decode time to do it like that, but it's an approach that would work in principle.

oh I see

But the encoder already inadvertently denoises the image as an unintended result of the quantization. Maybe the encoder should measure how much noise was removed and try to add it back with noise synth. Without changing the encoding process at all aside from the measurement step afterwards

AKA, fix `--noise 1`

Yes, that would be a good start.

Yes. And it can even be applied conveniently to existing images. Just compare the original with the lossy and measure the amount of noise that was lost. Then it can be added with a simple metadata change.

The question is: what's the best way to measure the noise?

I'm sure there must be literature on that, but just subtracting one from the other and computing some stats on the residuals should already be reasonable. Maybe median amplitude of residuals?

Isn't it this? <https://github.com/libjxl/libjxl/blob/4523cf652f568f1fbb57bf9a10ae3caae785cd9f/lib/jxl/enc_noise.cc#L271>

Or does that just take a guess instead of checking the difference to the encoded result

it takes only one image as input so I assume it is trying to estimate the noise in the input

I wrote a tool that takes a source image and a denoised image and estimates the `--photon_noise` parameter to use, but it really only estimates noise LUTs of the photon kind

ah, right, and I’m not sure I was done recalibrating the photon noise scaling to match the one in libaom

So recalibration and then integration into libjxl?

I don’t know how deeply it would make sense to integrate it; I had it as a separate command-line tool

`$ tools/estimate_noise ref.png denoised.png` and it tells you what it thinks is the most suitable photon noise parameter

which you have to copy and apply yourself

I thought I'd make sense to replace the code I linked above, though if the image has already been encoded, it might be useful to do <https://github.com/libjxl/libjxl/issues/4328> first for setting the noise after

speaking of photon noise, this is kinda an annoying bug: https://github.com/libjxl/libjxl/issues/4368

**Call for jxl-rs testing :-)** Hi everyone, jxl-rs has reached a point where the current `main` branch decodes all the jxl files that we are aware of, but there are always files we are not aware of! We would be grateful if you could download jxl-rs, run it on a bunch of images, and open issues for those images that *do not decode correctly* (or don't decode at all) In the meantime, we'll continue speeding things up 🙂

probably better also in <#803379415106584626>

I certainly have a knack for making exotic files, so I'll see what I can ~~break~~ do

speaking of, what's the status of tone mapping in jxl-rs? it's the only thing not formally marked off of the stages tracking bug and the person who was assigned to do it seemingly never came back? https://github.com/libjxl/jxl-rs/issues/58

I don't think it's implemented

If I wanted to automatically test it on a large number of images, what would be the best method? Checking PAE against what libjxl produces?

should work

Seems to have problems decoding JXL art

At least the ones I've tested

Yeah, something simple like that. And then, what's the best way to translate the median amplitude into an ISO value?

Well, I'm sure that's the easy part

Anyways, it's a good quick and dirty hack that could give a small but meaningful little bump to perceived fidelity. Like a low hanging fruit.

~~time to add image-rs support~~

that would be really nice for testing lik

lol

Yeah. Integration is king

Maybe even a libjxl C api translation layer

For all the existing libjxl support

It's good/bad timing, because I've been speaking with a GitHub developer about allowing JXL uploads for libjxl as a trial run. Would be nice if we could skip renaming them to `.jpg`, but I'm not sure what progress they made

Does .bin work? Is it really some stupid filename restriction?

They use whitelisted extensions, not even mime types. So renaming JXL to JPG still loads fine in supported browsers You can see it on the jxl-rs issues we made <https://github.com/libjxl/jxl-rs/issues/422>

For lossy JXLs (modular and VarDCT), I'm getting different pixel values from djxl (v0.11.1) and jxl_cli (main). PAE is consistently `257 (0.00392157)` for 8-bit images, less for higher bit depths. Is there any deviation allowed, or should it always be `0 (0)`?

257 is just an off-by-one in 8-bit, which is allowed and can be caused by several things, including float arithmetic differences between implementations, dithering being done differently, etc.

jxl-rs has no dithering currently IIRC while libjxl v0.11 had 8x8 bayer, now using blue noise in v0.12

I've also found a couple that don't decode with jxl-rs. Will raise bugs soon.

That's probably something we should fix 🙂

ppm output doesn't seem to work

It seems to write an empty ppm if the image has alpha

Looks like they're waiting on my jpegli PRs, and v0.12 of libjxl https://newsgroup.xnview.com/viewtopic.php?t=48869

worth reporting. xnview's export of jpeg when using *jpegli* seems to use libjpeg rather than jpegli when you choose **greyscale** (massively lower visual quality for low bpp - blockiness and artifacts match the non-jpegli codec they used before)

Maybe it was this? https://github.com/google/jpegli/pull/103

no visible connection, current and old xnviewmp versions show the same issue when opting to export jpg as **greyscale** instead of 16m color

As in the exact same file, or just poor quality? Because that PR hasn't been in a release and they said they use the libjxl version

> all the jxl files that we are aware of I love the way you phrased that all the jxl files we are aware of. all 113 of them <:KekDog:805390049033191445>

very excited about this landmark. I've got a few weird jxl files to test

the difference in visual quality in export between jpegli and non-jpegli when selecting to output as greyscale seems to result from some mismapped bit attribution (ie for a screenshot, jpegli at 4% is 15kb and non-jpegli 24kb - increasing quality % till 24kb jpegli export is almost exact match in artefacts, blocks. odd for jpegli export to greyscale from a colored input is not supposed to be visually worse than the old jpg codec xnviewmp export used

People have been rebasing jpegli PRs onto the libjxl repo because the Google ones haven't been merged for months. The Google repo is more up to date, so we don't want to accidentally skip commits between the two. I know I've brought it up a few times lately, I just don't want the jpegli fixes to miss the v0.12 release, causing even more issues and PRs to pile up https://github.com/libjxl/libjxl/pull/4504

yeah, this is yet another case of “original PNG had gAMA=0.45455 and no sRGB chunk, so now software that didn’t look at the gAMA tag but does look at the ICC profile renders the image correctly”

```console $ pngcheck -v original.png File: original.png (5973 bytes) chunk IHDR at offset 0x0000c, length 13 140 x 64 image, 32-bit RGB+alpha, non-interlaced chunk gAMA at offset 0x00025, length 4: 0.45455 <---- chunk pHYs at offset 0x00035, length 9: 3777x3777 pixels/meter (96 dpi) chunk IDAT at offset 0x0004a, length 5879 zlib: deflated, 32K window, fast compression chunk IEND at offset 0x0174d, length 0 No errors detected in a.png (5 chunks, 83.3% compression). $ pngcheck -v decoded.png File: decoded.png (7331 bytes) chunk IHDR at offset 0x0000c, length 13 140 x 64 image, 32-bit RGB+alpha, non-interlaced chunk gAMA at offset 0x00025, length 4: 0.45455 chunk iCCP at offset 0x00035, length 314 profile name = 1, compression method = 0 (deflate) compressed profile = 311 bytes chunk cHRM at offset 0x0017b, length 32 White x = 0.3127 y = 0.329, Red x = 0.64 y = 0.33001 Green x = 0.3 y = 0.6, Blue x = 0.15 y = 0.06 chunk IDAT at offset 0x001a7, length 6888 zlib: deflated, 32K window, superfast compression chunk IEND at offset 0x01c9b, length 0 $ magick decoded.png decoded.icc $ cd-iccdump decoded.icc icc: […] Text: en_US: RGB_D65_SRG_Rel_g0.45455 [100 bytes] ```

ugh it's annoying that so much software gets it wrong that getting it right makes it look like we're wrong.

I see so according to you they actually didn't take into account the gAMA that basically says it's sRGB and with the added ICC profile they do render it as such. On the other hand i'm already an "advanced" end user for windows and i don't have any software that render those correctly. Yeah i suppose it can be a frustrating problem.

those gamma22 vs. sRGB issues are really... something

I was planning to build a bunch of old libjxl versions to see if any differences in the output would trip up jxl-rs, but it seems like some of the older dependencies can't be compiled anymore? What a pain.

the gAMA (or more specifically the absence of an `sRGB` chunk) says it’s _not_ sRGB, but probably a lot of software assumes it is

sRGB is such a nightmare. Why can't we just retire it T.T

but 2.2 gamma is the real definition of sRGB (any other definition you may have heard is fake) so assuming that gAMA=0.45455 is sRGB is fine 😄

SRGB never actually defined it, it only hinted it

Ofc I agree that 2.2 is how it should be, but it can be reasonably thought to not be, especially with all the "sRGB pseudo specs" so to speak

So the difference is actually due to chrome's approximation when sRGB is assumed and when it is actually declared <:galaxybrain:821831336372338729>

uhm any spec of sRGB has that silly linear segment, I am sorry

yeah but it was just an encoding trick. Microsoft and HP assumed that the average CRT monitor would have a pure 2.2 gamma, and the silly linear segment plus gamma 2.4 segment was chosen to be an as close an approximation of that as possible, while supposedly making the math easier on some systems.

Yeah it was basically an approximation to make intermediate linear uint16 work, and then that became spec even when there's no real need anymore to avoid float arithmetic.

didn't a reference number of 2.2 come from an average of desktop CRTs iirc I remember reading that

yeah

but yeah, sRGB was designed to work well on rec709 CRTs, the linear bits was done since 8bit pipelines simply didn't well work at that level without it

I got you, currently encoding: (0.3.7) -d !0,1,15 -s !3,5,7,9 (0.5.0) -d !0,1,15 -e !3,5,7,9 (0.6.1) -d !0,1,25 -e !1,3,5,7,9 (0.7.0) -d !0,1,25 -e !1,3,5,7,9 (0.8.2) -d !0,1,25 -e !1,3,5,7,9 (0.9.0) -d !0,1,25 -e !1,3,5,7,9 (0.11.0) -d !0,1,25 -e !1,3,5,7,10

Someone want to guide me in automatically detecting discrepancies between the PNG decodes?

`compare -verbose -metric pae one.png two.png null:` ? Assuming they're in the same colorspace, since that command doesn't do any color management

Thanks, yeah, I had no intuition for a threshold, but realized I could just sort on error and visually inspect the worst.

what about comparing the hashes once the image is decoded with `ffmpeg -v warning -i input.png -f hash -` ?

Thanks, if you expect it's sensitive enough I might try it. Anyway, I already compared many images and only saw one obvious but common issue at very high distance.

well that ffmpeg command can only be used to compare hashes, so it is either completely lossless, or lossy (but you can't know how much)

Ah, looks like SHA256, not in line with this use case.

wdym, you would like another hash?

or you would like to get a error-distance between 2 files (like the command from wb)

I am comparing decodes between two softwares. There is flexibility in the result, so I should detect differences of some significance.

I mainly didn't know a threshold to target, but instead of figuring that out I just sorted on error and verified visually.

I'm aware of hashes which are suitable for measuring error, but not aware of a really precise one off the top of my head and didn't consider a benefit worth investigating.

ohh right, mb I thought you just wanted to know the boolean "Is it lossless"

We fixed the DCT visualizations on Windows. PR just opened. <:Stonks:806137886726553651>

<@794205442175402004> I don't suppose you could merge it? https://github.com/libjxl/libjxl/pull/4509

I clicked the button

Thanks

you need to be a trained merge conflict resolution associate to press that button

what do you mean with "on grey background"? is this an image with alpha?

yep

hm, interesting, I hadn't thought about the interaction between alpha and dithering

added the background to emphasize the dither in the lower gradient. but the colors in the opaque parts are very flat too, compared to the jxl-rs result.

jxl-rs doesn't do any dithering at all atm or what does it do?

when did we add dithering? in 0.8 there's no dithering yet, right?

is this with premultiplied alpha or regular PNG-style alpha?

I would expect this to be more of an issue with premultiplied/associated alpha than with unassociated...

I don't quite understand what information is in the alpha and what is in the grayscale image, is the upper part fully opaque and only the region at the bottom-left is transparent, with a gradient in the alpha channel for that black shadow?

These images look like they're 6-bit instead of 8-bit, the step size between color bands in the 0.8 image is more like 4 units in 8-bit than like 1 unit; same with the dithering in 0.10 and 0.12

so there's something I'm missing here, I don't understand how it can look like that

you didn't decode to 8-bit linear and then converted to sRGB or something like that, did you?

no dithering

Then 0.8 and jxl-rs should be more similar, no?

that seems like a valid point

Man, blue noise dithering looks soo better than ordered.

oh is 0.12 blue noise dithered?

I didn't even recognize it as dithering

looks better indeed

That's the idea! 😄

how does it actually decide when to dither? does it keep track of the input bit depth so that it doesn't dither on output if it's 8 -> 8 bit, but does if it's 12 -> 8 bit or something?

oh I'm dumb I assume the application embedding libjxl can just request dithering if the image output bit depth is higher than what it wants to display

FWIW with VarDCT you could always just dither anyways, I don't think it's particularly wrong

I don't know where the error is if there is one. Attached are the default decodes to PNG from each decoder. For the comparison visual I did naively convert to GIMP's Linear sRGB on import, not noticing any difference.

fair point. it can be a bit tedious when comparing the compression quality of different formats and the JXL is dithered unlike all the other ones. in an ideal world image viewers try to display the image's original bit depth and the GPU dithers it on a display pixel level instead of an image pixel level, but for whatever reason we're not there yet

I don't see how would you dither accurately on a display pixel level? Unless you mean feeding the GPU the 32 bit raws or whatever, scaling, and only then dithering

That is what is meant, yes

Doesn't need to be 32-bit, if it's just 2 bits more precision than the display itself, that's already enough to make a difference.

yes, ideally you'd be able to send a framebuffer of any commonly supported bit depth to the GPU and it works with the display driver+firmware to either do *screen pixel level* spatial dithering (in principle similar to the way libjxl dithers), or temporal dithering (where the display changes the color of a pixel thousands of times per second so you see the average of those, a value which the hardware could not natively be signaled to display)

but I don't know enough about this to know what the blockers are to get something like this generally working for every computer in practice

temporal dithering is being done by displays already to get a bit more color accuracy, but that has a limited bitdepth and people sometimes complain about the flashing because in the end you can't do it *that* fast

temporal dithering is how cheap 8-bit displays work, they are actually 6-bit with temporal dithering to pretend to be 8-bit, iirc

that's right. I haven't heard of cases where people can see temporal dithering - to me it seems more likely that you'd see the pulse-width modulation, which is the rapidly flashing of the entire display to change brightness, instead of *actually* changing the brightness, but I believe it

the problem is that generating randomness for each pixel each frame is kinda hard to do in display, so the randomness might be shared over larger areas

ohh I see

also, this is a good graph on what frequencies can result on visible flicker depending on intensity change and frequency

2KHz is basically safe, but you can't really push LCDs to that kind of speed and self-emissive displays usually build color depth off PWM anyways

what does the ripple axis mean?

oh that's the risk lmao

I cannot reason today

ripple = difference between peeks and valleys of signal

this is a standard for electrical engineers lol, ripple is a very well understood metric

For lossy, it's always float 32 so always dithered unless output as float 32. For lossless, it dithers when requested bitdepth is lower than stored bitdepth. libjxl dithers by default but can be told not to (I think)

that's odd. I know it's all float 32 but that's not the behavior I would have expected

though yeah it's lossy regardless so it's fair I suppose

ah okay. then for temporal dithering that should be very low risk regardless since you'd probably be switching between two neighboring pixel values

between two 8 bit values - if you got a 8 bit native panel then 30Hz is a safe zone, but for 6 bit native panels you want to push it quite a bit further

oh, and also, need to take gamma into account, forgot that myself

I just remembered Firefox will dither high bit depth images for you but also on an image pixel level, which is a shame because it very directly controls the frame buffer it's sending to the GPU. you wouldn't even need GPU support, it could just, do that. I think

Oh, and in dark scenes, temporal dithering won't work well without higher refresh rates - the difference between the neighboring values is bigger in relative %

the dither actually makes it less lossy :D if only by a small amount

oh, interesting

you'd think that simply rounding every high bit depth pixel to the nearest natively supported pixel is by definition the least lossy?

numerically speaking

that can cause the average over a region to drift in a particular direction

dither ensures that the average over a region stays closer to the high bit depth average

ah, that makes sense. neat

I know that at least NVIDIA GPUs do support this “send high bit-depth framebuffer; dither to monitor’s actual bit depth”

there are settings for that in nvidia-xsettings

apparently, it’s harder to enable on Windows https://www.nvidia.com/en-us/geforce/forums/game-ready-drivers/13/277754/dithering-option-in-nvidia-control-panel/

> There is a dithering option on Linux. Why you can't do this on Windows, the most popular operating system? I'm begging you, Nvidia, please, do this for us.

https://github.com/SLStyler/Dithering-for-Windows-Simple-BAT-/blob/main/Dither.bat I don’t know what reaction to have to someone writing this as a BAT

ah, it invokes a PowerShell

and VBScript

on intel iGPUs it looks like you might be able to do it by writing a register using an intel program which I did manage to install, but it doesn't work for a lot of people

someone pointed to a 1700 page manual pdf

links to forum posts that 404

I'll check this out in more detail later, I'm too sleepy for this

This kind of thing is the responsibility of the window manager/compositor to properly set up

oh hmm

I might ask the cosmic-comp people about this. currently there are no color management settings in the settings app, so I doubt it's implemented well in the compositor yet

though hdr and night light functionality are planned, I bet those require similar base features to get working

if proper hdr with color management is planned then yeah, that's most of the base features needed

their wallpaper thing supports jxl though so they score some points with that :)

I'm just wondering now, whether automatically dithering if bit-depth is higher than can be displayed is the correct move? Especially on lower res displays it can be kinda noticable

color banding is noticeable too, so either way you're going to have artifacts. since you're going to have artifacts anyway, I'd argue dithering would be better since it's visually closer to the intended image

dang I thought I was onto something when I found this command but it doesn't list bit depth at all

I'm sure we could tune the dither a bit more too. It seems like some areas are both too light and too dark in the comparison above, so maybe a tighter range would help

ssimu2 is as confused as I am, djxl output post 0.6 gets -100 scores

why does jxl-rs and libjxl 0.6 look nicer?

I wonder what changed

there is an infamous issue where older versions of cjxl produced nicer output in certain conditions and people have been trying to adjust the tuning in recent versions to get quality back

https://discord.com/channels/794206087879852103/1278292301038227489

this is the same cjxl/.jxl, though; only the decoder is changing

oh! that's surprising. my bad

jxl-rs, the most recently developed one, does a really nice job too

everyone's been cooking 💚

this image kinda points at me not really believing in small PRs, doesn't it xD

I was actually originally going to write "veluca has been cooking" since I was under the the impression you were the main development force, but I figured I'd check the contributors in case there was a larger team

I'd say veluca is doing most of the tricky things in jxl-rs recently, but yeah everyone is doing their job

I've been thinking a bit, could this be an issue with how gamma distorts the probability distribution? e.g. sRGB 99.5 shouldn't dither to 50% 99 50% 100, because the with gamma, 99.5 isn't actually "in the middle" of those values?

It did seem like images were slightly brighter, but it was also 4am with a dodgy viewer in terms of color management

For a second I thought of Gaborish, but that would be encoder side changes

dither itself is a red herring given the issue was introduced in 0.7, coinciding with different color profile representation in the PNGs

something crushes the colors, like Jon hinted

hmm, nope, checked how much error that introduces, at least on sRGB only happens to really dark colors and even then the error is very small (~2% max)

Maybe this? (or one of the other PNG color management issues) https://github.com/libjxl/libjxl/issues/4503

Wondering whether it's safe to use `save_as_reference = 3` when encoding (using a hacked encode.cc that allows this) as long as patches are disabled...

Can the encoder decide to use ID 3 internally for anything else? Or could it in the future?

Anecdotally it works fine 🙂

iirc the encoder currently only uses one id for patches and one for frame blending, so there should be two ids not used for anything, right <@179701849576833024> ?

I can often get a smaller file by making manual use of that extra reference frame than I can if I let patches use it. Especially for animations with repeated frames.

And I guess a follow-on question if id 3 isn't going to be used for anything else: should the API restriction be relaxed such that clients *can* use reference 3 as long as all frames explicitly disable patches?

oh, are you implementing an animation encoder on top of libjxl that is manually using reference frames? that sounds interesting!

if you're willing to open source it, we could add this to the libjxl repo and make cjxl use it when encoding animations. That would also make it easier to align what is needed in the libjxl api with what is needed to do more effective animation encoding. E.g. I can imagine you may at some point also want to manually define patches instead of just using frame blending, and that's also something we don't have an api for (yet)

Sort of... it's become a bit of a mess and needs rewriting from scratch TBH, but basically you feed it a JSON file that references other (single-frame) files that become the frames of the result, along with crop offsets, save_as_reference, blend_source, etc.

You have to manually work out the best blend source (and do the appropriate cropping / "alpha diffing")

By finding the most similar previous frame that you also have a spare reference slot for.

I believe that's true, yep

i.e., would it make sense to do something like this? https://github.com/libjxl/libjxl/pull/4512

<@532010383041363969> I noticed you removed this adjustment for X compared to B a long time ago. Do you recall if you ever added something similar back again? At a glance I can't see anything in Adaptive Quant that's compensating for the different range of the channels

I could be mistaken though, so we'll keep tuning the DCTs and then look into tuning AQ too

<@794205442175402004>, is this worth pursuing?

I'm working on this by the way... it will be on Github eventually.

When I've removed some of the broken features and added some kind of documentation.

yeah why not, I can see how it can be useful to have control over all reference slots and not letting the encoder reserve one if it's not using patches anyway.

is it normal for v0.11.1 to crash for lossless transcode of XYB JPEG input?

IIRC it doesn't support RGB JPEGs that are subsampled, which is what cjpegli produces by default with --xyb

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

Yeah, the PR has been pending for a few months https://github.com/google/jpegli/pull/136

ok thanks

waiting for this to be merged [⠀](https://cdn.discordapp.com/emojis/992849031011242034.webp?size=48&name=dorime)

Everyone's waiting for all the PRs

<:NotLikeThis:805132742819053610>

Everything from fixing decode failures and crashes to quality improvements have been ready for most of the year but not looked at

I knew for APP14 but didn't know (or forgot) this one <:KekDog:805390049033191445>

APP14, Empty DHT, Bad ICC, RGB subsampling, Static builds not being static, build failures, no DLL for Windows... All have PRs

Some are over a year old, fixing issues that still get opened on libjxl

It turns out you had already brought up the issue. It seems like libjxl is still defaulting to Linear images when outputting 8bit sRGB

I've re-opened the original issue about it, and closed many others as duplicates https://github.com/libjxl/libjxl/issues/2289

We ended up fixing it ourselves, or at least attempting to. I think sRGB as default makes sense, since you can always specifically request linear output for more advanced users https://github.com/libjxl/libjxl/pull/4516

Ended up finding this again https://github.com/libjxl/libjxl/pull/1341

Unfortunately got disabled in this commit <https://github.com/libjxl/libjxl/commit/27afa5e4c2e66d917746f407674369f19b6fca47#commitcomment-141216453>

I did not miss C build systems

🤨 how do we end up requiring that function

they're experimenting with toml configs https://discord.com/channels/794206087879852103/794206170445119489/1440005688871878787

oh, right, thanks

<@384009621519597581> https://github.com/skystrife/cpptoml is apparently header-only, in case that helps

oh nice, thanks

``` error: exception handling disabled, use ‘-fexceptions’ to enable 920 | throw array_exception{"Arrays must be homogenous."}; | ^ ``` will this be a problem for this library

actually since this will probably a fork I'll just enable the feature...somewhere

I don't know why there's like 50 makefiles but I think I found the right one 😅

this is probably strikingly obvious to everyone else, I've barely touched C ^^"

> Mixing code compiled with `-frtti` with that compiled with `-fno-rtti` may not work lovely

apologies for microblogging my struggles

Also <@604964375924834314>, do you think there'd be any issues caused by this? AFAIK you can always request Linear via the API or the djxl command, so it just makes the default more compatible for non-managed viewers and the average person https://github.com/libjxl/libjxl/pull/4516

I think my first thought is along the lines of “I hope our sRGB implementation behaves correctly above 1”, + that it exposes us to the controversy of “what is the sRGB TF, really” (especially combined with the first point, given that the divergence between piecewise and g2.4 widens)

if anything, maybe “gamma 2.2” might be a safer default

(^ this sentence is the output of the process “I don’t know what to believe anymore”)

I might need some help with this one ``` [ 93%] Linking CXX executable djxl [ 93%] Linking CXX executable benchmark_xl /usr/bin/ld: ../lib/libjxl_extras_codec.a(jpg.cc.o):(.data.rel.ro+0x10): undefined reference to `typeinfo for sjpeg::SearchHook' collect2: error: ld returned 1 exit status gmake[2]: *** [tools/CMakeFiles/djxl.dir/build.make:107: tools/djxl] Error 1 gmake[1]: *** [CMakeFiles/Makefile2:1421: tools/CMakeFiles/djxl.dir/all] Error 2 gmake[1]: *** Waiting for unfinished jobs.... ```

```diff --- a/lib/CMakeLists.txt +++ b/lib/CMakeLists.txt @@ -118,7 +120,8 @@ else () else() # WIN32 list(APPEND JPEGXL_INTERNAL_FLAGS -fsized-deallocation - -fno-exceptions + # -fno-exceptions # Disabled for TOML parsing library + -frtti # Enabled for TOML parsing library # Language flags -fmath-errno ```

easiest might be to disable sjpeg (edit `CMakeCache.txt`, look for `SJPEG` to find the variable that controls whether to build it, set it to `no` / `false`, rebuild)

thank you!

A smarter way could be defaulting to Linear for high bitdepth, and sRGB for 8bit. But you know the code best, so we just did a one line fix to close all the issues about Linear PNGs getting saved

got the config file working ^^ you can tune block selection without having to recompile

jonny, should I send you a copy while I work on this further

Sure, would make my tuning faster since I'm approaching smaller tweaks now

big agree

g22 being default is the only sane option

<@238552565619359744> (and anyone else interested) this is for the build that allows you to tune block selection via a config file. read the included README, it's important

I know it's inconvenient to set up, I'll be setting up something proper so it'll just be a fork of libjxl on github

<@207980494892040194> <@238552565619359744> public fork with the changes to allow tuning parameters from a config file between runs https://github.com/AccessViolation95/libjxl-tuning

~~this change isn't checked into git, so you'll need to do this yourself after cloning or building. until I find a way to disable building of SJPEG somewhere else~~ resolved

sapian, maybe you could create a windows build for jonny? I don't want to juggle all the dependencies and changes to my environment that I'd have to make to get cross compiling from linux to windows working ^^"

last time I tried to install python it...didn't go well

For Windows, I needed to remove `-fno-rtti` from `CMakeLists.txt`. Otherwise it looks like I got a working build. 👍

`SJPEG` seems to be fine when compiling for windows. I'm turning it back on.

oh huh

oh right yeah I think I neglected to change the build setting for windows

The encoding speeds are slower, is that due to `cjxl` trying to read from an external file every time it makes a DCT block decision?

try on a RAM-disk maybe?

good idea

Still about 20x slower, even when on a ramdisk ``` cjxl-main wallpaper_1.ppm --disable_output --num_reps 5 JPEG XL encoder v0.12.0 a8589583 [_AVX2_] {Clang 21.1.5} 1920 x 1080, geomean: 9.300 MP/s [9.128, 9.389], 5 reps, 12 threads. cjxl-tune wallpaper_1.ppm --disable_output --num_reps 5 JPEG XL encoder v0.12.0 b06b9a83 [_AVX2_] {Clang 21.1.5} 1920 x 1080, geomean: 0.378 MP/s [0.376, 0.387], 5 reps, 12 threads.```

Maybe parse the text once and store the values, instead of parsing for every DCT block

it's probably not doing disk I/O every time because the OS will cache it in memory, but you're probably right about that being the slowdown. specifically the TOML library parses it ever time

parsing it once was my initial plan but it would probably require more significant modifications to the code. I'd have to parse the config somewhere near the top of the call graph and pass a reference it along to eventually end up where it's needed

which I could do, but keeping these changes localized has the advantage that it's trivial to pull in improvements to other parts of upstream libjxl

I'll take a look at it, maybe it wouldn't be that many more modifications

Either way, it's already helping me make some more precise adjustments, and should speed things up tenfold

really glad to hear ^^

do you intend to run performance benchmarks for different configs as well? if so I'll get to resolving this soon, if not I'll probably keep it like this for the time being

or if you're testing images that are so large that the slowdown becomes a pain

also let me know if at any point you'd like more variables to be added to the config. they're trivial to add

I'm willing to give it a shot, right now I'm just testing a simple 1080p image.

ah I think you misunderstood me. I was asking if you're actively bothered by the slowness of it so I know whether I should fix it now or if this is fine for the time being

Oh, it doesn't bother me too much. It's fine for now.

When trying to build the wasm, it gets all the way to the end and 1 test fails. Anyone else getting this? ``` 4808/4818 Test #4818: test_wasm_jxl_decoder ............................................................................................................................................................................................................***Failed 0.15 sec Running testSdr /---/libjxl/tools/wasm_demo/jxl_decoder_test.js:47 jxlModule.HEAP8.set(encoded, buffer); ^ TypeError: Cannot read properties of undefined (reading 'set') at testSdr (/---/libjxl/tools/wasm_demo/jxl_decoder_test.js:47:19) at runTest (/---/libjxl/tools/wasm_demo/jxl_decoder_test.js:15:3) at Array.forEach (<anonymous>) at /---/libjxl/tools/wasm_demo/jxl_decoder_test.js:138:9 Node.js v22.15.1 ... 99% tests passed, 1 tests failed out of 4817 Total Test time (real) = 271.30 sec The following tests did not run: 4814 - GaussBlurTest.SlowTestDirac1D (Disabled) The following tests FAILED: 4818 - test_wasm_jxl_decoder (Failed) Errors while running CTest ```

Submitted a bug and pull request

Created 2 JPEGs with GIMP, using the Advanced Options [x] Use arithmetic coding, and cjxl would not transcode them. JPEG XL encoder v0.11.1 [AVX2] Note: Implicit-default for JPEG is lossless-transcoding. To silence this message, set --lossless_jpeg=(1|0). Encoding [JPEG, lossless transcode, effort: 7] ./lib/jxl/jpeg/enc_jpeg_data_reader.cc:144: JXL_FAILURE: Invalid comps_in_scan: 3 ./lib/jxl/jpeg/enc_jpeg_data.cc:402: JXL_FAILURE: Error reading JPEG ./lib/jxl/encode.cc:2095: Error during decode of input JPEG Error while decoding the JPEG image. It may be corrupt (e.g. truncated) or of an unsupported type (e.g. CMYK). EncodeImageJXL() failed. Eye of Gnome could view one, but gave an error with the other: Error interpreting JPEG image file (Suspension not allowed here) Firefox and Chromium could view both images.

post the images please

JPEG with arithmetic coding isn't well supported generally, and JPEG XL as a format doesn't support losslessly transcoding arithmetic coded JPEG

I understand not supporting bit-reconstruction, but it should be able to losslessy transcode still, no?

that depends on how you define "loss" here (I meant in bitstream level), but yeah I guess preserving only coeffs may be possible

Yes, that should be possible, but libjxl currently doesn't support it. Would be a good idea to add that though

It likely wouldn't have the same space savings, but if you wanted to convert Arithmetic JPEGs to JXL for wider support, then it might make sense

Arithmetic is around 10% savings over regular JPEG, JXL is around 20% savings, so it is still a meaningful improvement (though indeed smaller)