JPEG XL

Probably.

What's wrong about it?

You don't need a separate process to run a WASM VM.

You can link a wasm vm into your process but copying memory in and out of the vm is no different than serializing data between different processes. Just with even MORE overhead.

That's incorrect.

Really?

I don't understand then.

Yup, really. Context switches are expensive and are only getting more expensive (Meltdown/Spectre says hello).

Besides, who said you need to copy in and out of the VM? If it's a few tens (or hundreds) of bytes it's easier to copy and virtually free, if it's more, you can absolutely do something to access WASM buffers directly.

Anyway, embedding native code in JXL bitstream is an obvious non-starter for obvious reasons of ISA dependency. Even if you could sandbox it perfectly with zero cost (you can't).

Oh, no one was arguing for that. Jon was just saying it might be worthwhile to make a very simple and basic JIT that generates native instructions to decode the MA trees.

Ah, then I misread that part.

Then you have a JIT already, what's the problem with shipping WASM bitcode instead of that? :)

It's a kind of risky idea but MAYBE it could be made guaranteed-safe if someone was very careful and clever?

They were, and they made wasm...

Why reinvent the wheel?

Well the MA trees have a lot simpler requirements than wasm. That would be like killing a mosquito with a grenade launcher

wasm doesn't have good support for simd instructions yet either right?

There is support for simd, has been for quite some time. You can use SIMD from Rust compiled to wasm32, for instance. Is there any indication that it isn't good?

Anyway. TL;DR of my position. - Linux namespaces are totally irrelevant because they leave GIANT attack surface which is extremely excessive for running untrusted native code (Linux namespaces except userns aren't, and never were, a security boundary; userns are kinda trying to be, but a very shoddy one) - Plan 9 mooning is totally irrelevant as well because we have it already and it's called seccomp mode 1, literally designed for running untrusted binary code with almost zero attack surface - If the amount of untrusted binary code is tiny, the setup and communication overhead of ANY external process (be it seccomp 1 or whatever Plan 9 had) would be MASSIVELY exceeding the cost of the code itself - if you want/need a JIT anyway, just use WASM (in whatever part of the pipeline) and don't reinvent the wheel

<:JXL:805850130203934781>

unveil is a filesystem namespace with no overhead, and unveil+pledge is a way for processes to revoke their own privileges and have the kernel enforce it. They're good ideas and something similar should be adopted everywhere to make security easier.

both unveil and pledge combined are less powerful than seccomp mode 1, so again totally irrelevant

I thought simd instructions were still in the planning stages for wasm

(seccomp mode 2 _is_ pledge-equivalent, btw, and yes, filesystem namespaces are unveil, but that's again not what we need here)

Less powerful? It's not about power. All of the power of seccomp is totally useless if it's incomprehensible to use.

Writing secure software needs to be practical and obvious and convenient.

It's about relevance. I don't understand what's the point of bringing irrelevant sandboxing features from other OSes into the discussion, what point are you making?

Because you mentioned seccomp, which is a uselessly incomprehensible version of what could be a useful security feature

But it's only useful if people actually want to use it

And no one wants to use it if it's not easy to use like pledge

originally I mentioned seccomp mode 1, which has NO configuration

so it can't be incomprehensible by definition

And that is what I mean by namespace, btw

then you are using the words wrong

Different processes having different views of the filesystem

namespaces mean a very specific thing

That is often called a filesystem namespace

And if different processes have access to different kernel syscalls, then that isn't usually called a namespace but you can probably assume the intent or meaning still by the context

Okay, we are going in circles. Namespaces are irrelevant. To run untrusted native code, you don't need "different views of the filesystem": you need *NO* view of the filesystem, like no access to the syscalls at all. Anything else is already an infinitely larger attack surface than you want. So in context of this discussion, filesystem namespaces, or any other namespaces at all, have exactly 0% relevance.

I said that like an hour ago.

I don't want to have to "assume the intent or meaning". Words have defined meanings, let's use them.

I can understand your point of view and it's a good one.

I don't know what mode 1 is off the top of my head. It's a linux specific API with very fine grained control and not at all friendly to the typical programmer, with not even a wrapper in the C library for it.

<#806898911091753051>?

Sorry no one has gotten back to you on this. Chunked encode API is pretty new and I'm not sure how it works.

I'm just a lurker.

Seems like auto-merge for PRs is being blocked by a formatting error <https://github.com/libjxl/libjxl/actions/runs/14235466206/job/39943279145?pr=4178> Just added it to my changelog PR if you want to merge it quickly <@794205442175402004> https://github.com/libjxl/libjxl/pull/4169

Yikes, now they fail because of my recent changes, pls revert your typo fix lol

The only failing required test is due to your [CMAKE fix not being merged](<https://github.com/libjxl/libjxl/actions/runs/14251775663/job/39946056483?pr=4169>), and yours won't merge because of my [typo fix not being merged](<https://github.com/libjxl/libjxl/actions/runs/14235466206/job/39943279145?pr=4178>), so now we're at a gridlock of who's gets manually merged first haha

I didn't realize that you were hitting that issue too, I was referring to that log in your PR: ``` tools/jxltran.cc:9:#include "lib/include/jxl/decode.h" tools/jxltran.cc:10:#include "lib/include/jxl/decode_cxx.h" Don't add "include/" to the include path of public headers. ``` Isn't it a required test?

Required for merging have the indicator on the right

Ah, didn't realize that 😅

Though, fixing it wouldn't hurt since we appear to have plenty of time

I actually have permission to close PRs on the repo with my Triage role, but unfortunately I can't merge

I would like to fix the CMake first, but I would need another CI run for that. I'm a bit plaing a guess game here

I will do it on my next `jxltran` PR. But you can do too if you want

It doesn't seem to break anything, so I'll let you do it as part of the jxltran work

<@794205442175402004> apologies for the double ping, but you'll need to force merge that due to the stalemate with the CMAKE sjpeg fix (which will require re-approval after too). Then Auto-Merge should start working again

OK, I'm playing with progressive encoding again... Last time y'all told me that progressive lossless encoding is basically broken with effort >=5 (although in the end I failed to understand why exactly). However, I'm also getting the same thing if I use `--progressive_dc` instead of `-p`: ``` $ cjxl path/to/png path/to/jxl -d 0 JPEG XL encoder v0.11.1 794a5dcf [AVX2,SSE4,SSE2] Encoding [Modular, lossless, effort: 7] Compressed to 161373.8 kB including container (10.997 bpp). 10672 x 11000, 7.569 MP/s [7.57, 7.57], , 1 reps, 32 threads. cjxl path/to/png -d 0 365,93s user 16,98s system 2143% cpu 17,861 total $ cjxl path/to/png path/to/jxl -d 0 --progressive_dc=1 JPEG XL encoder v0.11.1 794a5dcf [AVX2,SSE4,SSE2] Encoding [Modular, lossless, effort: 7] ^C cjxl path/to/png -d 0 --progressive_dc= 392,90s user 233,60s system 104% cpu 9:58,64 total ``` — which, to my understanding, isn't supposed to actually do progressive encoding of the main image (i.e., it does not imply `--progressive_ac` or `--responsive`). Why is this?

`progressive_dc` and `progressive_ac` only work for the lossy mode of libjxl. For lossless they don't actually make the image progressive, all it does is disables chunked encoding, which trades encoding time for more density.

Ah, it seems my understanding was incomplete. I did understand that `{q,}progressive_ac` was only applicable to the lossy mode (as it is fundamentally about encoding the AC/"HF" VarDCT coefficients), but I thought that `progressive_dc` was basically "prepending" a frame made of the LF coefficients onto the main image, regardless of whether the main image was lossy or lossless.

Progressive lossless uses a different technique called squeeze.

All of JPEG XL's features are explained really well in this technical report. Section 5.1.3 explains what squeeze does alongside some images a few pages down.

We're actively working on progressive lossless, if not almost done with it already https://discord.com/channels/794206087879852103/803645746661425173/1357850229247840401 Right now, progressive_dc disabling chunked works around an [issue](<https://github.com/libjxl/libjxl/issues/3823#issuecomment-2351120650>) with the TOC, where the 1:8 LF frame can't be rendered until the end of the file. Downside being the entire image has to be processed as a whole, instead of threading individual groups. Squeeze, used for progressive lossless, also disables chunked due to downsampling the image as part of the transform

We're actively working on progressive

So I'm trying to compile libjxl and I followed this guide https://github.com/libjxl/libjxl/blob/main/doc/developing_in_windows_vcpkg.md Visual Studio doesn't show any errors, but I just have no binaries at all in the /out/build/x64-Clang-Release/tools folder

I recommend using msys2, it's an easier process and it generates faster binaries

I got further by setting BUILD_TESTING to OFF in CMakeSettings.json

Why does this always happen

What am I doing where everything always fails with the most obscure errors that nobody else has?

huh msys2 just worked

No errors, no bs

Or well ig one error I had to work around (my cmake version is 4.0.0 idk wtf it on about)

Why are these like quadruple the size they should be

Actually more like 20-30x the size

and they don't even work wtf

Did it download and compile dependencies like brotli, hwy, skia/skcms and whatever?

It's kind of a pain to compile libjxl

But totally doable

Homosapien had the same issues with it not being static and massively larger. We fixed thrm (mostly) and he mentioned rewriting the build docs

you compiled dynamic, you need to copy DLLs to the folder the exec is in

in isolation static will always be smaller

or run them from the mingw shell you built them in, as it will have the `PATH` set appropriately

maybe a debug (or at least unoptimised) build? you can run `cmake -DCMAKE_BUILD_TYPE=Release .` from the build directory (or edit `CMAKE_BUILD_TYPE` in `CMakeCache.txt` directly) and rebuild

Our static builds are still 2-4x larger than the github releases. 10mb per binary

[av1_woag](https://cdn.discordapp.com/emojis/852007419474608208.webp?size=48&name=av1_woag)

It was 50, but that was debug as Mario said

note that by default, a CMake build won’t be stripped

so you can do that right after building, or add `-s` (if I recall correctly) to the linker flags

I did that, which changed my command to this ``` cmake -DCMAKE_BUILD_TYPE=Release -DBUILD_TESTING=OFF -DBUILD_SHARED_LIBS=OFF -DJPEGXL_ENABLE_BENCHMARK=OFF -DJPEGXL_ENABLE_PLUGINS=ON -DJPEGXL_ENABLE_MANPAGES=OFF -DJPEGXL_FORCE_SYSTEM_BROTLI=ON -DJPEGXL_FORCE_SYSTEM_GTEST=ON -DCMAKE_POLICY_VERSION_MINIMUM=3.5 .. ``` The exes are still slightly too large, but much closer to normal release From here how would I make a stripped static build?

<@207980494892040194> didn't you say two static flags are required?

`-DCMAKE_EXE_LINKER_FLAGS=-s` might help

(that, or running `strip` on all executables yourself)

You need to specify two flags for a truly static libjxl. `-DBUILD_SHARED_LIBS=OFF` and `-DJPEGXL_STATIC=ON`. Also I recommend removing `-DJPEGXL_FORCE_SYSTEM_BROTLI=ON`, lots of errors pop up and the build fails with it on.

Also I recommend using clang, according to my testing it's around 5-10% faster than GCC

This does decrease the size, but static builds are still 1-2MB bigger than official release

I'll see about trying GCC

Also my command currently ``` cmake -DCMAKE_BUILD_TYPE=Release -DBUILD_TESTING=OFF -DBUILD_SHARED_LIBS=OFF -DJPEGXL_ENABLE_BENCHMARK=OFF -DJPEGXL_ENABLE_PLUGINS=ON -DJPEGXL_ENABLE_MANPAGES=OFF -DJPEGXL_STATIC=ON -DCMAKE_EXE_LINKER_FLAGS=-s -DJPEGXL_FORCE_SYSTEM_GTEST=ON -DCMAKE_POLICY_VERSION_MINIMUM=3.5 .. ```

pacman -S can't find clang-compiler-rt so well idk if it will work but ig I'll try

aaaaaaaa

welp I got what I could time to try build

Same Cmake error even though I have 4.0 so ig I will add the minimum shit

<:Think2:826218556453945364> ``` [344/379] Error: Can't generate doc since Doxygen not installed. FAILED: CMakeFiles/doc C:/Users/Admin/Documents/GitHub/libjxl-mingw/build/CMakeFiles/doc C:\Windows\system32\cmd.exe /C "cd /D C:\Users\Admin\Documents\GitHub\libjxl-mingw\build && false" [353/379] Building CXX object tools/CMakeFiles/enc_fast_lossless.dir/__/lib/jxl/enc_fast_lossless.cc.obj ninja: build stopped: subcommand failed. + retcode=1 ```

~~I think you don't need clang-rt to compile.~~ Also I think the inflated binary sizes are intrinsically tried to lib-c or p-threads or something like that. Not much you can do about it I think.

How do I disable doc generation with clang?

strange, I got it to compile on my machine even though I don't have doxygen installed

try adding `-DJPEGXL_ENABLE_DOXYGEN=OFF`

Now I get this ``` + cmake --build /c/Users/Admin/Documents/GitHub/libjxl-mingw/build -- all doc ninja: error: unknown target 'doc', did you mean 'jxl'? ```

Oh I can just do this

`Pacman -S --needed mingw-w64-clang-x86_64-compiler-rt mingw-w64-x86_64-doxygen `

wtf why do I get that error now

I went back to the original command and I get that error and I have no idea what I did

temp storing this here ``` ./ci.sh opt -DBUILD_TESTING=OFF -DBUILD_SHARED_LIBS=OFF -DJPEGXL_ENABLE_BENCHMARK=OFF -DJPEGXL_ENABLE_MANPAGES=OFF -DJPEGXL_STATIC=ON -DJPEGXL_FORCE_SYSTEM_GTEST=ON -DCMAKE_POLICY_VERSION_MINIMUM=3.5 -DCMAKE_BUILD_TYPE=Release -DJPEGXL_ENABLE_DOXYGEN=OFF ```

I took a snapshot before I went to gcc because I knew some shit would happen so ig I'll try again

wait you are using the script? I got it to compile like so, `export CC=clang && export CXX=clang++` and then running the regular cmake command

I don't really trust that script I'll be honest

Oh I'm just following this https://github.com/libjxl/libjxl/blob/main/doc/developing_in_windows_msys.md

So DJPEGXL_ENABLE_DOXYGEN=OFF just permenantly breaks the build command even if I remove it and nuke the build folder

So I get an error with doxygen so ig I'll try your method

Does compiling libjxl with LTO optimizations work? It could be another way of reducing binary sizes but it always seems to fail for me.

yeah regular ol' cmake works just fine, and it builds faster too. Just use this command for it to use all of your cores `cmake --build . -- -j$(nproc)`

Well it's using clang now and idk if I notice any difference The executables are still a bit bigger than the official release

It's 20% faster than the official Windows releases so I would say it's a worthwhile trade off

cool

So interesting findings, gcc compiled libjxl theoretically compatible with XP Except I get this error and it works fine on Vista+ so idk what it's on about

Or well all the executables I'm interested in (cjpegli, cjxl, djxl, and jxlinfo)

They check out in Dependency Walker, but I get this with all

The UTF8 manifest breaks XP Ig I'll just compile without it

Nevermind it can have a UTF8 manifest, it just is picky

So adding a compatibility entry makes it work ``` <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1"> <application> <windowsSettings> <activeCodePage xmlns="http://schemas.microsoft.com/SMI/2019/WindowsSettings">UTF-8</activeCodePage> </windowsSettings> </application> </compatibility> </assembly> ```

clang*

i already forgor

Well time to see if libavif fares better now with clang as well

Had to install yasm but it just builds as well holy shit

oop need to make static build

<:Think2:826218556453945364>

I apparently can't do 32 bit build of libavif

eh jxl better anyways

Does clang not support utf8?

Wait nvm

I noticed the issue

It would be funny to have a building doc for Windows XP <:KekDog:805390049033191445>

Not sure what hardware you're running, but if it's period correct, you could be a good benchmark for our faster_decoding tweaks xD

Can I get someone to run the pipeline on [4165](<https://github.com/libjxl/libjxl/pull/4165>)

It's a VM, but I do have some period hardware

but period hardware boring

For older pre-Sandy Bridge or AVX, I have 462 Athlon XP (unlikely to run due to no SSE2) 478 Pentium 4 something or another i forgor 754 or 939 Athlon 64 I forgor again 775 Pentium 4 3.06GHz 775 C2D 1.86GHz 775 C2Q Q6700 AM3 Athlon II x4 something or another AM3 Phenom II x4 955 AM3 Phenom II x6 1090t 1366 Xeon 5080

Interesting, I wonder why this wasn't done for jpegli, seeing as it's usually YCbCr (Could this have avoided RGB JPEGs?) <https://github.com/libjxl/libjxl/blob/main/lib/jxl/enc_modular.cc#L763>

encoding in RGB is very inefficient

jpegli can encode in XYB using an ICC v4 profile

Yup, and it would be a lot more compatible with existing hardware and software if it would add a JPEG APP14 tag. Otherwise some decoders will treat it like a normal YCbCr JPEG and mess up the colors.

Also jpegli STILL uses chroma subsampling by default for XYB JPEG, which is another hint for certain decoders to treat it like a normal YCbCr JPEG

Since it makes no sense to use chroma subsamping for an RGB JPEG

Pretty sure that would be a one-line fix too, and that alone would have a big impact. The APP14 header fix might be a 2 line fix.

That still uses RGB JPEG internally

but it's not RGB

I see what you mean

Yeah, I mean it could have used the usual YCoCg with YXB

The ICC profile is applied AFTER reverse-YCoCg back to RGB

And Adobe (APP14) JPEG is well supported by existing decoders

Just like how CMYK JPEG is commonly supported, using the same exact Adobe tag

If you were to do this, then the decoder would still do the reverse YCbCr transform, but maybe it's possible to make an ICC profile that takes that into account and changes it back by applying another YCbCr transformation on top of the inverse XYB transform. Ugh, confusing. But it's probably doable.

isn't the reason jpegli does XYB as an RGB JPEG because YCbCr in JPEG is not and cannot be lossless meaning you would get a double lossy color transform?

also jpegli does chroma subsampling **on purpose** for XYB JPEGs it's not some random accident

although it's not compatible with JPEG XL sadly :(

Ah yeah, I recall something along those lines

Regardless, swapping the Y and X channels would give a more graceful image degredation than hot pink and green

Graceful? I hear that it might actually be better for it to be ungraceful, so it's more obvious when something goes wrong.

Also I thought the channels are already arranged "YXB"

I tried creating my own YXB JPEG by channel swapping and ICC editing, but it ended up still having a tint, but with the image still recognisable. So it might be worth it

YBX would probably be kinda close to YCbCr right?

If the goal was "graceful degradation"

Which is arguably undesirable if it makes it harder to tell that a problem is present

Maybe there should be some "tell" like intentionally making it look super bright and washed out without color management

But that's not as obvious and cool as just making the whole thing look green

😎

The B channel caused an overexposed Cr result, but I could have done something wrong

Just a more graceful tint than eye searing pink and green

Pink and green are cool tho

Upgrading jpeg-xl 0.11.1 -> 0.11.1_1 👀

Is it normal for effort=10 to give a larger file size for "JPEG lossless transcode" mode?

Larger than effort=9 I mean

i recall it performs worse than e9 for reversible jpeg transcode

🧐 why

Local MA trees are sometimes better than Global ones

I think

Exactly, as separation along group number is limited to 256 splits in global tree, but not limited in local ones (each group has its own tree). Then this effect is more pronounced in large JPEGs with high variability

To be a bit more specific, an MA tree can have 255 contexts at most, so using a tree per group drastically increases the possible options

so if using local trees there can be at most 255 * group_count contexts?

As I understand it, yes

I was actually contemplating changing group size dependent on image size and thread count. Using the largest group size that fully utilises the encoding threads So for me, 1080p would be the current default of `-g 1`, 4K would be `-g 2` and 8K would be `-g 3` (based on megapixels/16 threads, compared to pixels per group size) Depends how much of an impact on encode/decode speed it has though. Yet more testing to be done!

I'm sure I've said it before, but I would've expected a memory reduction between 16 threads and 1 thread, since it's using local MA trees per group in lossless. Accounting for the image buffer being 32f instead of 8int, it's still using twice as much memory on something

Could somebody run CI on mine PR? I think I fixed all the problems, but cannot check it locally, thanks

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

https://discord.com/channels/794206087879852103/1256302117379903498/1360893139233280092

I can think of a good group size heuristic.

For each possible group size, Calculate the area in px^2 of "unused space" and use the largest one?

The largest one with the least unused space I mean

Afaik there's no reason for small group sizes to be better than larger group size.

That's what I was thinking, but ended up just using a minimum "pixels per thread" to make sure every block was full before picking a higher group size. So all threads are always saturated in the first pass, then whatever's left runs after

Encoding speed, decoding speed, memory and density

And I don't know how much cost "wasted space" actually has, if any at all

Well in terms of density I mean, larger group sizes should not have any reason to be at a disadvantage.

From my testing, very little. At most, a memory hit from allocating the extra space, and a small speed penalty from the bigger groups. Hence why I thought I'd keep it simple with the 'minimum saturation'

Better local MA trees in smaller groups

This is what I had cooked up, split for legibility here ```C uint64 pixels_per_thread; pixels_per_thread = (xsize * ysize) / num_threads; if (cparams.modular_group_size_shift == -1) { if (cparams.speed_tier <= SpeedTier::kKitten && xsize >= 1024 && ysize >= 1024 && pixels_per_thread >= 1048576){ frame_header->group_size_shift = 3; } } else if (xsize >= 512 && ysize >= 512 && pixels_per_thread >= 262144){ frame_header->group_size_shift = 2; } } else if (xsize >= 256 && ysize >= 256 && pixels_per_thread >= 65536){ frame_header->group_size_shift = 1; } } else { frame_header->group_size_shift = 0; } } else { frame_header->group_size_shift = cparams.modular_group_size_shift; } ```

Oh... that makes sense.

Checks the image meets the dimensions of the group size, then checks if there's enough pixels at that group size to fill all threads, if not, try the next lower size

If a bunch of similar dct blocks are all in the same group...

There are no DCT blocks, this is modular

also vardct has a fixed group size of 256

Oh

I went for hardware dependant settings since if you want the old behaviour, all you need to do is add `g 1`, and it's dependant on image resolution too so it would already vary based on input

I think it makes more sense for it to vary based on image than based on hardware

But it's not that big of a deal. Especially if it increases speed too

Gives a encode speed boost, sometimes a big decode speed boost (5x) and at worst a 0.1 bpp increase, or at best a 0.1 bpp decrease so far. I am gonna test it more though

The density difference I would imagine is too small to matter also

Yeah, I *was* worrying about it, but you get more image-to-image variance than this ever seems to cause, and bumping up an effort level with the speed increase natually obliterates it

The best way to improve libjxl right now is to make the source tree more logically organized into folders, making it easier to find and build only exactly what you want/need/expect/specify. While wasting the minimum amount of time figuring out the build system or fetching dependencies you don't even need. If I only need libjxl and not cjxl, I should be able to do that easily without being a cmake genius.

Hopefully that also will improve programmer productivity in the long term too

Tried it on a few more images, the results are 'it varies' Anything from a 1% size increase, to a 20% reduction. 25% faster encoding, or 5% slower. I'll probably stick it in a PR down the road so I can test it independently and more thoroughly

Same thing with jpegli too. If I want to build that it should be easy to specify what I want, if I want a libjpeg-compatible static or dynamic library for linking, what version, or if I want a jpegli-specific library with jpegli symbols, and if I want to install header files for libjpeg and/or libjpegli

20% bitrate reduction? For lossy modular?

Lossless, and 12% because I forgot the .6 thanks to being up all night, but yeah

All of the improvements jonny and I are working on are purely for lossless. It's somewhat easy to benchmark and gauge improvements since all we have to worry about is encode/decode speeds and density.

12% is still pretty massive

Smaller group size = 12% bitrate improvement??

For progressive lossless only?

Progressive lossless has some strange behavior, a lot of the settings which benefit regular lossless actually hurt progressive lossless. An example would be small group sizes, on average it's bad for normal lossless but good for progressive lossless. So we had to completely retune the codec for progressive.

Normal lossless, you can see the command in the image

The group size and threading is an idea I had while we wrap up the progressive and faster decoding tweaks, but I think it's better suited as a separate PR

For progressive lossless only, it's around 20% bitrate improvement and 600% encode speed improvement, 20% decode speed improvement Faster Decoding lossless, 75% bitrate improvement and 40% decode speed improvement

I thought progressive was more like 35 - 40% bitrate improvment?

Ever since we fixed that RCT bug

Oh right yeah, with that fixed it's around 35%

Some images don't like it, some love it. Heuristics are broken so we can't try both easily

Yeah, some of the heuristics seem actively hurt progressive. So just disabling them and setting a global flag is better in most cases.

YCoCg *tends* to help more than hurt, so we're enabling it for progressive. Though I have seen a few images get bigger with it instead

I only just thought, but it's the per channel (or global?) palette that breaks things. Smaller groups might be allowing it to use local palette still... Yet more testing to be done!

Okay nevermind, I got them mixed up

Yeah, we still might be able to eek out a little more bitrate saving with progressive. <:FeelsReadingMan:808827102278451241> <:jxl:1300131149867126814>

<:JXL:805850130203934781>

```-X PERCENT, --pre-compact=PERCENT Use global channel palette if the number of sample values is smaller than this percentage of the nominal range. -Y PERCENT, --post-compact=PERCENT Use local (per-group) channel palette if the number of sample values is smaller than this percentage of the nominal range.``` It's `-Y 0` that fixes progressive even on main cjxl

Username found this, so we could try adding a few predictors for progressive to try <https://github.com/libjxl/libjxl/blob/c496c521f99c13b8205c4fc4ff3eb3d652a1d1c3/lib/jxl/modular/encoding/enc_ma.cc#L535>

Right, like a special heuristic predictor just for progressive

Probably for efforts 8+

Nah, I think it could run lower. It'll only be maybe 4 predictors instead of the full 12 that P15 does. Maybe even just gradient and none for the decode speed

not that it matters, but current default selects g2 for small enough images

interesting concept for encoding, but wouldn't larger group sizes negatively affect decode speed on platforms with more threads than the origin? I'm also curious if it's really a net benefit to use the smallest group size in general, I recall it especially slowing down decode in some cases

Yeah, images 400 x 400 or less, citing no multithreaded speedup and wasted space in half-full groups. In practice though, there's not much overhead from empty space in groups. Otherwise it's always g1, apart from e11 which overrides any given parameters anyway

From our testing in <#1358733203619319858>, g0 is always faster, to the point we made faster decoding level 2 and up force g0. And with the overhauled decoding levels, I'm hoping people will be more likely to use them if they want to make sure decoding is fast. The odds are highly unlikely the image exactly matches group dimensions, so there'll be extra groups that more threads can still take advantage of too. Surprisingly, g0 even helps when threads are already saturated at higher levels. Best guess is the shallower MA trees allow quicker traversal per group

As always with image compression, results vary based on image content, but it seems to be a slight density improvement while making sure the threads you specify are actually being used. I think it's because the higher resolution the image, the more likely it is to have slow gradients instead of sharp edges, making larger groups more effective

not quite sure what channel to post this, but I have something kinda cool to show off :) I write security puzzles for hacking competitions (CTFs) and this year modified libjxl to include some extra predictor opcodes which had vulnerabilities. Teams had to craft a jxl image which could exploit these vulnerabilities and get code execution when the image is rendered to png. https://github.com/Nautilus-Institute/quals-2025/tree/main/jxl4fun Attached is what my final exploit image looked like, all of the grey parts are memory address leaks propagating through the predictor operators. It calculates ASLR (Address Space Layout Randomization, an exploit mitigation) bypass offsets using various operators. Finally the red pixels are from a new operator I added which had a out-of-bounds vulnerability. This is where the actual exploit triggers :) Anyway I had a lot of fun learning libjxl internals so that I could modify it in this way for the puzzle. I hope some of you can appreciate the exploit and the puzzle

Ooh, intruiging

This may interest you too https://github.com/google/google-ctf/tree/main/2023/quals/rev-jxl/solution

Yup, I've seen that one thanks for sharing :) Cool that you know about it. For mine I wanted to take it all the way to code exec. I was inspired by this exploit: https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html Which does similar style things in the JBIG2 image library to calculate offsets

Ahhh, my favourite. I remember discovering that a while ago and thinking "They built a microprocessor inside a PDF? Why didn't I hear about this sooner!"

Maybe it's a high effort implication since that's mostly where I've permuted settings.

I was considering limiting g3 to effort 9+ or when chunked is disabled, due to the 4x memory increase compared to current

I will try the suggestion posted. I tried something similar before, but quickly discarded it due to decode. Btw, at a glance it seems the "pixels_per_thread > min_target_group_pixels" enforcement ensures threads cannot be minimized when images cleanly tile with full groups. Intended?

Ah, good catch, I'll edit that now. If decode speed is still an issue, I recommend trying `--faster_decoding` in our fork <https://github.com/jonnyawsom3/libjxl/tree/FastSqueezeFixes> It has a much cleaner scale of Density/Speed, with improvements exceeding main `--faster_decoding 4`

can't wait to test it in olive

in my testing fd4 got significantly faster with reasonable density tradeoff

25% faster and 25% smaller as a rule of thumb https://discord.com/channels/794206087879852103/1358733203619319858/1358735338817720330

```images per bucket g3 g2 g1 g0 20t 1 31 261 529 1t 299 306 146 71 bpp 20t dec MP/s 1t dec MP/s git head e7 4.59 66.575 10.559 modified 20t e7 4.57 81.226 10.366 modified 1t e7 4.56 40.009 9.389 git head e8 4.47 72.912 10.044 modified 20t e8 4.46 78.802 9.717 modified 1t e8 4.45 19.530 8.164```

Intriguing

If someone fixes the color ringing/desaturation issue, and the overzealous crushing of shadows, then libjxl will leap 2 generations ahead and surpass libaom...

isn't it mainly just a tuning issue?

You could call it that

Is there anything blocking turning the jpegli folder into a submodule of the Google repo? We've noticed some commits not being mirrored and it would remove any confusion or ambiguity

So would deleting the separate repo 😂

If we use it as a submodule, then we can treat it as an actual library instead of a growth clinging onto libjxl. Ideally also using it instead of libjpeg

Whether it's an actual library or not doesn't depend on it being in a separate repo. It depends on the build system making it easy to build static/dynamic libraries and whether it comes with header files to make it easier to use as a library.

It uses a lot of code and files from libjxl. But libjxl needs to be easier to build as a library only, without setting up a bunch of dependencies that are only used for cjxl/djxl

libjpegli builds itself as a single libjpeg compatible library but doesn't let you build different API versions of the library at the same time, and it doesn't come with any header files.

Those seem like far more useful things to fix than separating redundant copies of the code into confusingly diverging repos

It's cool that they share lots of code and that improvements and adoption of one helps both...

Might be a bit much to ask, but is there an example of initializing an ImageBundle with my own data? (If this is the wrong channel, point me to the right one.)

isn’t ImageBundle the internal API?

It's a jxl class, yeah?

one that is not meant to be exposed outside of libjxl

I'm just trying to make a version of ssimulacra2 that accepts images as piped data, instead of command line arguments that are file names. It seems to be quite attached to jxl and operates on ImageBundles, as far as I can tell.

oops forgot to sign the ImageBundle NDA

guys, we can finally transcode our JPEGs https://github.com/libjxl/libjxl/pull/2704

> the fraction of JPEGs with empty DHT markers found in the wild seems to have grown recently and it is now a substantial amount

Interesting, I wonder what changed

I think it's just change in visibility given sufficient time

I think WhatsApp for some reason started to produce jpegs with empty dht markers

OK, I've tried several approaches for DCT coefficient order determination other than simple histogram (taking into account two-coef correlations growing from beginning and end of coefficients, remaking histogram for zero-runs after each coef selection, etc.), all of them are much slower and produce on my JPEG test suite at best (2-3)*10^-5 relative size improvement, so I think to stop here and try other improvements

Maybe Glacier mode can benefit from the best of them, otherwise it is pointless

Thanks for trying, it's of course more satisfying if there's an improvement but it's also good to know when the simpler thing is as good as it gets.

Apart from everything, it's great that jxl-rs is getting more love recently!

Can you pass "-" as the filename? this works with djxl

No. I already rewrote the main method. It had no logic previously to get the data in any other manner than reading it itself. I got it to run with my own data, but either I put it at slightly wrong addresses or in the wrong format, so I'll have to continue debugging it on the weekend.

possibly relevant is there's a separate ssimulacra2 repo

https://github.com/cloudinary/ssimulacra2

dunno how much is actually just stuff pulled from upstream libjxl

Pretty much all of it.

It's identical

Assuming I didn't break anything, this should help a few longstanding issues https://github.com/google/jpegli/pull/130

how much benefit is gained from the less compatible blue subsampling with XYB?

this I guess? https://discord.com/channels/794206087879852103/803645746661425173/1362628965860380823 (not-specified = blue subsampling)

Subsampling of RGB JPEG at all is a bit exotic, but generally not a whole lot... The channel is already heavily quantized, making the subsampling have less impact. In the PR I made 444 default for compatibility, and merely fixed the `--chroma_subsampling` parameter so that it doesn't subsample the Y channel for XYB JPEGs, if people choose to use subsampling anyway for the extra few percent (and sacraficing the 20% from JXL...)

We did try subsampling X too, since if we're risking compatibility anyway, we might as well make the most of it. It ended up hurting image quality far too much though, so we stuck with only B subsampling instead

oh, yes, that must be it, thanks (I assume those bits are not really “per pixel”, though)

We don't know why, but we also discovered that Vertical and Horizontal subsampling are swapped between YCbCr and XYB, so we had to reverse the values to get the expected results...

What happens is you subsample luma and keep chroma at 1:1

You get a blurry image

Honestly it should refuse to use subsampling for RGB JPEG...

Also what about the jpegli files in the libjxl source, are they just diverging into two separate redundant branches and files now?

Good start though 👀

I think usually you would put those in 3 separate pull requests though

Also does it actually write the correct adobe tag or does it write a ycck tag?

seems like it should write the correct value for the APP14 marker: https://github.com/google/jpegli/blob/bc19ca2393f79bfe0a4a9518f77e4ad33ce1ab7a/lib/jpegli/bitstream.cc#L58

Probably... Maybe I could have it print a warning about compatibility issues. Can't just make it a submodule because it has duplicate JXL code and the folder structure is a level too high. Probably should be separate PRs. Only the second 'real' PR I've actually made along with <#1358733203619319858>, so still learning best practices. It was mostly one line changes so didn't seem worth splitting to me. Correct tags. Default value of APP14 is 0, which is RGB and CMYK JPEG. YCbCr gets assigned 1 (Not that it's used anyway) and YCCK 2

<@245794734788837387> brought this up, sounds like a good idea. Using RGB at Quality 100/Distance 0 with a warning when subsampling is enabled

it would also kinda line up with libjxl does things since it also has special behavior for distance 0

oh and if there is a warning added about JXL-transcoding for XYB and quality 100 it should probably be present around the API and CLI option(s) for subsampling

maybe something like "**WARNING:** Using Values other then 444 in conjunction with either XYB or Quality 100/Distance 0 will result in files that cannot be losslessly transcoded to JPEG XL!"

As previously said, subsampled RGB isn't common anyway, so it could just be `Note: Implicit-default for Quality 100/Distance 0 is RGB JPEG` `Warning: Subsampled RGB JPEG may cause compatibility issues`

Also <@207980494892040194>, I'm gonna need a hand to fix... Everything xD

https://tenor.com/view/meme-anime-gif-22734101

Think I fixed it, somehow a missing } wasn't breaking the windows builds, so we never caught it before

Also made it only subsample *YCbCr* at low quality, since if we do want to expose RGB in cjpegli, we don't want that subsampled at all Should probably make RGB a parameter so people can disable it if they only want q100 YCbCr

Though, I wonder how well subsampling everything and effectively halving the resolution but at higher quality would look....

I also fixed some incorrect chroma values for 440 and renamed `distance` to `qDistance` since it was already defined earlier.

Added APP14 to CMYK and fixed the issues... Hopefully. Tests soon™

Is there a reason for why the jxl-x86-windows-static.zip 0.11.1 release of libjxl has 19/64 detections as a trojan? That seems very high for a false positive

On Virustotal

And it has been detected as a trojan for months

Doesn't sound particularly appealing to me...

Scores 2 points higher in SSIMULACRA, so it's something :P

Higher than default ycbcr?

That's still kinda silly

RGB JPEG is kind of uncommon

`cjpeg -quality 100` vs `cjpeg -quality 100 -rgb`

And quality 100 generally shouldn't be used. It'd be a default, but I'd probably add the same `-rgb` flag to cjpegli, with 0 disabling the switch and 1 forcing RGB on... If it's feasible. Along with the printout about being RGB

RGB JPEG shouldn't be used because it's not efficient and the quant tables are not even tuned for that.

There is no quant table at q 100, it's all 1...

But for quality 100 that's a different story since that doesn't apply

Yeah

Still uncommon

Didn't stop XYB, and again, it'll only be a default for cjpegli. With a message about how to disable it, similar to JPEG transcoding with cjxl

But it'll probably be a sperate PR. This one was meant to fix the biggest issues. APP14, weird XYB defaults and broken subsampling, with a tweak to enable 420 at q 30

Might address https://discord.com/channels/794206087879852103/1301682361502531594 at some point too, but we need to do wider testing around what quality threshold to disable it

do a Xor compare of both of them against the lossless source, there are a lot less colors shifted around for RGB

if someone is specifying "quality 100" then I don't think they care about size

I would presume the amount of people who care about size when defining the maximum available quality value are wayyy less then the people defining it because they expressly don't care about size and want a reference exchange file

What difference does it actually make though?

Aside from compatibility possibly.

Possibly larger file size for no actual increase in fidelity?

We *just* said that it scores 2 points higher...

I have seen on multiple occasions both people and companies use "quality 100" JPEGs as original references or as an intermediate format or "master copy", such as for example an artist exporting a ref sheet with defined color areas you are supposed to use a color picker on **OR** a company serving and processing millions or more images a day.

That doesn't demonstrate anything though frankly.

Comparisons with color gradients would be an excellent real demonstration though

What are those white sqares and why do the originals have such bad banding?

YCbCr and RGB at q100 compared to the original with XOR

https://cloudinary.com/blog/why_jpeg_is_like_a_photocopier#why_does_this_happen_

This is a cool comparison too, but not as convincing as just showing some color gradients, side by side.

~~trolling arc~~

At least they haven't brought up noise again

maybe they are genuinely worried about the compatibility concern although In my testing RGB JPEGs seem to work just fine in most software

I'm sincerely asking questions and sincerely wondering how much of a difference it makes. It's unfortunate you assume I have bad intentions.

with the context of your messages being in relation to a compatibility concern with software they make more sense

otherwise they seem like you are either ignoring or don't understand what is being presented to you and why

The xor comparison for example is a cool visualization but a better visualization would be a worst-case image like RGB color gradients and comparing the difference side by side.

Original, YCbCr, RGB

Nice! See? That very effectively demonstrates that it makes a real and positive difference.

That's all I was asking.

Gradients were actually a good shout, my fairly noisy test image was masking most of it

Exactly.

I'm happy now. You demonstrated exactly what I was asking about.

It's not trolling to ask a sincere and fair question...

I genuinely didn't know if the color transformation would actually make a difference in practice.

It's nearly 5am and I *really* didn't wanna go into Krita to try and make a comparison image... Then I realised I had that 10-bit test image and could just let Discord do the comparing for me

I guess my reason for confusion was I couldn't gauge exactly *why* you kept seemingly fighting against a change that when presented as improving color sampling accuracy in a case where people treat something as a giant reference image. psychovisual tuning vs mathematical similarity or something idk

Bonus YCbCr vs XYB

XYB still has that issue for me where stuff becomes darker

Importing to Krita the image is darker, but strangely converting the layer from XYB to sRGB fixes it, as if it's using the wrong transfer or something for rendering. In Irfanview it has a pink tint...

I was skeptical of what the actual difference was or whether it could actually be demonstrated.

Or if it was just an assumption

If I'm honest I was skeptical it would show anything in a gradient, but then it clicked that an RGB gradient would be best *in* RGB, naturally

Yep, it's basically a worst case scenario and the best contrived example to demonstrate the difference

But it's still real enough to matter

RGB looks just like the original whereas xyb and ycbcr are uneven steps

....it's the god damn gamma again

To be fair, the uneven steps are because of rounding errors that can theoretically be fixed in the decoder/cms, but that's a whole other can of worms. And you're not going to fix everyone's broken software.

Old XYB, New XYB (Stripped gAMA from the PNG)

The gAMA tag was messing up the png xyb?

cjpegli uses the guts of libjxl, so it correctly handles gamma in PNGs... Everything else, doesn't. So the XYB looks wrong in comparison

Interesting, seems jpegli is the main culprit, not sure why though

Lots of virus engines classify very broad categories as "trojan" like for example anything with the curl dll

what do the virus engines call the supposed trojan?

I believe it would be worth investigating. Widows Defender reacts to it, so no Windows users can use it without Defender intervening

There is also the risk of supply chain attacks, which I don't think should be forgotten completely

https://www.virustotal.com/gui/file/aa950f4d37abc1e52a5dbca153479b7cba0303e35331deb7d5ee5b18adf7a23b It is necessary to contact those AV companies and to report the case as False Positive. I recommend to start with Avast/AVG - same company, same detection. BitDefender's engine is used by more different products - so resolving it there has big impact.

If someone feels like it, feel free to check https://app.codecov.io/gh/libjxl/libjxl?search=&displayType=list and try to figure out what's up with those ~15% lines of code currently not covered by tests. It could be various things: - missing tests that should actually be there - various rather trivial error conditions (e.g. invalid api usage) that we didn't bother to add tests for (though maybe we should?) - dead code that can be removed - dead code because of a bug

Seems to be errors or untested encode parameters like keeping invisible pixels

Do you think that could explain the excessive ram usage? I remember you said the math wasn't adding up.

Will try to check

You mean for progressive lossless? Because that was something else, I just mean the error conditions aren't being tested in the coverage

https://web.ist.utl.pt/nuno.lopes/pubs/ub-pldi25.pdf

came across this in a paper and thought it may be relevant to devs here. I am slightly skeptical that there’s performance on the table here / that this will replicate, and it’s perhaps best dealt with by the LLVM developers, but <:shrugm:322486234142212107>

Clang alone is a 20% performance increase, 130% for fast lossless. It gets built as part of the tests on Github but discarded, with MSVC being uploaded to releases instead

My message is less about the speedup from compiler choice, and more about how a loop in clang builds of libjxl may be responsible for a lot of lost, but potentially easily recovered, performance.

Oh I didn't even see they used Clang, I was just saying much more than 7% is on the table

Unfortunately the paper doesn’t provide a whole lot of detail, and the regression is _probably_ a weird quirk of Sandy Bridge. (Which is weird since the Ivy Bridge cores aren’t much different from Sandy Bridge.) It’s a shame they don’t test on a modern architecture.

Fair!

> jpegxl-1.5.0 Not sure where they found that version number...

Ahh, it's a benchmarking suite version, not a library version https://openbenchmarking.org/test/pts/jpegxl

So they ran the tests using 0.7 too... Not exactly representative for multithreading either then

No that, more like how ram usage is double the size of the image as a raw bitmap after accounting for 32 bit float, ram was still 2x higher than it should be.

Or maybe I'm misremembering

Oh, no. The code coverage is just code that doesn't run in the tests. So corrupted files or misconfigured settings

Finally this is all-green again

Great catch! Thanks for digging into it.

This is your regularly scheduled reminder that <:JXL:805850130203934781> is awesome and cool.

Looking though some old PRs that never made it. I wasn't expecting the Game of Life as a heuristic

https://tenor.com/view/game-of-life-glider-grid-pixels-repeat-gif-27605519

Ended up doing more than we expected, but I think it's ready now https://github.com/google/jpegli/pull/130

We wanted to have cjpegli display the new defaults when they're triggered, but couldn't get it working. We also wanted to disable XYB when the RGB at distance 0 is triggered, since the color transform causes artifacts similar to YCbCr

Should give better results by default now though, with multiple bugs/strange behaviours fixed and the `-d 0`/`-q 100` RGB mode improving quality by a few points more

first (?) jxl-rs decoded image 🙂

And a 40MP image no less, so much for starting small xD

Curious about its performance

Slow, but not even *too* slow for not having any performance optimization whatsoever (5x slower than libjxl on this image)

Was it a VarDCT or Modular image?

Modular

Simple modular or with Squeeze/RCT/Delta?

RCT, but no squeeze or other fun stuff

Is that 5x slower both singlethreaded? (Prepare yourself for the barrage of questions xD)

yup

jxl-rs is currently single thread only and doesn't have any handwritten SIMD routines

just focusing on working implementation

I was moreso checking if libjxl was set to singlethreaded, but yeah. Glad we've hit this milestone and I'm sure more aren't far off

Reaching the usable status is already a milestone

not there yet 😛

it seems that libjxl is creating VarDCT image that its LF quant values exceed signed 16-bit range, but isn't marked as `modular_16bit_buffers = false` https://github.com/tirr-c/jxl-oxide/issues/456

jxl-oxide decodes the image successfully when I turn off 16-bit buffer optimization

(the problematic sample is at `c=0 y=25 x=39` in LF image which has value of `32894`)

We had something similar in libjxl-tiny in the implementation of a hw encoder. I suppose we should be more accurate in the range of quant factors to ensure the quantized lf stays within Level 5 constraints.

Realised the changelog had been neglected, so thought I'd try and catch it up https://github.com/libjxl/libjxl/pull/4224

I'll have to make a mental note of adding to the changelog as part of my future PRs, if applicable, rather than trying to recall what's new since the last release

Is there an ETA or any milestone that needs to be met before 0.12 releases?

AFAIK no set goals/dates from the core devs, but I was hoping to get all the jpegli tweaks merged and copied over before the next release, since libjxl is still where most get it from https://github.com/google/jpegli/pull/130

Some slight density improvement for lossless, at the cost of some decode slowdown: https://github.com/libjxl/libjxl/pull/4228 (and at faster_decode=2, some slight decode speedup, at the cost of some density) Feel free to try it out on your favorite image/corpus.

In general there is probably still some substantial room to improve MA tree learning heuristics. In particular we should implement some post-clustering tree pruning that (recursively) removes splits that go to two leaf nodes with identical predictor and context after clustering (and identical multiplier/offset). Such splits only cause some encode/decode slowdown (since the tree is unnecessarily deep) and some signaling overhead, without giving any compression benefit, so pruning them can only improve things — it just seems a bit tricky to do the code plumbing to do this pruning. <@179701849576833024> or <@1346460706345848868> do you want to give it a shot?

I think I should dedicate my jxl time to jxl-rs 😄 also I remember trying that out and it not being helpful, but I might misremember

~~what if you removed that regression so jxl's image quality goes back to 0.8, and then you can claim a MASSIVE quality improvement!~~

I still feel like we should try non-greedy tree splitting, but who has the time...

this is for lossless, where only speed and density matter. Lossy is a trickier thing

yeah, jxl-rs is more important than slight encoder improvements

As in, for each property do a DP to figure out the best way to split *more than 2-way* along that property, then repeat recursively in each subtree

The decoder could also optimize for things generated that way (especially if we limit this to using, say, two properties at most), and I imagine this would be massively faster to decode too

(two properties makes this effectively be 3 lookups in a lookup table)

Why 3 lookups?

2 1d lookups to reduce the range of the properties, and 1 2d lookup for the leaf

ah right

if it's limited to _n_ properties you can do it with _n_ 1D lookups followed by 1 _n_ D lookups, right?

yup

I imagine as soon as n starts being more than 3 or 4 the n-D lookup becomes unpractical

(depending on the # of distinct values)

where the size of the _n_ D lookup table is equal to the product of the number of nodes per property (+1)

yup

well, number of distinct nodes

there's already a specialized codepath for n = 1 and property = gradient/wp

yeah it might be lower than the number of nodes if there's repetition in the subtrees

but tbh, even if we don't table it up, a tree which has a relatively small number of parts that all share the same property should be significantly faster to decode as is

(basically by making a tree of 1d lookup tables)

(or even not lookup tables, if the # of possible values is small -- just do a SIMD-fied linear search...)

something like 7 buckets per property (large negative, medium negative, small negative, zero, small positive, medium positive, large positive) could already be pretty effective, so I can imagine you could pick the 3 most informative properties and make a lookup table of size `7*7*7`

yeah that would work, and the LUT would either be small or just fit in a single SIMD registers (and effectively be 3 instructions or so)

(fwiw you don't even need to decide those buckets, you can just let the DP figure out the best 7-way split :P)

I'm getting mixed results, and the impact to decoding speed is relatively negligible (within 0.5-2%). t's hard to say if it benefits photographic images more than non-photo

~~Also, I think I just found another huge regression with lossless.~~

~~I'll post it in <#803645746661425173> when I'm done double checking my numbers~~

Nevermind, got my numbers mixed up

Was comparing two different images by accident lol 😅

Welp, back to work addressing the smaller regression(s) with faster decoding 3

Speaking of which, can I use this multiplier for faster decoding to increase the number of buckets? It's hurting large photos for faster decoding 1-3. https://github.com/libjxl/libjxl/pull/4201#issuecomment-2849934762

No, that's a different parameter I think.

I'm making some edits in a fork and it turns out making the histogram "less efficient" is increasing density somehow.

Granted idk what an "efficient histogram" means. I'm just going off what the PR and Chat GPT says and changing variables around

Me and Sapien have been discussing that. When we have time, we're going to try changing values to their previous states, to see if we can get the quality back without outright reverting the PR

The only difference is actually in non-static properties. Level 1 already disables WP entirely, giving a 2x speedup thanks to using the kNoWP tree type

hopefully the solution to the regression gets found sooner or later

I'm struggling to understand it due to my lack of C++ experience, but assuming `gi` is Global Image and `sg` is Single Group, isn't this trying to select per-group RCTs by measuing the entire image instead? <https://github.com/libjxl/libjxl/blob/0855a037d7ac65249f0f4700995bbd9decb3b47d/lib/jxl/enc_modular.cc#L1462>

Nah, at that point in the code, `gi` is a group image 🙂

https://github.com/libjxl/libjxl/blob/0855a037d7ac65249f0f4700995bbd9decb3b47d/lib/jxl/enc_modular.cc#L1363

Ahh, we're trying to figure out why the RCT selection is worse than explicitly setting YCoCg in our tests, since it should be trying each RCT and then using the best result

Similar was happening with per-group palette and squeeze for progressive lossless, we think it must be basing decisions on the smallest step

EstimateCost is at the top of the file, so is that using the full image? https://github.com/libjxl/libjxl/blob/0855a037d7ac65249f0f4700995bbd9decb3b47d/lib/jxl/enc_modular.cc#L273 "at that point in the code" has me wanting to double check haha. Regardless, we're testing it now and globally setting a specific RCT is better than allowing local RCTs, so something is definitely wrong with the cost estimation

``` cjxl smol.png smol.jxl -d 0 JPEG XL encoder v0.12.0 e87f2f87 [_AVX2_,SSE4,SSE2] Compressed to 24252.3 kB (7.616 bpp). 5828 x 4371, 5.662 MP/s [5.66, 5.66], , 1 reps, 12 threads. cjxl smol.png smol.jxl -d 0 -C 6 JPEG XL encoder v0.12.0 e87f2f87 [_AVX2_,SSE4,SSE2] Encoding [Modular, lossless, effort: 7] Compressed to 24093.9 kB (7.567 bpp). 5828 x 4371, 7.448 MP/s [7.45, 7.45], , 1 reps, 12 threads. ``` Choosing a global RCT `-C 6` or `-C 10` comes really close to the RCT heuristics, or in this case, even beating it.

Yes, good idea

We added some debug printout and it seems like it *is* running per-group, but it *isn't* taking into account predictor selection. Still looking into it though