|
Kupitman
|
2025-08-05 11:19:11
|
Bro, GitHub.
|
|
2025-08-05 11:20:47
|
https://github.com/libjxl/libjxl/releases/download/v0.11.1/jxl-x64-windows-static.zip
|
|
|
monad
|
2025-08-07 04:01:41
|
I'm back after seven weeks, did anything happen
|
|
|
jonnyawsom3
|
|
monad
I'm back after seven weeks, did anything happen
|
|
2025-08-07 04:20:30
|
v0.12 is releasing soon, patches uses 3x less memory, lossless encoding is 15% faster, effort 1 lossless is actually lossless now
|
|
|
screwball
|
2025-08-07 04:23:44
|
is libjxl C ABI compatible or is it restricted to the C++ ABI? do i have to write bindings n stuff?
|
|
|
|
monad
|
2025-08-07 04:30:16
|
\> effort 1 lossless is actually lossless now
that's what they always say
|
|
|
Quackdoc
|
2025-08-07 05:00:33
|
I always verify [yep](https://cdn.discordapp.com/emojis/721359241113370664.webp?size=48&name=yep)
|
|
|
A homosapien
|
|
monad
\> effort 1 lossless is actually lossless now
that's what they always say
|
|
2025-08-07 05:16:00
|
"The boy who cried lossless"
|
|
|
CrushedAsian255
|
2025-08-07 08:53:18
|
there should be a --verify switch
|
|
2025-08-07 08:53:20
|
like in FLAC
|
|
|
|
Kupitman
|
|
v0.12 is releasing soon, patches uses 3x less memory, lossless encoding is 15% faster, effort 1 lossless is actually lossless now
|
|
2025-08-07 09:41:35
|
When
|
|
|
|
jonnyawsom3
|
|
Kupitman
When
|
|
2025-08-07 10:25:11
|
https://github.com/libjxl/libjxl/issues/4376
|
|
|
|
A homosapien
|
2025-08-08 01:22:19
|
I feel like I could write up a blog post on the jxl website, *"Welcome to libjxl 0.12, after one year in development, hopefully it will have been worth the wait"*
|
|
|
|
Quackdoc
|
2025-08-08 03:13:49
|
is github shitting? I can hardly even open the page
|
|
2025-08-08 03:29:03
|
oh joy, I tried to use jxl-coder's build script and got this issue and ofc the cmake policy stuff breaks
```
CMake Error at third_party/zlib/CMakeLists.txt:1 (cmake_minimum_required):
Compatibility with CMake < 3.5 has been removed from CMake.
Update the VERSION argument <min> value. Or, use the <min>...<max> syntax
to tell CMake that the project requires at least <min> but has been updated
to work with policies introduced by <max> or earlier.
Or, add -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to try configuring anyway.
```
|
|
2025-08-08 03:29:54
|
it seems like it uses their own deps, i wonder if that's an issue?
|
|
2025-08-08 03:31:17
|
positively ancient
|
|
|
Jyrki Alakuijala
|
|
screwball
how does JXL lossless compare to PNG? (encoding speed, file size reduction)
|
|
2025-08-11 05:46:05
|
PNG is fully shadowed by WebP lossless (for 8 bit color dynamics)
|
|
|
A homosapien
I have Google pixel, so all of my photos have been ultraHDR for almost two years now
|
|
2025-08-11 05:49:34
|
I dont like UltraHDR. Its design is against my engineering aesthetics.
|
|
|
|
jonnyawsom3
|
2025-08-11 06:34:00
|
I don't think anyone here likes it
|
|
|
Managor
|
2025-08-12 02:24:49
|
Are you guys waiting for Ladybird to go into Alpha before adding it as a browser that supports JPEG XL?
|
|
|
๐ฐ๐๐๐
|
|
Managor
Are you guys waiting for Ladybird to go into Alpha before adding it as a browser that supports JPEG XL?
|
|
2025-08-12 02:46:53
|
Ladybird is not suitable for use yet.
|
|
|
Demiurge
|
2025-08-14 09:21:22
|
Whenever I see "Ladybird" I read it in Hank Hill's voice
|
|
|
Meow
|
|
|
Demiurge
|
2025-08-15 07:25:56
|
Yeah I don't think of ladybugs at all, I think of Mike Judge
|
|
2025-08-15 07:26:07
|
and propane
|
|
2025-08-15 07:26:14
|
and "that boi ain't right"
|
|
|
|
Meow
|
2025-08-17 03:11:21
|
Would v0.12 be released this month? I'm waiting for it to experiment with the entire collection of the full 120 images of my current avatar
|
|
|
Orum
|
2025-08-17 03:11:58
|
I'm waiting for it too, and I think it's coming soonโข
|
|
2025-08-17 03:12:33
|
But I'll just be patient and wait for the release; there's a tracker issue on GH for 0.12, look up above โคด๏ธ
|
|
|
https://github.com/libjxl/libjxl/issues/4376
|
|
2025-08-17 03:12:47
|
this
|
|
|
|
jonnyawsom3
|
2025-08-17 03:24:54
|
Most things on the todo list are just PRs waiting for approval by other developers. Guess everyone's on holiday or busy with jxl-rs right now
|
|
|
|
Meow
|
2025-08-17 03:49:53
|
As hyped as GPT-5
|
|
2025-08-17 03:50:30
|
v0.12 is going to change the world
|
|
|
|
Kupitman
|
|
|
Meow
|
2025-08-17 02:27:44
|
Wow Homebrew shows a libjxl update!
`jpeg-xl 0.11.1_1 -> 0.11.1_2`
|
|
|
|
jonnyawsom3
|
2025-08-17 02:38:21
|
0.11.1.2?
|
|
|
|
Meow
|
2025-08-17 02:57:41
|
Hmm I'm sure about why it exists
|
|
|
|
Quackdoc
|
2025-08-17 03:50:04
|
probably a dependency update
|
|
|
|
Meow
|
2025-08-17 04:02:17
|
Will `-e 10 -E 4 -I 100 -g 3` remain relevant in v0.12?
|
|
|
|
jonnyawsom3
|
|
Meow
Will `-e 10 -E 4 -I 100 -g 3` remain relevant in v0.12?
|
|
2025-08-17 04:06:32
|
I've proposed defaulting to `-E 1` at effort 9, `-I` will adjust based on effort level and group size is inconsistent... I'm actually finding that `-g 0` results in smaller files a lot of the time with my images
|
|
2025-08-17 04:07:22
|
Issue is none of my forks built and I've been a bit too busy to debug them... So not done complete testing or made a PR yet
|
|
|
|
Meow
|
2025-08-17 04:11:11
|
What will result in the smallest?
|
|
|
|
jonnyawsom3
|
2025-08-17 04:36:16
|
Oh, also I found out that `-Y` is actually harming density by default, so maybe I'll disable that too
Depends on the image. We need to come up with some heuristics or fast trials to do it automatically
|
|
|
|
๐ฐ๐๐๐
|
|
Meow
Would v0.12 be released this month? I'm waiting for it to experiment with the entire collection of the full 120 images of my current avatar
|
|
2025-08-17 04:46:19
|
<:SmileDoge2:1320855554683441163>
|
|
|
|
monad
|
2025-08-17 09:44:15
|
\> everyone wondering when v0.12 will drop
\> me wondering when Jon will have pancakes again
|
|
|
|
Kupitman
|
|
๐ฐ๐๐๐
<:SmileDoge2:1320855554683441163>
|
|
2025-08-17 10:27:01
|
whaaat
|
|
2025-08-17 10:27:48
|
how
|
|
2025-08-17 10:29:32
|
gray images fixed in 0.12?
|
|
|
|
๐ฐ๐๐๐
|
|
Kupitman
how
|
|
2025-08-17 10:37:54
|
git upstream is already `v0.12` now
|
|
|
|
Kupitman
|
|
๐ฐ๐๐๐
git upstream is already `v0.12` now
|
|
2025-08-17 10:44:24
|
how to download it
|
|
|
|
๐ฐ๐๐๐
|
2025-08-17 10:44:44
|
you can't download a git upstream software
|
|
2025-08-17 10:44:49
|
but you can compile it ๐
|
|
|
|
Kupitman
|
2025-08-17 10:45:11
|
i believe gpt give me working command to do it
|
|
|
|
๐ฐ๐๐๐
|
2025-08-17 10:45:15
|
https://github.com/libjxl/libjxl
|
|
|
username
|
|
Kupitman
how to download it
|
|
2025-08-17 10:45:17
|
https://artifacts.lucaversari.it/libjxl/libjxl/latest/
|
|
|
|
Kupitman
|
|
|
๐ฐ๐๐๐
|
|
๐ฐ๐๐๐
https://github.com/libjxl/libjxl
|
|
2025-08-17 10:45:37
|
https://github.com/libjxl/libjxl/blob/main/BUILDING.md
|
|
2025-08-17 10:45:42
|
specifically this page has information
|
|
|
|
Kupitman
|
2025-08-17 10:46:21
|
<:BlobYay:806132268186861619>
|
|
2025-08-17 10:52:40
|
HOW
|
|
2025-08-17 10:52:49
|
cjxl v0.11.1 794a5dcf [AVX2,SSE4,SSE2]
Copyright (c) the JPEG XL Project
|
|
2025-08-17 10:53:05
|
๐ก
|
|
|
|
๐ฐ๐๐๐
|
2025-08-17 10:53:11
|
dunno
|
|
2025-08-17 10:53:23
|
let me rebuild it again
|
|
|
RaveSteel
|
2025-08-17 10:53:25
|
did you download the v11.1 release source code instead of cloning from main?
|
|
|
|
Kupitman
|
2025-08-17 10:53:45
|
what i need to clone
|
|
|
|
RaveSteel
|
2025-08-17 10:53:54
|
https://github.com/libjxl/libjxl
|
|
2025-08-17 10:54:17
|
just run `git clone` on the repo link
|
|
|
|
Kupitman
|
2025-08-17 10:54:24
|
ok
|
|
2025-08-17 10:58:02
|
that not working
|
|
2025-08-17 10:58:14
|
CMake Error at third_party/CMakeLists.txt:100 (message):
|
|
|
|
RaveSteel
|
2025-08-17 10:58:51
|
run this
|
|
2025-08-17 10:58:58
|
`git clone https://github.com/libjxl/libjxl.git --recursive`
|
|
|
|
Kupitman
|
2025-08-17 11:00:10
|
what do next
|
|
|
|
RaveSteel
|
2025-08-17 11:01:08
|
cd into libjxl
|
|
2025-08-17 11:01:21
|
mkdir build && cd build && cmake ../ && make -j$(nproc)
|
|
|
|
๐ฐ๐๐๐
|
|
Kupitman
what do next
|
|
2025-08-17 11:04:41
|
I also have a script
|
|
2025-08-17 11:04:52
|
for static building but it hardcodes clang + polly environment and requires you to build all tools needed for static building
|
|
|
|
Kupitman
|
|
RaveSteel
mkdir build && cd build && cmake ../ && make -j$(nproc)
|
|
2025-08-17 11:04:56
|
<:AngryCry:805396146322145301>
|
|
|
๐ฐ๐๐๐
for static building but it hardcodes clang + polly environment and requires you to build all tools needed for static building
|
|
2025-08-17 11:06:00
|
what i need do
|
|
2025-08-17 11:06:18
|
i really want get 0.12
|
|
2025-08-17 11:07:29
|
stop
|
|
|
|
RaveSteel
|
|
Kupitman
<:AngryCry:805396146322145301>
|
|
2025-08-17 11:08:41
|
You need to run the absolute path to the binary
|
|
|
|
Kupitman
|
2025-08-17 11:08:52
|
i see
|
|
2025-08-17 11:08:59
|
cjxl: error while loading shared libraries: libjxl_threads.so.0.12: cannot open shared object file: No such file or directory
|
|
|
|
RaveSteel
|
2025-08-17 11:09:40
|
Haven't Seen that error before lol
|
|
|
|
๐ฐ๐๐๐
|
2025-08-17 11:09:51
|
well it expects a library in your system
|
|
2025-08-17 11:10:00
|
building software is problematic ๐
|
|
2025-08-17 11:10:09
|
that's why I build statically but it's also a lot of work
|
|
|
|
Kupitman
|
2025-08-17 11:11:14
|
i try something from gpt
|
|
|
|
๐ฐ๐๐๐
|
2025-08-17 11:11:50
|
LLMs generally don't know build details of the most software
|
|
|
|
Kupitman
|
2025-08-17 11:13:24
|
you know?
|
|
|
|
๐ฐ๐๐๐
|
2025-08-17 11:13:25
|
it can give you bunch of bullshit; such as non-existent Cmake arguments
|
|
|
|
username
|
|
Kupitman
i really want get 0.12
|
|
2025-08-17 11:16:17
|
as far as I understand you could download pre-built binaries from the link I sent earlier if you do not want to go through the process of manually compiling
|
|
|
|
๐ฐ๐๐๐
|
|
Kupitman
you know?
|
|
2025-08-17 11:20:29
|
What's your system
|
|
2025-08-17 11:20:32
|
let me build it for you
|
|
2025-08-17 11:20:39
|
I mean hardware (CPU)
|
|
|
|
Kupitman
|
2025-08-17 11:20:46
|
i7-8700
|
|
|
|
๐ฐ๐๐๐
|
2025-08-17 11:21:34
|
`-march=skylake`
|
|
|
|
Kupitman
|
|
|
๐ฐ๐๐๐
|
2025-08-17 11:22:52
|
It's what you use for the compiler for your CPU; so it tunes extra optimization for that arcitechture
|
|
2025-08-17 11:22:59
|
I am compiling
|
|
2025-08-17 11:23:07
|
it will be static; so you won't need any library from your system
|
|
2025-08-17 11:23:20
|
and it will be extremely optimized (be ready for extra speed)
|
|
|
|
Kupitman
|
|
|
๐ฐ๐๐๐
|
|
๐ฐ๐๐๐
I also have a script
|
|
2025-08-17 11:30:45
|
Here all binaries that can be seen here (all git upstream, static, highly optimized) compiled against skylake arc
|
|
|
Kupitman
thx
|
|
2025-08-17 11:30:51
|
ready
|
|
|
|
Kupitman
|
|
๐ฐ๐๐๐
Here all binaries that can be seen here (all git upstream, static, highly optimized) compiled against skylake arc
|
|
2025-08-17 11:31:18
|
yay, personal malware
|
|
2025-08-17 11:31:24
|
<:BlobYay:806132268186861619>
|
|
|
|
๐ฐ๐๐๐
|
2025-08-17 11:31:29
|
please test before running ๐
|
|
|
|
Kupitman
|
2025-08-17 11:32:11
|
terminated by signal SIGILL (Illegal instruction)
lol
|
|
|
|
RaveSteel
|
|
|
๐ฐ๐๐๐
|
|
๐ฐ๐๐๐
please test before running ๐
|
|
2025-08-17 11:32:42
|
|
|
|
|
Kupitman
|
|
|
๐ฐ๐๐๐
|
2025-08-17 11:33:29
|
does it run?
|
|
|
|
Kupitman
|
|
|
๐ฐ๐๐๐
|
2025-08-17 11:33:48
|
๐ maybe because my system is libcxx based
|
|
2025-08-17 11:33:52
|
instead of libstdc++
|
|
|
|
Kupitman
|
2025-08-17 11:33:54
|
i think i'm not on skylake
|
|
|
|
๐ฐ๐๐๐
|
|
Kupitman
i think i'm not on skylake
|
|
2025-08-17 11:34:04
|
...
|
|
|
|
Kupitman
|
2025-08-17 11:34:18
|
google say it coffee lake
|
|
2025-08-17 11:34:28
|
<:kekw:808717074305122316>
|
|
|
|
๐ฐ๐๐๐
|
|
Kupitman
google say it coffee lake
|
|
2025-08-17 11:34:45
|
```sh
gcc -Q --help=target -march=native 2>/dev/null | grep march
```
Try this
|
|
2025-08-17 11:35:09
|
it will tell you the correct march
|
|
|
|
Kupitman
|
2025-08-17 11:35:35
|
-march= skylake
Known valid arguments for -march= option:
waat
|
|
|
|
๐ฐ๐๐๐
|
2025-08-17 11:36:00
|
don't trust google or LLMs against deterministic tools ๐
never ever
|
|
|
|
Kupitman
|
2025-08-17 11:36:07
|
|
|
2025-08-17 11:36:14
|
i can't trust intel????
|
|
2025-08-17 11:36:25
|
wtfff
|
|
|
|
๐ฐ๐๐๐
|
2025-08-17 11:36:26
|
yes, but compilers can use different -march values for specific cpus
|
|
2025-08-17 11:36:44
|
it sucks but it is what it is
|
|
2025-08-17 11:36:50
|
what was the error you get by the way?
|
|
2025-08-17 11:36:56
|
and do you get them for all binaries I sent you?
|
|
2025-08-17 11:37:01
|
like webp, ssimulacra2, etc
|
|
|
|
Kupitman
|
2025-08-17 11:37:17
|
yes
|
|
2025-08-17 11:37:28
|
all
|
|
2025-08-17 11:37:38
|
<:FeelsSadMan:808221433243107338>
|
|
|
|
๐ฐ๐๐๐
|
2025-08-17 11:38:10
|
well march=skylake even works fine on my machine <:kekw:992848817324052601>
|
|
2025-08-17 11:38:28
|
ohh
|
|
2025-08-17 11:38:33
|
maybe I should have disabled avx512
|
|
2025-08-17 11:38:39
|
but you said it was for all binaries
|
|
2025-08-17 11:38:46
|
some of them don't even have avx512 support
|
|
|
|
Kupitman
|
2025-08-17 11:39:31
|
lol
|
|
2025-08-17 11:39:34
|
gpt say too
|
|
|
|
jonnyawsom3
|
|
Kupitman
gray images fixed in 0.12?
|
|
2025-08-17 11:39:36
|
No
|
|
|
username
as far as I understand you could download pre-built binaries from the link I sent earlier if you do not want to go through the process of manually compiling
|
|
2025-08-17 11:40:03
|
Also Username already gave you official binaries to download when you first asked for v0.12
|
|
2025-08-17 11:40:16
|
https://artifacts.lucaversari.it/libjxl/libjxl/latest/
|
|
|
|
Kupitman
|
|
Also Username already gave you official binaries to download when you first asked for v0.12
|
|
2025-08-17 11:40:58
|
I didn't understand how to use them...
|
|
|
|
jonnyawsom3
|
|
Kupitman
I didn't understand how to use them...
|
|
2025-08-17 11:42:12
|
Download the file that matches your OS, then extract the zip and run cjxl
|
|
|
|
๐ฐ๐๐๐
|
|
Kupitman
I didn't understand how to use them...
|
|
2025-08-17 11:42:20
|
`jxl-linux-x86_64-static.zip 15-Aug-2025 15:28 17019862`
|
|
|
|
Kupitman
|
2025-08-17 11:42:37
|
how open it from konsole
|
|
|
|
๐ฐ๐๐๐
|
2025-08-17 11:42:47
|
unzip that first
|
|
|
|
Kupitman
|
2025-08-17 11:43:03
|
i mean don't copy full path
|
|
2025-08-17 11:43:08
|
always
|
|
|
|
๐ฐ๐๐๐
|
|
Kupitman
i mean don't copy full path
|
|
2025-08-17 11:44:32
|
just click on the hyprerlink
|
|
|
|
Kupitman
|
|
|
jonnyawsom3
|
2025-08-17 11:45:04
|
Here's a WIP changelog for v0.12 <https://github.com/jonnyawsom3/libjxl/blob/patch-1/CHANGELOG.md>
|
|
|
|
๐ฐ๐๐๐
|
2025-08-17 11:45:07
|
Then:
```sh
unzip jxl-linux-x86_64-static.zip
tar -xzvf jxl-linux-x86_64-static.tar.gz
# it will be in tools
```
|
|
|
https://artifacts.lucaversari.it/libjxl/libjxl/latest/
|
|
2025-08-17 11:45:25
|
click on this link; or open with a browser
|
|
2025-08-17 11:45:41
|
then click here
|
|
|
๐ฐ๐๐๐
Then:
```sh
unzip jxl-linux-x86_64-static.zip
tar -xzvf jxl-linux-x86_64-static.tar.gz
# it will be in tools
```
|
|
2025-08-17 11:45:52
|
then you can apply these commands to extract the binaries
|
|
|
|
Kupitman
|
2025-08-17 11:46:16
|
Significant improvements to EXR input handling. Now supports float32, multilayer and per-channel bitdepth.
that doesn't fix gray images?
|
|
|
|
jonnyawsom3
|
2025-08-17 11:47:22
|
Unless your gray image is float32, multilayer or variable bitdepth EXR, no
|
|
|
|
Kupitman
|
|
๐ฐ๐๐๐
Then:
```sh
unzip jxl-linux-x86_64-static.zip
tar -xzvf jxl-linux-x86_64-static.tar.gz
# it will be in tools
```
|
|
2025-08-17 11:47:46
|
and???
|
|
2025-08-17 11:47:57
|
how open it from path
|
|
|
|
๐ฐ๐๐๐
|
2025-08-17 11:48:00
|
there is no and; you have the binaries in the tools folder ๐
|
|
2025-08-17 11:48:12
|
you need to move them to `/home/username/.local/bin`
|
|
2025-08-17 11:48:21
|
and delete your current JXL package / binaries
|
|
|
|
Kupitman
|
2025-08-17 11:49:08
|
doesn't have permission
|
|
|
๐ฐ๐๐๐
and delete your current JXL package / binaries
|
|
2025-08-17 11:50:41
|
real...
|
|
2025-08-17 11:50:47
|
:: removing libjxl breaks dependency 'libjxl' required by ayugram-desktop
:: removing libjxl breaks dependency 'libjxl' required by ffmpeg
:: removing libjxl breaks dependency 'libjxl.so=0.11-64' required by ffmpeg
:: removing libjxl breaks dependency 'libjxl' required by opencv
:: removing libjxl breaks dependency 'libjxl' required by sdl2_image
:: removing libjxl breaks dependency 'libjxl' required by webkit2gtk-4.1
|
|
|
|
๐ฐ๐๐๐
|
2025-08-17 11:51:02
|
HMMM
|
|
2025-08-17 11:51:04
|
then do this
|
|
2025-08-17 11:51:17
|
just find cjxl, dxjl binaries and force delete them
|
|
2025-08-17 11:51:21
|
and change them with the newer ones
|
|
2025-08-17 11:51:27
|
the other tools will probably work, still
|
|
|
|
Kupitman
|
2025-08-17 11:52:05
|
<:AngryCry:805396146322145301>
|
|
2025-08-17 11:52:41
|
<:FeelsAmazingMan:808826295768449054>
|
|
2025-08-17 11:52:53
|
thanks!
|
|
|
|
jonnyawsom3
|
|
๐ฐ๐๐๐
the other tools will probably work, still
|
|
2025-08-18 12:05:00
|
Yeah, no API changes in this version AFAIK
|
|
|
|
A homosapien
|
|
Kupitman
gray images fixed in 0.12?
|
|
2025-08-18 12:33:23
|
gray images fixed how?
|
|
|
|
Meow
|
2025-08-18 01:43:48
|
I will still wait for the official release
|
|
|
|
Orum
|
2025-08-18 02:00:57
|
oh, whoops, didn't see that they'd already been pinged...
|
|
|
|
Meow
|
|
A homosapien
gray images fixed how?
|
|
2025-08-18 02:08:15
|
He might mean the poor opitimisation of greyscale non-photographic images
|
|
2025-08-18 02:10:17
|
|
|
2025-08-18 02:10:18
|
I don't think it's addressed in v0.12
|
|
|
|
A homosapien
|
2025-08-18 02:21:35
|
libjxl can compress grayscale images well, its the defaults that are not good for those kinds images.
|
|
|
|
Orum
|
2025-08-18 02:25:24
|
yeah they've been talking about improving the heuristics for forever
|
|
2025-08-18 02:25:34
|
but it's usually something that gets pushed to the back burner
|
|
|
|
username
|
2025-08-18 02:29:18
|
focus is on adoption ATM so most of the devs are working on jxl-rs
|
|
|
|
Kupitman
|
|
A homosapien
gray images fixed how?
|
|
2025-08-18 02:34:48
|
Over bit used, 24 for only 8 gray.
|
|
|
|
Orum
|
2025-08-18 02:35:17
|
even if you feed it a pgm?
|
|
|
|
Kupitman
|
2025-08-18 02:35:43
|
Not tested
|
|
|
|
Orum
|
2025-08-18 02:37:55
|
works fine:
```
$ cjxl -d 0 -e 2 test.pgm test.jxl
JPEG XL encoder v0.11.1 794a5dcf [AVX3,AVX2,SSE4,SSE2]
Encoding [Modular, lossless, effort: 2]
Compressed to 4720 bytes (0.039 bpp).
1343 x 712, 42.400 MP/s [42.40, 42.40], , 1 reps, 32 threads.
$ jxlinfo test.jxl
JPEG XL image, 1343x712, (possibly) lossless, 8-bit Grayscale
Color space: Grayscale, D65, sRGB transfer function, rendering intent: Relative
```
|
|
|
|
A homosapien
|
|
Kupitman
Over bit used, 24 for only 8 gray.
|
|
2025-08-18 02:42:52
|
The PNG input has to be grayscale. Libjxl lacks the ability to detect and convert to grayscale like Oxipng.
|
|
|
|
Orum
|
2025-08-18 02:43:49
|
wait, what the hell is AVX3?
|
|
|
|
A homosapien
|
2025-08-18 02:44:37
|
Another name for AVX512
|
|
2025-08-18 02:44:42
|
I think
|
|
|
|
Orum
|
2025-08-18 02:45:03
|
why not just call it what it's actually called?
|
|
|
|
A homosapien
|
2025-08-18 02:51:58
|
ยฏ\_(ใ)_/ยฏ
|
|
|
|
Meow
|
2025-08-18 03:50:20
|
and the successor is called... AVX10
|
|
|
|
Orum
|
2025-08-18 03:51:21
|
yep... they're worse at counting than George Lucas
|
|
|
Mine18
|
|
username
focus is on adoption ATM so most of the devs are working on jxl-rs
|
|
2025-08-18 06:31:54
|
jxl-rs to the rescue!
|
|
|
|
Meow
|
2025-08-18 06:50:35
|
I read it as ATM adoption initially. Time for all ATMs to use JXL
|
|
|
I've proposed defaulting to `-E 1` at effort 9, `-I` will adjust based on effort level and group size is inconsistent... I'm actually finding that `-g 0` results in smaller files a lot of the time with my images
|
|
2025-08-18 08:17:05
|
How about simply `-e 11` instead?
|
|
2025-08-18 03:47:39
|
Still too slow for me
|
|
|
|
screwball
|
2025-08-18 04:01:43
|
apparently on IOS, jxl images dont have photon noise when viewed through the Files app
they only have it when viewed through the Camera/Photos app
|
|
|
|
Meow
|
|
I've proposed defaulting to `-E 1` at effort 9, `-I` will adjust based on effort level and group size is inconsistent... I'm actually finding that `-g 0` results in smaller files a lot of the time with my images
|
|
2025-08-18 04:18:15
|
Uh `-g 0` resulted in larger for mine and it took much longer time
|
|
|
|
jonnyawsom3
|
|
Meow
Uh `-g 0` resulted in larger for mine and it took much longer time
|
|
2025-08-18 04:24:17
|
It took longer? By how much?
|
|
|
|
Meow
|
2025-08-18 04:25:50
|
354.9 seconds for `-g 3` but 1531.99 seconds by `-g 0` for a sample
|
|
|
|
jonnyawsom3
|
2025-08-18 05:05:40
|
5x longer is an extreme difference. Best case I see 6% faster and worst case 27% slower using `-g 3` compared to `-g 0` on a 4K image
|
|
|
_Broken sฬธyฬดmฬดmฬตฬฟeฬดออtฬธrฬตฬฬฟyฬดอ อ
|
2025-08-18 09:44:02
|
For anyone *on Linux* that frequently uses the verbose help to look through the options and their parameters, here is a little thing that may make the reading easier.
Since (at least on my side) the options / option names and their description are written right underneath each other, with out an additional line-break for separation.
This makes it hard for me to read / find an option that I'm looking for.
Luckily you can colour text patterns using grep. Even though it is rudimentary, it does help on my side.
```
cjxl -v -v -v -v | grep -E "\s+-[a-zA-Z]|--[0-9a-zA-Z_=\|-]+|[0-9]\|[0-9\|]+|$" --color=always | less -r
```
```
djxl -v -v | grep -E "\s+-[a-zA-Z]|--[0-9a-zA-Z_=\|#-]+|[0-9]\|[0-9\|]+|$" --color=always | less -r
```
-# "| less -r" is optional
-# Also, since this is using grep, in-case something is missing, look at help with-out grep colouring. (Should not happen, but incase)
Hope this is useful to someone ๐ฆฆ
-# Also hope this is correct channel to share that;
|
|
|
|
Meow
|
|
5x longer is an extreme difference. Best case I see 6% faster and worst case 27% slower using `-g 3` compared to `-g 0` on a 4K image
|
|
2025-08-19 01:44:37
|
I used a non-photographic image (variant of my avatar)
|
|
|
|
jonnyawsom3
|
2025-08-19 01:46:13
|
I did too, non-photographic that is
|
|
|
|
Meow
|
2025-08-19 01:48:03
|
Mine is with an Alpha channel (transparent background)
|
|
|
|
jonnyawsom3
|
2025-08-19 04:40:03
|
Did you only change group size between the commands?
|
|
|
|
Meow
|
2025-08-19 05:14:21
|
The only difference is `-g`
|
|
2025-08-19 05:15:28
|
so I was pretty surprised at how it encoded drastically slower by simply changing `-g` from 3 to 0
|
|
2025-08-19 05:16:23
|
and larger as well as even closer to simply `-e 10`
|
|
|
|
Kupitman
|
2025-08-19 07:20:08
|
I didn't see changes
|
|
2025-08-19 07:20:31
|
#fixgrayimages
|
|
|
|
screwball
|
2025-08-19 08:06:45
|
I read somewhere that JXL has a specific mode for compressing โsynthetic imageryโ
Is that accurate or is that just referring to lossless mode?
|
|
|
|
username
|
|
screwball
I read somewhere that JXL has a specific mode for compressing โsynthetic imageryโ
Is that accurate or is that just referring to lossless mode?
|
|
2025-08-19 09:38:06
|
just the lossless mode afaik
|
|
|
|
screwball
|
|
username
just the lossless mode afaik
|
|
2025-08-19 09:45:30
|
ok that makes sense
|
|
|
|
monad
|
|
5x longer is an extreme difference. Best case I see 6% faster and worst case 27% slower using `-g 3` compared to `-g 0` on a 4K image
|
|
2025-08-19 11:20:29
|
worst case I found
```v0.12.0 dc8438ad, 0 threads, 3 reps
B enc MP/s dec MP/s enc cmd
16071 1.386 32.508 d0e10E3I100g3
16312 0.132 22.749 d0e10E3I100g0```
|
|
|
|
jonnyawsom3
|
2025-08-19 12:30:03
|
Wow, decode speed is even worse too... We made `--faster_decoding 2` use `-g 0`, but apparently those results either weren't consistent or were OS dependant
|
|
|
|
Meow
|
2025-08-19 12:30:53
|
I tested on macOS 15.6 with libjxl v0.11.1 installed via Homebrew
|
|
|
Traneptora
|
2025-08-19 03:39:37
|
we did it!
|
|
2025-08-19 03:39:39
|
|
|
2025-08-19 03:39:54
|
EXIF for ffmpeg, including with JPEG XL support
|
|
|
|
Quackdoc
|
2025-08-19 04:35:57
|
Nice! ~~now we just need mkv support~~
|
|
|
DZgas ะ
|
|
Meow
and the successor is called... AVX10
|
|
2025-08-19 05:30:59
|
sus
|
|
|
|
monad
|
|
Wow, decode speed is even worse too... We made `--faster_decoding 2` use `-g 0`, but apparently those results either weren't consistent or were OS dependant
|
|
2025-08-19 10:18:07
|
More likely a fixation on multithreading, but I've pointed that out before.
|
|
|
|
jonnyawsom3
|
|
monad
More likely a fixation on multithreading, but I've pointed that out before.
|
|
2025-08-19 10:19:57
|
We tested singlethreaded and it was still faster
|
|
2025-08-19 10:22:29
|
g1 `3840 x 2160, geomean: 4.247 MP/s [4.20, 4.27], , 5 reps, 0 threads.`
g0 `3840 x 2160, geomean: 4.651 MP/s [4.47, 4.70], , 5 reps, 0 threads.`
|
|
|
|
Quackdoc
|
2025-08-27 06:49:00
|
a15 qpr2 doesn't seem to recognize jxl any more, at least LOS 22.2 doesn't. this means iacobionuts app no longer works for jxl
|
|
|
|
screwball
|
2025-08-28 03:22:09
|
im curious why theres jxl-rs *and* jxl-oxide being developed separately, instead of combining forces to build a decoder in less time
|
|
2025-08-28 03:23:07
|
do they have different goals?
|
|
|
HCrikki
|
2025-08-28 03:55:01
|
jxl-rs is only a decoder
|
|
2025-08-28 03:55:22
|
oxide does encode and decode
|
|
|
Fahim
|
|
HCrikki
oxide does encode and decode
|
|
2025-08-28 04:01:51
|
Pretty sure it's the other way around, oxide is decode-only
|
|
|
Tirr
|
2025-08-28 04:12:22
|
both are decode-only for now
|
|
|
|
jonnyawsom3
|
2025-08-28 06:01:44
|
Tirr developed Oxide, and has been helping with jxl-rs for months. So they're not separate either
|
|
2025-08-28 06:02:45
|
The current encoders are libjxl, fjxl, sjxl (fast lossless and simple lossless) and hydrium
|
|
|
|
username
|
2025-08-28 06:07:36
|
your forgetting one. I don't remember the name of it but it's a port of fjxl to Rust
|
|
2025-08-28 06:08:43
|
sjxl didn't exist at the time but it might be closer to it since idk if the Rust port of fjxl retains the written out SIMD
|
|
|
|
jonnyawsom3
|
2025-08-28 06:27:07
|
I'm not really sure I'd call a port a new encoder
|
|
|
|
username
|
2025-08-28 06:29:23
|
I mean sjxl is just a simplified standalone version of fjxl and fjxl functions as effort 1 in libjxl sooo I would say it's fine to count it
|
|
|
|
Kupitman
|
|
The current encoders are libjxl, fjxl, sjxl (fast lossless and simple lossless) and hydrium
|
|
2025-08-28 07:02:54
|
Hydrium lossy
|
|
|
|
jonnyawsom3
|
2025-08-28 07:09:09
|
Correct
|
|
|
|
Kupitman
|
|
|
screwball
|
|
Tirr
both are decode-only for now
|
|
2025-08-28 07:27:53
|
wait so, oxide is supposed to be decode-only, while rs is eventually going to be encode and decode?
|
|
2025-08-28 07:28:01
|
or is it the other way around?
|
|
|
|
jonnyawsom3
|
2025-08-28 07:30:15
|
Neither. Both are decoders. We'll see what happens when they're complete but there are no plans for now
|
|
|
|
Tirr
|
2025-08-28 07:31:38
|
I do plan to add simple bitstream editing feature in jxl-oxide *someday*, but not full encoder though
|
|
|
|
screwball
|
|
Neither. Both are decoders. We'll see what happens when they're complete but there are no plans for now
|
|
2025-08-28 07:32:04
|
alright
well even if they have cross communication between the projects, im still confused why theres 2 of them
but i guess more options is not a bad thing
|
|
|
|
jonnyawsom3
|
2025-08-28 07:32:45
|
Because Oxide is owned by Tirr, jxl-rs is run by Google. Username will explain
|
|
|
|
username
|
2025-08-28 07:34:55
|
jxl-oxide is made by Tirr. jxl-rs is made by the libjxl devs + Tirr and exists because Mozilla refuses to add JXL support to Firefox unless a decoder is made for them by Google
|
|
2025-08-28 07:35:02
|
not 100% if it's just restricted to Google or more so that they won't accept a decoder that isn't made by a large entity that can give some kind of guarantee of continued support.
|
|
2025-08-28 07:36:20
|
so a big reason jxl-rs is currently being developed is just so that Firefox will finally add full support for JXL and hopefully enable it by default for all users
|
|
|
|
screwball
|
|
username
so a big reason jxl-rs is currently being developed is just so that Firefox will finally add full support for JXL and hopefully enable it by default for all users
|
|
2025-08-28 07:37:30
|
i see
so, that does not mean that libjxl is also a google project, correct? its entirely independent from google, and jxl-rs is an isolated google collaboration?
|
|
|
|
jonnyawsom3
|
2025-08-28 07:38:39
|
libjxl is also Google owned, hence the Google CLI every contributor has to sign
|
|
|
|
username
|
2025-08-28 07:39:26
|
the existence of JPEGย XL and libjxl is in large part due to one of the research divisions at Google afaik
|
|
2025-08-28 07:40:33
|
a lot of the main libjxl devs are Google employees and while the libjxl repo isn't directly registered as a Google repo is does have the Google CLI and stuff yeah
|
|
|
|
jonnyawsom3
|
2025-08-28 07:42:58
|
"it's complicated"
|
|
|
|
screwball
|
|
username
a lot of the main libjxl devs are Google employees and while the libjxl repo isn't directly registered as a Google repo is does have the Google CLI and stuff yeah
|
|
2025-08-28 07:43:04
|
ok i understand now
|
|
2025-08-28 07:43:09
|
๐
|
|
|
|
Meow
|
2025-08-28 07:46:37
|
Specifically, Google Zรผrich
|
|
|
|
veluca
|
2025-08-28 07:56:08
|
jxl-rs also took some different decisions impl-wise than jxl-oxide (for better performance/less memory usage), that when we started we believed would be too much effort to change in jxl-oxide
|
|
|
|
jonnyawsom3
|
2025-08-28 08:19:37
|
Applying the lessons learnt from libjxl and Oxide over the years
|
|
|
|
screwball
|
2025-08-28 08:22:23
|
i know that the encoding process is very parallel-friendly, but is decoding also friendly to parallelization?
and do jxl-rs or jxl-oxide allow you to decode using multiple threads? (ive never even looked at their APIs before)
|
|
|
|
jonnyawsom3
|
2025-08-28 08:28:32
|
Every JXL file is encoded using groups, and every group can be decoded per thread. Last I checked jxl-rs isn't threaded yet, but is being worked on
|
|
|
|
screwball
|
|
Every JXL file is encoded using groups, and every group can be decoded per thread. Last I checked jxl-rs isn't threaded yet, but is being worked on
|
|
2025-08-28 08:31:26
|
wonderful
|
|
|
|
veluca
|
|
Every JXL file is encoded using groups, and every group can be decoded per thread. Last I checked jxl-rs isn't threaded yet, but is being worked on
|
|
2025-08-28 09:07:53
|
I am hoping to get to this in this or next week, but I am super busy ๐
|
|
|
|
username
|
2025-08-28 09:17:54
|
<@179701849576833024> what are the plans in relation to Firefox/Gecko integration? I see that zond has been working on a fork of Firefox adding support so is it the intention for that to end up being submitted to Mozilla for review or just for purely testing?
|
|
|
|
veluca
|
2025-08-28 09:18:22
|
first one ๐
|
|
|
|
username
|
2025-08-28 09:19:34
|
oo nice. a suggestion I have is if possible to maybe look into adding a entry to `about:config` to allow changing the progressive mode used for decoding
|
|
2025-08-28 09:21:03
|
as far as I understand jxl-rs has multiple modes for attempting progressive decode and it would be really nice/handy to be able to switch between them without a full browser recompile
|
|
2025-08-28 09:26:01
|
https://github.com/libjxl/jxl-rs/blob/main/jxl/src/api/options.rs#L6
|
|
|
|
jonnyawsom3
|
|
username
as far as I understand jxl-rs has multiple modes for attempting progressive decode and it would be really nice/handy to be able to switch between them without a full browser recompile
|
|
2025-08-28 09:26:05
|
Why though? Surely you'd just want the most progressive so the browser can request based on download speed. Otherwise it's what libjxl does with 1:8, or non-progressive
|
|
|
|
username
|
|
Why though? Surely you'd just want the most progressive so the browser can request based on download speed. Otherwise it's what libjxl does with 1:8, or non-progressive
|
|
2025-08-28 09:27:01
|
iirc the implementation zond is working on is set to `Pass` which I assume is for performance
|
|
2025-08-28 09:27:29
|
I would go check but the Github page starts dying when I try to look at it
|
|
|
|
jonnyawsom3
|
2025-08-28 09:27:53
|
Right now lossless is pretty much always FullFrame, and lossy always Pass when encoding with libjxl. After v0.12, both will be using Eager compatible encoding (For lossless, making progressive actually feasable)
|
|
|
|
username
|
2025-08-28 09:32:09
|
my internet is so much slower then my computer so I would love to be able to switch the mode to `Eager` via `about:config` when jxl-rs lands in Firefox/Gecko
|
|
|
|
veluca
|
|
username
my internet is so much slower then my computer so I would love to be able to switch the mode to `Eager` via `about:config` when jxl-rs lands in Firefox/Gecko
|
|
2025-08-28 09:50:23
|
I would be surprised if that's really true ๐
|
|
|
|
username
|
|
veluca
I would be surprised if that's really true ๐
|
|
2025-08-28 09:52:56
|
https://cdn.discordapp.com/attachments/863102954965696513/1094856331548184626/image.png
|
|
2025-08-28 09:56:19
|
it used to be even slower: https://cdn.discordapp.com/attachments/594583298131623937/1084933719854415982/image.png
|
|
2025-08-28 09:59:56
|
either way having a switch in `about:config` would still be nice for testing purposes at the very least
|
|
|
|
jonnyawsom3
|
2025-08-28 10:04:24
|
That's still a decent speed, you sure it's not the 500 open tabs you have?
|
|
2025-08-28 10:05:51
|
Now *this* is when I was begging for LQIP JXL loading
|
|
|
username
iirc the implementation zond is working on is set to `Pass` which I assume is for performance
|
|
2025-08-28 10:42:42
|
As far as I can tell it's just using the default, which is Pass. I'm not sure what kind of loading behaviour Firefox has, but I feel like either it will be slow enough that it only calls for Pass anyway, or it's smart enough for Eager to be used by default (Plus one of the selling points for JXL is the Eager progressiveness, which only Oxide shows currently)
|
|
|
|
Kupitman
|
|
username
https://cdn.discordapp.com/attachments/863102954965696513/1094856331548184626/image.png
|
|
2025-08-28 12:39:51
|
Lol
|
|
|
|
A homosapien
|
2025-08-28 12:44:36
|
Italy's 4G speeds are no joke
|
|
2025-08-28 12:45:04
|
Speedtest.net wouldn't even load for me
|
|
|
|
Kupitman
|
2025-08-28 12:51:07
|
HAHAHAHAHAA
|
|
|
A homosapien
Italy's 4G speeds are no joke
|
|
2025-08-28 12:51:37
|
I have similar speed only on egypt free wifi
|
|
2025-08-28 12:51:51
|
You pay for that?!
|
|
|
|
jonnyawsom3
|
|
A homosapien
Italy's 4G speeds are no joke
|
|
2025-08-28 12:53:27
|
You beat my speeds in Spain, but not my ping. God we need JXL
|
|
|
|
A homosapien
|
|
Kupitman
You pay for that?!
|
|
2025-08-28 12:55:01
|
Yes ๐
|
|
2025-08-28 12:55:34
|
I live in the USA so I'm glad my coverage extends to Italy but it's painful
|
|
|
|
screwball
|
2025-08-29 04:19:06
|
is it barbaric to have my program directly call into cjxl as a child process, instead of properly integrating the libjxl library?
i can theoretically feed cjxl some .ppm files just fine
|
|
|
|
Quackdoc
|
2025-08-29 05:50:36
|
nope, lots of people do it, it's not flexible, nor is it reliable, but if it works it works.
|
|
|
_wb_
|
2025-08-29 10:13:07
|
if you're lucky, the OS will keep a temporary ppm in memory and not actually write it to disk if it's deleted before it's flushing its cache. To be sure, you can use a ramdisk for the temp files. With temp ppm files in memory, the difference between calling cjxl and properly integrating libjxl should not be that big...
|
|
|
|
jonnyawsom3
|
2025-08-29 10:14:43
|
Or a pipe
|
|
|
|
Traneptora
|
|
screwball
is it barbaric to have my program directly call into cjxl as a child process, instead of properly integrating the libjxl library?
i can theoretically feed cjxl some .ppm files just fine
|
|
2025-08-29 05:35:35
|
minimal reason not to use the library if you're calling it from c or c++
|
|
|
|
screwball
|
|
Traneptora
minimal reason not to use the library if you're calling it from c or c++
|
|
2025-08-29 05:36:51
|
Calling it from Zig
Using external dependencies undoubtedly is my weakest skill
|
|
2025-08-29 05:42:00
|
And frankly, Iโm not too worried about performance
|
|
2025-08-29 05:42:17
|
I know that doing it this way is going to be noticeably slower
|
|
2025-08-29 05:42:38
|
It doesnโt really matter for this
|
|
|
|
Quackdoc
|
2025-08-31 12:19:42
|
does `djxl` have anything it can do like streaming input/output to lower ram usage? trying to benchmark decoding ram usage of various things and libjxl and jxl-oxide are quite high peak usages
|
|
|
|
Orum
|
2025-08-31 12:28:42
|
it's rather interesting that fast decode 4 sometimes results in smaller files than 0 (for lossless images)
|
|
2025-08-31 12:29:29
|
```
121682002 tjs_fd0.jxl
121680618 tjs_fd4.jxl
```
|
|
2025-08-31 12:30:35
|
the difference is negligible, sure, but it's still interesting
|
|
|
|
jonnyawsom3
|
2025-08-31 05:54:36
|
Huh, interesting
|
|
|
Orum
it's rather interesting that fast decode 4 sometimes results in smaller files than 0 (for lossless images)
|
|
2025-08-31 09:14:26
|
Is that on main?
|
|
2025-08-31 09:28:08
|
<https://www.reddit.com/r/softwaregore/s/5BFyIrW9Le>
Hmm, is there any conversion tool that reads the depth maps? Could be an easy way to make JXLs with a depth channel
|
|
2025-09-02 11:46:04
|
Was thinking of this chart again earlier tonight. It was previously said that the middle "JXL to JPEG" path wasn't worth the effort, but effort 4 JXL could *maybe* fit into standard JPEG, based on how JPEGLI does AQ, XYB, ect. Just a thought, but worth mentioning
|
|
|
|
screwball
|
2025-09-03 02:42:46
|
is the windows 11 image viewer not able to display JXL files with a wider color gamut? i rendered a PNG out of blender using Rec2020
it looks completely fine in image viewer as a png, but the JXL variant is severely desaturated
i know the issue is not with the JXL because gimp is able to display it perfectly
|
|
|
|
jonnyawsom3
|
2025-09-03 02:59:14
|
Do you have HDR enabled?
|
|
|
|
HCrikki
|
2025-09-03 03:02:36
|
share a sample image that doesnt render properly?
if its not true hdr but gainmaped, a newer libjxl added that support but the extension might be based on an older libjxl snapshot
|
|
|
|
jonnyawsom3
|
2025-09-03 03:16:15
|
Blender doesn't have gainmaps
|
|
|
|
screwball
|
|
Do you have HDR enabled?
|
|
2025-09-03 03:19:50
|
no, my monitor is most likely just sRGB or something, its a basic one
|
|
|
HCrikki
share a sample image that doesnt render properly?
if its not true hdr but gainmaped, a newer libjxl added that support but the extension might be based on an older libjxl snapshot
|
|
2025-09-03 03:20:25
|
idk what a gainmap is but if its anything jxl specific, that info is not coming from the png
|
|
2025-09-03 03:20:31
|
give me a moment
|
|
2025-09-03 03:21:29
|
ok so here is a test render
like i said before, the PNG is Rec2020 and looks identical to how it looked inside blender
|
|
2025-09-03 03:21:56
|
the JXL file looks perfect in gimp but looks desaturated in windows image viewer
|
|
2025-09-03 03:22:39
|
if this is related to rendering intent (i usually choose Perceptual in gimp) then i have no idea how to tell windows image viewer that
|
|
|
|
Meow
|
|
screwball
idk what a gainmap is but if its anything jxl specific, that info is not coming from the png
|
|
2025-09-03 03:33:57
|
Gainmap isn't included with PNG until its upcoming 4th spec
|
|
|
|
username
|
|
screwball
the JXL file looks perfect in gimp but looks desaturated in windows image viewer
|
|
2025-09-03 06:38:13
|
there's a good chance Microsoft's software just doesn't do proper HDR for JXL. The only thing I know that's almost guarantied to work is [Thorium](https://thorium.rocks/) (fork of Chromium) although it's a full web browser rather then an image viewer.. afaik there isn't anything about JXL that makes it hard to do HDR it's just that most software and companies just suck at supporting HDR stuff
|
|
|
|
Meow
|
2025-09-03 07:30:14
|
No other image viewer for proper HDR of JXL?
|
|
|
NovaZone
|
2025-09-03 07:33:19
|
qview probly can
|
|
2025-09-03 07:35:42
|
granted on sdr but colors look the same between the 2 on qview
|
|
|
|
HCrikki
|
2025-09-03 07:42:15
|
zoner supposedly fully supports hdr jxl (view and edit). should be verified on a machine that is actually hdr-ready
|
|
2025-09-03 08:00:32
|
imageglass supposedly fixed a similar issue in february. check if it displays fine
|
|
2025-09-03 08:00:54
|
https://github.com/d2phap/ImageGlass
|
|
|
|
Meow
|
2025-09-03 08:01:26
|
Cannot check when there's no HDR display๐ญ
|
|
|
|
Mine18
|
|
screwball
the JXL file looks perfect in gimp but looks desaturated in windows image viewer
|
|
2025-09-03 09:13:21
|
try third party image viewers, like imageglass and nomacs
|
|
|
|
Kupitman
|
|
HCrikki
https://github.com/d2phap/ImageGlass
|
|
2025-09-03 09:24:26
|
xnviewmp >
|
|
2025-09-03 09:24:50
|
imageglass always have issue
|
|
|
Lilli
|
|
HCrikki
https://github.com/d2phap/ImageGlass
|
|
2025-09-03 09:35:48
|
been using that as my image viewer for a few years now, I like it. Support for SVGs could use a lot of improvements, but it's overall great
|
|
|
|
Mine18
|
2025-09-03 09:52:07
|
ive been using imageglass for a while but switched to nomacs as it has better animation support (animated png, webp, avif, jxl)
|
|
|
|
NovaZone
|
2025-09-03 10:26:02
|
wonder if imglass ever fixed the gif playback speed issue ๐คฃ
|
|
|
|
Orum
|
2025-09-08 10:57:57
|
is there a guide somewhere on the tuning options that are useful for non-photo (both lossy and lossless)?
|
|
|
|
monad
|
|
Orum
is there a guide somewhere on the tuning options that are useful for non-photo (both lossy and lossless)?
|
|
2025-09-09 02:14:25
|
Not a guide, but I have large dumps of lossless measurements over my personal 8bpc collection focusing on encode compute/density efficiency. It's from libjxl 0.10 as 0.11 wasn't noticeably different.
Practical-effort: https://monad.observer/jxl/bench/20240517#contents
High-effort (including multi-command): https://monad.observer/jxl/bench/20240506#contents
Example insights:
3D renders and digital paintings: cjxl_0.10.1_d0e7E4g3num_threads0 measured 10x faster for similar density to cjxl_0.10.1_d0e10num_threads0
text: cjxl_0.10.1_d0e10P0I0g3modular_palette_colors10000num_threads0 measured 4x faster for similar density to cjxl_0.10.1_d0e10num_threads0
scaled pixel art: cjxl_0.10.1_d0e1num_threads0 measured 7x faster for 2x density compared to cjxl_0.10.1_d0e3num_threads0
|
|
|
|
Meow
|
2025-09-09 02:15:08
|
I use JXL for non-photographic images only
|
|
|
|
Orum
|
|
monad
Not a guide, but I have large dumps of lossless measurements over my personal 8bpc collection focusing on encode compute/density efficiency. It's from libjxl 0.10 as 0.11 wasn't noticeably different.
Practical-effort: https://monad.observer/jxl/bench/20240517#contents
High-effort (including multi-command): https://monad.observer/jxl/bench/20240506#contents
Example insights:
3D renders and digital paintings: cjxl_0.10.1_d0e7E4g3num_threads0 measured 10x faster for similar density to cjxl_0.10.1_d0e10num_threads0
text: cjxl_0.10.1_d0e10P0I0g3modular_palette_colors10000num_threads0 measured 4x faster for similar density to cjxl_0.10.1_d0e10num_threads0
scaled pixel art: cjxl_0.10.1_d0e1num_threads0 measured 7x faster for 2x density compared to cjxl_0.10.1_d0e3num_threads0
|
|
2025-09-09 02:16:32
|
not quite sure how to interpret this data
|
|
2025-09-09 02:17:31
|
I just want to know what params to play with; IIRC `-g` and `-I` were two
|
|
2025-09-09 02:17:48
|
and I think sometimes `-P`?
|
|
|
|
monad
|
2025-09-09 02:30:14
|
Higher `g` generally implies denser at a cost of multi-threaded decode speed.
Higher `I` generally implies denser at a cost of encode speed.
`P0` can be good for particular content especially with flat colors. Most others don't compete with `P15` for density, but particularly options outside `P14`, `P6`, `P4`, `P5` aren't worth looking at in my experience.
|
|
|
|
Orum
|
2025-09-09 02:31:49
|
any of them useful for lossy, or just lossless?
|
|
|
|
monad
|
2025-09-09 02:34:28
|
Maybe `I` and `E` still does something in VarDCT, but it should be minimal. Higher `E` is also generally denser for lossless. I know nothing about lossy modular.
|
|
|
|
Orum
|
2025-09-09 02:35:24
|
what about `-P` in VDCT?
|
|
|
|
monad
|
2025-09-09 02:36:00
|
IIRC, it's hardcoded.
|
|
|
|
Orum
|
2025-09-09 02:36:10
|
ah, so it does literally nothing then
|
|
|
|
jonnyawsom3
|
2025-09-09 03:00:32
|
When Jon is back from holiday, this should change things a bit https://github.com/libjxl/libjxl/pull/4236
|
|
2025-09-09 03:02:14
|
Group size is always 1 currently, I thought of some experiments based on resolution, assuming larger images are smoother, but results varied. Sometimes g0 would be second best density behind g3 at much faster speeds
|
|
|
|
monad
|
2025-09-09 03:47:12
|
For lossless, the encoder picks g2 for images with dimensions at most 400 pixels which would require multiple groups. It also picks g0 for images fitting in one group, but I'm not aware of practical consequences from that.
|
|
|
|
Traneptora
|
|
username
there's a good chance Microsoft's software just doesn't do proper HDR for JXL. The only thing I know that's almost guarantied to work is [Thorium](https://thorium.rocks/) (fork of Chromium) although it's a full web browser rather then an image viewer.. afaik there isn't anything about JXL that makes it hard to do HDR it's just that most software and companies just suck at supporting HDR stuff
|
|
2025-09-11 01:20:01
|
mpv :)
|
|
|
|
Demiurge
|
2025-09-11 02:12:05
|
mpv has an image mode too I heard
|
|
2025-09-11 02:12:20
|
A config file
|
|
|
|
Quackdoc
|
2025-09-11 02:53:42
|
I dont think it has a dedicated mode or anything? It's not hard to configure tho
|
|
|
|
Kupitman
|
|
Demiurge
mpv has an image mode too I heard
|
|
2025-09-11 04:44:42
|
wtf
|
|
|
|
NovaZone
|
2025-09-11 05:44:02
|
yea even a wallpaper mode now ๐คฃ
|
|
2025-09-11 05:45:06
|
https://github.com/mpv-player/mpv/commit/7a5ecf1c06e25c3ca6cf84e78dbe9b091437f739
|
|
2025-09-11 05:47:55
|
so technically u can have a jxl animated wallpaper with mpv now kek
|
|
|
|
Traneptora
|
2025-09-11 06:09:08
|
```
leo@gauss ~/Development/Traneptora/hydrium :) $ memusage ~/.local/bin/hydrium --one-frame george-smile.png ./test.jxl 2>&1 | grep -Eo -e 'heap peak: [0-9]+'
heap peak: 180893635
leo@gauss ~/Development/Traneptora/hydrium :) $ memusage build/hydrium --one-frame george-smile.png ./test.jxl 2>&1 | grep -Eo -e 'heap peak: [0-9]+'
heap peak: 93354222
```
|
|
2025-09-11 06:09:21
|
hydrium memory decrease GET
|
|
|
|
jonnyawsom3
|
2025-09-11 06:39:23
|
Half the memory for single frame?
|
|
|
|
Traneptora
|
|
Half the memory for single frame?
|
|
2025-09-11 08:06:46
|
yup!
|
|
2025-09-11 08:07:54
|
so the issue is that each Frame signals the frequences for the HF coefficients at the start of the frame, so you have to buffer all the HF coefficients before you can calculate the frequencies, since you can't actually entropy-encode them until you calculate the frequences
|
|
2025-09-11 08:08:25
|
I figured out that HF coefficients have a "preset" and if I put each preset in separate clusters, the frequencies don't overlap
|
|
2025-09-11 08:09:58
|
which means that I can instead of buffering the un-encoded HF coefficients for the entire frame, I can buffer the encoded coefficients for each LF group, and then I can throw away the symbols
|
|
2025-09-11 08:10:06
|
saves me a lot of RAM buffering the symbols
|
|
|
Half the memory for single frame?
|
|
2025-09-11 08:30:16
|
depends on the size of the frame. but yes
|
|
|
|
jonnyawsom3
|
|
Traneptora
depends on the size of the frame. but yes
|
|
2025-09-16 04:38:20
|
Saw you bumped the version to 0.6 on the Github, don't suppose you could make a release with a fresh binary?
|
|
|
|
Traneptora
|
|
Saw you bumped the version to 0.6 on the Github, don't suppose you could make a release with a fresh binary?
|
|
2025-09-16 04:41:36
|
wanna iron out some known bugs first
|
|
2025-09-16 04:41:37
|
but then yes
|
|
|
|
jonnyawsom3
|
2025-09-16 04:41:50
|
Ah right
|
|
|
spider-mario
|
2025-09-17 07:05:41
|
cursed idea: port jxlatte to .NET; name the port โJExcelโ (as a Microsoft reference)
|
|
|
|
jonnyawsom3
|
2025-09-17 07:12:23
|
Do any .NET bindings exist for libjxl? Might be a good fit
|
|
|
|
Tirr
|
2025-09-17 07:13:18
|
not a reference but https://github.com/tirr-c/jexcel ๐
|
|
|
|
spider-mario
|
2025-09-17 07:22:08
|
oh ๐
|
|
|
Do any .NET bindings exist for libjxl? Might be a good fit
|
|
2025-09-17 07:22:56
|
there seems to be https://github.com/cocoon/jxl.Net, butโฆ it calls `cjxl.exe`/`djxl.exe` as subprocesses?
|
|
2025-09-17 07:24:11
|
either way, a pure C# implementation might mean less hassle with getting or producing libjxl binaries for all platforms and integrating them
|
|
2025-09-17 07:25:05
|
maybe it could even be made decently fast with https://learn.microsoft.com/en-us/dotnet/standard/simd
|
|
|
|
Orum
|
2025-09-18 01:52:47
|
not with managed memory, it won't be
|
|
2025-09-18 01:52:57
|
and C# (or really, .net/mono) has its own host of headaches
|
|
|
|
spider-mario
|
2025-09-18 07:38:09
|
what sort?
|
|
|
spider-mario
either way, a pure C# implementation might mean less hassle with getting or producing libjxl binaries for all platforms and integrating them
|
|
2025-09-18 07:38:32
|
to be clear, when I said that, I meant in the context of a .NET app
|
|
|
|
Orum
|
|
spider-mario
what sort?
|
|
2025-09-18 08:43:32
|
compatibility
|
|
|
|
DZgas ะ
|
2025-09-19 03:39:59
|
<:Hypers:808826266060193874> <:JXL:805850130203934781> Telegram on PC creates a preview jpg that is embedded inside the message, for jxl image size of 10000x4500 - excellent
|
|
|
|
Quackdoc
|
2025-09-19 06:21:01
|
thats a beeg picture
|
|
|
|
jonnyawsom3
|
2025-09-19 07:08:19
|
No match for OpenTTD though
|
|
|
|
Kupitman
|
|
DZgas ะ
<:Hypers:808826266060193874> <:JXL:805850130203934781> Telegram on PC creates a preview jpg that is embedded inside the message, for jxl image size of 10000x4500 - excellent
|
|
2025-09-19 09:02:58
|
On client, that normal
|
|
|
Marcel
|
2025-09-21 05:06:46
|
Safari now supports HDR test on JPEG XL page!
|
|
2025-09-21 05:07:12
|
|
|
|
|
Orum
|
2025-09-21 05:15:21
|
I may often be critical of Apple but at least they're doing JXL some justice...
|
|
2025-09-21 05:15:42
|
now if only Mozilla would follow suit <:SadOrange:806131742636507177>
|
|
|
|
Quackdoc
|
2025-09-21 05:18:51
|
eventuallyโข
|
|
|
|
jonnyawsom3
|
2025-09-21 05:32:12
|
I made some suggestions to the Firefox dev who likes JXL, they gave it an eyes react so here's hoping. It would mean round-robin progressive loading, down to 0.2% of the file in worst case network conditions
|
|
|
|
Quackdoc
|
2025-09-21 05:38:03
|
ff will want to wait until jxl-rs is at least somewhat performant and efficient
|
|
|
|
jonnyawsom3
|
2025-09-21 05:39:37
|
Until it's shipped, definitely. But for prototyping the fork already exists and changes/requests are being made to help integration
|
|
|
lonjil
|
|
I made some suggestions to the Firefox dev who likes JXL, they gave it an eyes react so here's hoping. It would mean round-robin progressive loading, down to 0.2% of the file in worst case network conditions
|
|
2025-09-21 07:49:07
|
๐
|
|
|
|
veluca
|
|
Quackdoc
ff will want to wait until jxl-rs is at least somewhat performant and efficient
|
|
2025-09-21 08:05:36
|
working on it ๐
|
|
2025-09-21 08:05:43
|
but I am a bit busy these weeks
|
|
|
AccessViolation_
|
|
I made some suggestions to the Firefox dev who likes JXL, they gave it an eyes react so here's hoping. It would mean round-robin progressive loading, down to 0.2% of the file in worst case network conditions
|
|
2025-09-21 09:00:28
|
what do you mean with round robin progressive loading? do you mean network activity would be scheduled between many images?
|
|
|
|
username
|
|
AccessViolation_
what do you mean with round robin progressive loading? do you mean network activity would be scheduled between many images?
|
|
2025-09-21 09:05:03
|
here's the exact comment for context: https://github.com/libjxl/jxl-rs/issues/387#issuecomment-3312545154
|
|
|
|
AccessViolation_
|
2025-09-21 09:09:50
|
oh gotcha, yeah that seems nice
|
|
|
|
Quackdoc
|
|
veluca
working on it ๐
|
|
2025-09-21 09:10:02
|
we have patience :D
|
|
2025-09-21 09:10:37
|
~~the internet can waste terabytes of bandwidth for now no problemo~~
|
|
|
|
jonnyawsom3
|
|
AccessViolation_
what do you mean with round robin progressive loading? do you mean network activity would be scheduled between many images?
|
|
2025-09-21 09:36:09
|
Yeah, so loading a page would do a partial content request for JXL files, downloading the first kilobyte or so of all images to get their Table Of Contents. Then load the scans of each image one after each other. If the network is slow and the image was saved progressively, the browser could decode after a timeout regardless of download progress, down to an 8x8 preview (We may try to add the size as a cjxl parameter). If the network is fast it can go straight to the 1:8 LF or just fully download in one go, similar to how video players/streaming work with buffering
|
|
2025-09-21 09:36:46
|
We've had the rough idea for years, but having it integrated into the browser instead of per-site/server would solve most of the issues that held it back, also giving excellent reference for other implementations
|
|
|
|
AccessViolation_
|
2025-09-21 09:37:20
|
yeah that would be really cool
|
|
2025-09-21 09:38:51
|
I wonder if you could do something with lazy loading images as well? it's quite jarring that they pop in only when in view, maybe it should start loading a 1:8 image when it's near the viewport and load the full thing when in the viewport, as usual. or maybe that would break the spec, and it's not 'allowed' for lazy images
|
|
|
|
jonnyawsom3
|
|
Quackdoc
~~the internet can waste terabytes of bandwidth for now no problemo~~
|
|
2025-09-21 09:39:41
|
Also I did some extremely rough napkin maths, with the fixed fast lossless and the other small regression fixed, a single server rack would be able to encode every image uploaded to the web... Assuming everyone wanted fast lossless and has infinite bandwidth, but a fun idea :P
|
|
2025-09-21 09:40:38
|
Hitting 3GP/s on a consumer 8 core CPU under normal use too, servers would shred it
|
|
|
AccessViolation_
I wonder if you could do something with lazy loading images as well? it's quite jarring that they pop in only when in view, maybe it should start loading a 1:8 image when it's near the viewport and load the full thing when in the viewport, as usual. or maybe that would break the spec, and it's not 'allowed' for lazy images
|
|
2025-09-21 09:43:09
|
That was part of the idea, since you're downloading the TOC of every JXL anyway, it should be aware that there's an image there even if it can't decode yet. Worst case, download the first 8KiB and the new progressive images will load
|
|
2025-09-21 09:44:30
|
We'd need an API to get the TOC first though, and ideally cache the decoded previews for the later progressive decodes (Instead of decoding LfGlobal 5 times in a row)
|
|
|
|
Quackdoc
|
|
Also I did some extremely rough napkin maths, with the fixed fast lossless and the other small regression fixed, a single server rack would be able to encode every image uploaded to the web... Assuming everyone wanted fast lossless and has infinite bandwidth, but a fun idea :P
|
|
2025-09-21 09:46:39
|
xD
|
|
|
|
jonnyawsom3
|
2025-09-21 09:46:43
|
Ironically, it would make Firefox's implementation blow the old Chrome one out of the water, when it hasn't even had transparency for years
|
|
|
|
Meow
|
|
Marcel
|
|
2025-09-22 02:13:25
|
Meanwhile Preview on iOS/iPadOS 26 can't open JXL
|
|
2025-09-22 02:13:59
|
The purposes of that app are also criticised
|
|
|
|
Marcel
|
|
Meow
Meanwhile Preview on iOS/iPadOS 26 can't open JXL
|
|
2025-09-22 08:00:34
|
itโs work for me
|
|
|
|
Meow
|
2025-09-22 08:01:56
|
Pretty weird
|
|
|
KKT
|
|
Marcel
|
|
2025-09-24 09:35:45
|
I'll update the text on the page!
|
|
|
|
cioute
|
2025-09-25 12:23:55
|
i like how png became 1.7 times lighter in 7 sec
|
|
2025-09-25 12:28:47
|
why browsers have no support of jpegxl?
|
|
|
|
spider-mario
|
2025-09-25 12:48:31
|
<@1321081296113373187> are you building in a directory where you previously built with exr 3.2 installed, then upgraded exr to 3.3? simply running `cmake .` (to make it redetect the right exr version) then re-attempting the build might fix it
|
|
2025-09-25 12:49:20
|
if it doesnโt, you can try to edit `CMakeCache.txt` and remove all variables with `EXR` in the name, to force redetection
|
|
2025-09-25 12:49:42
|
(or just clear the build directory altogether and start from scratch)
|
|
2025-09-25 01:05:28
|
oh, and it builds from source?
|
|
|
|
cioute
|
2025-09-25 01:26:23
|
did you know android gallery app which can correctly zoom jpegxl? i tested jpegview (fork) on windows and qview on linux, they can
|
|
|
|
jonnyawsom3
|
2025-09-25 01:28:24
|
Correctly zoom? There's viewers that don't do it properly?
|
|
|
|
cioute
|
2025-09-25 07:03:16
|
<@604964375924834314> i just need type "pkg install openexr", solved
|
|
|
cioute
did you know android gallery app which can correctly zoom jpegxl? i tested jpegview (fork) on windows and qview on linux, they can
|
|
2025-09-25 08:23:38
|
Oupson's jpegxl viewer decodes jpegxl at full resolution
|
|
2025-09-26 11:05:06
|
why best image format has worst naming?
|
|
|
|
Meow
|
2025-09-26 11:14:03
|
Define "worst"
|
|
2025-09-26 11:14:53
|
Maybe you will really love QOI because it's quite ok
|
|
|
|
cioute
|
2025-09-26 11:30:29
|
i changed my mind, now jpegxl is not worst naming
|
|
|
|
Quackdoc
|
|
|
Tirr
|
2025-09-28 01:51:48
|
<@&807636211489177661> <:BanHammer:805396864639565834>
|
|
|
|
AccessViolation_
|
2025-09-28 03:07:46
|
I wonder if it would have been helpful if JXL had a mode that produced more or less byte-aligned compression. since there is little interframe compression in multi-frame JXLs, if it had a byte-aligned encoding mode like QOI or a mode to occasionally realign itself every so many bits, that could allow entropy coding to deduplicate similar patterns between frames without adding more coding tools specifically for interframe coding
|
|
2025-09-28 03:12:53
|
though, I wonder if arithmetic coding means that slight variations won't just cause identical compressed data to be misaligned, it might also change it completely. even with huffman coding I suppose variations might change the probability distributions and cause identical data between frames to be encoded differently, even when it's aligned
|
|
|
|
jonnyawsom3
|
2025-09-28 08:05:23
|
We can do differential storage and patches
|
|
|
|
AccessViolation_
|
2025-09-30 08:09:45
|
how, on a high level, does MA-tree generation and context clustering work? I've read the relevant sections from the paper, but it doesn't go into what's done to decide how to generate the MA-tree or in what way sets of histograms are chosen to become clusters
|
|
2025-09-30 08:11:49
|
I have no idea how complex this is and so I don't know whether this is something that could be adequately explained in a discord message or would require its own paper. I hope it's the former ^^
|
|
2025-09-30 08:24:46
|
to be more specific: I imagine the encoder has for every pixel information like which predictor would work best and all the properties for use in decision nodes, has to look at that data and produce a binary tree with those properties and well picked thresholds, balancing 'correct result' coverage and tree size. I can't find anything about how that's done
|
|
|
|
veluca
|
2025-10-01 12:48:57
|
I don't think I ever wrote any documentation for it
|
|
2025-10-01 12:50:06
|
tldr: for every possible split node, compute the cost of compressing each half with the best predictor. Compare that to the cost with the best predictor if not splitting. If the difference is above a threshold, split and recurse
|
|
|
|
AccessViolation_
|
|
veluca
tldr: for every possible split node, compute the cost of compressing each half with the best predictor. Compare that to the cost with the best predictor if not splitting. If the difference is above a threshold, split and recurse
|
|
2025-10-01 02:26:09
|
oh wow, that's delightfully simple.
do you test every applicable threshold value (presumably range-constrained by relevant parent decision nodes) for every split node, or do you use some heuristic or discrete sampling to reduce the amount of threshold values you test?
|
|
|
|
veluca
|
2025-10-01 02:27:06
|
all of them, but we typically quantize the properties to 16 or 256 values, I think
|
|
|
|
AccessViolation_
|
2025-10-01 02:28:20
|
also is the `-I PERCENT: Percentage of pixels used to learn MA trees.` referring to the pixels that are used when comparing the cost of both splits?
|
|
|
|
veluca
|
|
|
AccessViolation_
|
2025-10-01 02:28:43
|
gotcha, I was wondering what that did
|
|
|
|
veluca
|
2025-10-01 02:29:06
|
it's probably far from optimal (in fact I have known a probably-better splitting rule for a few years at this point)
|
|
2025-10-01 02:29:09
|
but who had time
|
|
|
|
jonnyawsom3
|
|
AccessViolation_
also is the `-I PERCENT: Percentage of pixels used to learn MA trees.` referring to the pixels that are used when comparing the cost of both splits?
|
|
2025-10-01 02:34:49
|
Yes but not quite, Monad discovered that 100 isn't actually all pixels. There's another hidden value that requires setting it to 10,000 to actually sample every pixel (or something like that)
|
|
|
|
AccessViolation_
|
2025-10-01 02:35:25
|
oh yeah I remember someone talking about that <:KekDog:805390049033191445>
|
|
2025-10-01 02:54:38
|
the thing that immediately comes to mind for me is that - at least from its description - it seems to have no insight into how the the current possible decision nodes would affect the usefulness of the next two possible child nodes. an evaluation depth of 2 would prevent it from making a choice that's the most optimal by itself, but suboptimal when evaluated together with the child nodes.
another thing would be: location-based decisions that produce splits of contiguous blocks of pixels, e.g. `y > 120`, will retain a lot more structure early on than those based on pixel values, like `NW-N > 120`, which would produce a sparse selection of pixels. that poor locality might limit how many of the following possible decision nodes would be effective. so a decision node that doesn't preserve preserve locality of pixels in the splits well could have a higher cost multiplier if it were to be used be used close to the root of the tree
|
|
2025-10-01 02:59:09
|
time to dive into the source code :3
|
|
|
|
_wb_
|
|
Yes but not quite, Monad discovered that 100 isn't actually all pixels. There's another hidden value that requires setting it to 10,000 to actually sample every pixel (or something like that)
|
|
2025-10-01 05:22:52
|
There are two rounds of sampling: first `I/100` samples to decide how to quantize the actual samples, then `I` actual samples. IIRC.
|
|
|
|
jonnyawsom3
|
2025-10-01 05:48:37
|
Hmm, I wonder how much of an impact the quantization has, might be worth tuning further
|
|
|
BackAlleyNoNo
|
2025-10-03 01:02:20
|
It seems like jxl is amazing for adult picture like quality (example below. ~1mb, good lighting, alot of skin). been testing jxl vs avif mainly on adult pictures, and jxl consistently 30-40% smaller then avif. It gets even better the higher quality the picture is.
|
|
2025-10-03 01:06:09
|
One caveat - for pictures where skin is the whole picture, this is where avif and jxl is roughly the same. Maybe this is because all skin = a "simpler" picture? Whereas the more "busy" the picture is, the more efficient jxl can be
|
|
|
|
Meow
|
2025-10-03 02:18:26
|
That's why Pornhub adopted JXL recently
|
|
|
|
NovaZone
|
2025-10-03 02:23:29
|
and avif ๐
|
|
|
Jake Archibald
|
2025-10-03 11:01:30
|
Hey folks! I'm kicking the tyres of progressive rendering of JXL. My understanding is that, even without `--progressive`, it should be possible to do a full-pass low res rendering? Is that right? If so, is there a way to make `djxl` output that? Right now I'm feeding it a fragment of the input & `--allow_partial_files`, but without `--progressive` I'm only getting square-by-square rendering
|
|
|
|
lonjil
|
|
Jake Archibald
Hey folks! I'm kicking the tyres of progressive rendering of JXL. My understanding is that, even without `--progressive`, it should be possible to do a full-pass low res rendering? Is that right? If so, is there a way to make `djxl` output that? Right now I'm feeding it a fragment of the input & `--allow_partial_files`, but without `--progressive` I'm only getting square-by-square rendering
|
|
2025-10-03 11:11:18
|
I don't recall the name of it, but there's an option called something like "downsample". I believe jf you set this to 8, you should get just the LF components of each DCT block.
|
|
|
|
Jake Archibald
|
|
lonjil
I don't recall the name of it, but there's an option called something like "downsample". I believe jf you set this to 8, you should get just the LF components of each DCT block.
|
|
2025-10-03 11:17:58
|
I've given that a try, but it doesn't impact the earliest I can get a useful preview out of the file
|
|
2025-10-03 11:18:10
|
Thank you though!
|
|
|
|
veluca
|
2025-10-03 11:21:01
|
are you doing lossy or lossless?
|
|
|
|
Jake Archibald
|
2025-10-03 11:21:33
|
Lossy
|
|
2025-10-03 11:22:23
|
Created via `cjxl fox.png fox.jxl -q 42.5 -e 10` (with and without the progressive flag)
|
|
2025-10-03 11:23:24
|
Happy to change the encoding method if there's a way to get an earlier rendering pass
|
|
|
|
lonjil
|
2025-10-03 11:31:47
|
I wonder if this is djxl just being a little silly and not outputting as much as it could, or if the file has an odd order.
|
|
|
|
veluca
|
2025-10-03 12:20:21
|
ah, I wonder if this is streaming encoding doing weird things
|
|
2025-10-03 12:20:29
|
also, can you try with default flags?
|
|
|
|
Jake Archibald
|
2025-10-03 12:26:56
|
<@179701849576833024> I'm not sure how to do that (not seeing anything in `cjxl -v --help`)
|
|
2025-10-03 12:27:27
|
Or do you mean, remove `-e`?
|
|
2025-10-03 12:29:34
|
Leaving `-e` as the default gives me the same sort of results
|
|
|
|
veluca
|
2025-10-03 12:29:34
|
yes, remove all the flags
|
|
|
|
Jake Archibald
|
2025-10-03 12:29:45
|
Is `-q` a flag?
|
|
|
|
veluca
|
2025-10-03 12:29:47
|
including -q
|
|
|
|
Jake Archibald
|
2025-10-03 12:32:04
|
Without any flags, I get a much bigger file, but the loading pattern visible to `djxl` seems the same as `cjxl fox.png fox.jxl -q 42.5 -e 10`, as in, it delivers nothing until it's pretty far into the file, then renders a transparent image at canvas size, then renders in square chunks starting from the top-left.
|
|
2025-10-03 12:35:05
|
With `cjxl fox.png fox.jxl`, it produces a 722kb file, and `djxl` can't produce any image data until it has ~111kb.
|
|
2025-10-03 12:36:28
|
With `cjxl fox.png fox.jxl -q 42.5 -e 10 --progressive`, it produces a 158kb file, and `djxl` can't produce anything until it has 63kb.
|
|
|
|
Quackdoc
|
2025-10-03 12:36:50
|
try jxl-oxide
|
|
|
|
Jake Archibald
|
2025-10-03 12:37:38
|
For comparison, a similar size JPEG, 154kb, can produce some pixel data after 1.2kb, and a full pass at ~33kb
|
|
2025-10-03 12:38:14
|
<@184373105588699137> I'll give it a go, thanks
|
|
|
|
Quackdoc
|
2025-10-03 12:38:24
|
jxl-oxide is far better then djxl currently for producing images, some example can be seen in the jxl-oxide thread
|
|
2025-10-03 12:38:57
|
I haven't tested libjxl itself so I dunno if its a djxl or a libjxl issue
|
|
|
|
_wb_
|
2025-10-03 12:39:30
|
if it renders a transparent image, try preprocessing your original to have no alpha channel
|
|
|
|
Jake Archibald
|
2025-10-03 12:41:24
|
ohh, interesting. Yeah the input is a PNG
|
|
2025-10-03 12:41:52
|
but I didn't think it had alpha data. I'll make sure it doesn't
|
|
2025-10-03 12:51:22
|
<@794205442175402004> yeah, that was part of the problem. Now `cjxl fox.png fox.jxl -q 42.5 -e 10` gives me a full scan render at ~63k. That's still a lot later than a similar sized JPEG though.
|
|
2025-10-03 12:51:38
|
I'll try jxl-oxide
|
|
2025-10-03 01:04:57
|
Ohh interesting, jxl-oxide can produce earlier renders, but it looks channel-by-channel. As in, you wouldn't want a browser displaying anything before the ~63k mark
|
|
2025-10-03 01:07:25
|
Also `djxl` has better smoothing of the first scan
|
|
2025-10-03 01:07:33
|
Thanks folks!
|
|