Post AvUUoZT87QFh6bR0T2 by imp3tuz@mastodon.gamedev.place
(DIR) More posts by imp3tuz@mastodon.gamedev.place
(DIR) Post #AvUUoXEAS55y9cQ1rs by aras@mastodon.gamedev.place
2025-06-25T13:30:48Z
0 likes, 0 repeats
Was nerdsniped into doing comparison of EXR, EXR+HTJ2K, JPEG-XL for *lossless* compression of *float* images. Am I doing something wrong, or is JPEG-XL not that great at this use case? https://github.com/aras-p/test_exr_htj2k_jxl
(DIR) Post #AvUUoXwpm0pAO9JhUO by imp3tuz@mastodon.gamedev.place
2025-06-25T13:33:14Z
0 likes, 0 repeats
@aras what purpose does JPEG-xl serve BTW? I came across it while expiring stuff from krita but didn't really get it...
(DIR) Post #AvUUoYqqPlcxBrWQnA by shamanix@mastodon.gamedev.place
2025-06-25T13:54:18Z
0 likes, 0 repeats
@imp3tuz @aras Multi layers, multi channels, high bit integers or floats.Encoding and decoding speed way faster than jpeg2000 that in most case not support more than 16bit int.But HT2K extension made jpegxl in case of lossy encoding/decoding speed I guess.
(DIR) Post #AvUUoZT87QFh6bR0T2 by imp3tuz@mastodon.gamedev.place
2025-06-25T13:56:50Z
0 likes, 0 repeats
@shamanix @aras can old systems handle it? Or would you require some code or something? I guess my question is- how backwards compatible?
(DIR) Post #AvUUoa0o6DBsn3BtxY by ignaloidas@not.acu.lt
2025-06-25T13:58:59.167Z
0 likes, 0 repeats
@imp3tuz@mastodon.gamedev.place @shamanix@mastodon.gamedev.place @aras@mastodon.gamedev.place new format entirely, needs new code, but can losslessly re-compress JPEG's with fairly significant savings
(DIR) Post #AvUUrmjfFYij7VhWMq by aras@mastodon.gamedev.place
2025-06-25T13:58:02Z
0 likes, 0 repeats
@imp3tuz @shamanix it has nothing to do with JPG besides sharing the similar name. It is a different file format, so no, software that does not implement support for it obviously will not support it.
(DIR) Post #AvUUrnKt1AUiyx7FNw by ignaloidas@not.acu.lt
2025-06-25T13:59:43.072Z
0 likes, 0 repeats
@aras@mastodon.gamedev.place @imp3tuz@mastodon.gamedev.place @shamanix@mastodon.gamedev.place I mean, it's the same standards group as the old format (nevermind that it's 30 years later)
(DIR) Post #AvUXWAtf2QcnXwlPxA by ignaloidas@not.acu.lt
2025-06-25T14:29:25.267Z
0 likes, 0 repeats
@aras@mastodon.gamedev.place IIRC the modular mode of JPEG-XL is fairly heavily focused into compression ratio so the speed is somewhat understandable, there's an explanation of the methods used here: https://cloudinary.com/blog/jpeg-xls-modular-mode-explainedthough it does seem a bit slower than what's advertised
(DIR) Post #AvUg5XHUbYR6jtHcsC by ignaloidas@not.acu.lt
2025-06-25T16:05:27.401Z
0 likes, 0 repeats
@aras@mastodon.gamedev.place ah, for the problems with interleaving - if you don't care about viewing the images with external programs and just need them in separate buffers - you could encode with only a single channel set as "color", with the rest set as extra (works as a grayscale + extra channels)
(DIR) Post #AvUrltzFfsAwon9i9Q by aras@mastodon.gamedev.place
2025-06-25T16:45:22Z
0 likes, 0 repeats
@ignaloidas I still need to convert from my interleaved format to planar that libjxl requires
(DIR) Post #AvUrlvI4pMpOrSyG8G by ignaloidas@not.acu.lt
2025-06-25T18:16:15.955Z
0 likes, 0 repeats
@aras@mastodon.gamedev.place ah, I misread, though you had/needed all planar instead of all interleaved
(DIR) Post #AvbAzOWWW0CZMscoKm by zeux@mastodon.gamedev.place
2025-06-25T18:40:54Z
0 likes, 0 repeats
@aras Nerdsniping it is!Caveats:- I switched to 1 thread to make it fair because I'm too lazy to chunk the image to thread the (de)compression as that's presumably what OpenEXR is doing- I had to pad some images with zero fp16 channel so that stride % 4 == 0- It looks like metric for compression ratio here is based on total size so larger images contribute more; unsure what the detailed ratio comparison is!- I didn't validate whether the libraries are compiled optimally on Linux
(DIR) Post #AvbAzPhY8UcF1Mn89w by zeux@mastodon.gamedev.place
2025-06-26T06:36:41Z
0 likes, 0 repeats
@aras M4 numbers for 1 thread, not as bottlenecked by vector.resize as Linux is - still some cost, but looks like only ~20% of the total decompression time instead of 50%... and probably actually memset in this case, no kernel time.
(DIR) Post #AvbAzQj0KZNECATo48 by zeux@mastodon.gamedev.place
2025-06-27T01:33:08Z
0 likes, 0 repeats
@aras Final post after sprinkling some OpenMP; I had to resize the right chart a little bit :D
(DIR) Post #AvbAzRiKeYQjGNAmem by crystalmoon@chaos.social
2025-06-28T18:58:08Z
0 likes, 0 repeats
@zeux @aras Last I remember the tree encoding step of libjxl was the bottleneck, do you know if they managed to fix that?from the chart I'm kinda embarrassed to see no changes from my time working on it
(DIR) Post #AvbAzSaZOtobyaY6CG by aras@mastodon.gamedev.place
2025-06-28T19:14:29Z
1 likes, 0 repeats
@crystalmoon @zeux I haven't looked where inside libjxl time ends up being spent, and I'm not familiar with that format/code at all. Been talking with them on their discord lately; they said they consistently see JXL being faster than EXR in benchmarks. Turns out... they've been comparing multi-threaded JXL with single-threaded EXR 🤦
(DIR) Post #AvbAzWkzu4X6u5SU0O by zeux@mastodon.gamedev.place
2025-06-25T18:47:56Z
0 likes, 0 repeats
@aras Also for meshopt decompression, std::vector::resize of the target image takes more time than decompression itself - split between actual memset in std::vector and kernel page clearing, which is ironic - so the decompression throughput here is obviously not actually what it should be with a pool of some sort.