Seems like a good idea to me. Two things:

• Some of the tests are failing, probably just because they're comparing the new dithering to a reference decode with the old dithering and getting some differences.
• Using a 32x32 matrix might cause a bit of slowdown due to some extra pressure on the cpu cache, since it's 4 KiB instead of 0.5 KiB. Could you give some before/after results for djxl input.jxl output.ppm --num_threads=0 --num_reps=100 to see if there's something noticeable?

A very small but notable difference for me on my intel i5-12400, from 74.889 MP/s to 74.034 MP/s.

Speaking of the failing tests, what would be the best way to fix them?

A very small but notable difference for me on my intel i5-12400, from 74.889 MP/s to 74.034 MP/s.

Speaking of the failing tests, what would be the best way to fix them?

Best to locally run the tests and check on a case-by-case basis if the failure indicates an actual problem or not.
I think there might be an actual problem related to the dithering weights being too high, making lossless uint8 no longer roundtrip. Once that's fixed, maybe there are no failing tests anymore.

In my ideal world, dithering matrix should be generated at compile time. Most preferably if all values are integer/(2**k) (and no FPs are used in calculations before the final conversion)...

Theoretically, we could just call the photon noise in the decoder to get blue noise for 'free', set to a low level like 200.

Okay I upped the precision from 4 decimal points to 5 and I constrained the values to [-0.49219, 0.49219]. Hopefully this fixes the failing tests.

It's seems like @jonsneyers is on holiday. 😅

@jonsneyers friendly ping