|
|
veluca
|
2025-12-26 07:03:16
|
not sure it is |
|
2025-12-26 07:03:59
|
there's also this knob, fwiw: https://github.com/libjxl/libjxl/blob/main/lib/jxl/enc_frame.cc#L655 |
|
2025-12-26 07:04:20
|
that should just increase or decrease the precision on x/b AC |
|
|
jonnyawsom3
|
2025-12-26 07:15:56
|
I know Jyrki pointed us towards a B channel parameter a few months ago, but even setting it to max didn't help. Maybe this one is different though, so it's worth a shot |
|
|
|
veluca
|
2025-12-26 07:20:36
|
probably the same |
|
|
Demiurge
|
2025-12-26 07:34:28
|
It's just as bad with flat colors too in my experience. The desaturation seems pretty consistent... |
|
|
|
jonnyawsom3
|
2025-12-26 07:45:48
|
Do you have an example? I only got it in the AC |
|
|
monad
|
2025-12-26 09:16:23
|
tried it on my Minecraft screenshot, adjusting the result of HowMuchIsXChannelPixelized() and HowMuchIsBChannelPixelized() by +5 (for example) instead of +2 helped colors at significant encode size cost.
All else default:
```
B ssimu2
603707 81.07776755 f67665352.png.git445e9098.jxl
684163 84.76121362 f67665352.png.git445e9098_5+HowMuchIsXChannelPixelized.jxl
```
(name of JXL not reflecting accurately that both functions were adjusted) |
|
2025-12-26 09:39:41
|
disabling the first conditional block produced worse color in my example:
```
B ssimu2
603707 81.07776755 f67665352.png.git445e9098.jxl
590307 78.82932201 f67665352.png.git445e9098_off.jxl
``` |
|
|
|
jonnyawsom3
|
2025-12-26 10:12:12
|
Last I saw, it already does round towards 0, but in XYB a value of B 0 doesn't mean B 0 in sRGB |
|
|
|
veluca
|
2025-12-26 10:13:06
|
Ah maybe we got rid of Jyrki's funny rounding |
|
|
|
jonnyawsom3
|
2025-12-26 10:15:34
|
Theoretically, making a new quant table could be automated. Just start with all 1s, increase the highest frequency quantization until a score threshold, then do the next value until it hits the threshold too. Repeat until you hit the last value of the last channel. Not sure how accurate SSIMU2 is for this high saturation though, so we'd probably end up in the same spot |
|
|
|
veluca
|
2025-12-26 11:01:19
|
going to bet that a large part of this issue comes from metrics not being good enough 😛 |
|
|
|
jonnyawsom3
|
2025-12-26 11:05:32
|
Well with the (Unrelated) big quality regression in v0.8, SSIMU2 actually said the quality was worse, but every other metric said it was good so it wasn't caught |
|
2025-12-26 11:06:17
|
...I need to keep working on that DCT tuning at some point |
|
2025-12-26 11:16:35
|
Ah nevermind, I was thinking of this but it's CMS only https://github.com/libjxl/libjxl/pull/3329 |
|
2025-12-27 12:28:23
|
Hmm, what score do you get if you match the filesize with the adjusted build? |
|
|
|
monad
|
2025-12-27 12:53:35
|
I could do that naively by decreasing target distance, which should easily benefit ssimu2 score more than the adjustment. Is that what you mean? |
|
|
|
jonnyawsom3
|
2025-12-27 12:55:38
|
Sorry, I mean with the boosted saturation, what if you raise the distance to match the filesize of the normal encoding. I assume the score will be lower, but I'm curious by how much |
|
|
|
monad
|
2025-12-27 12:57:25
|
Ok, I will check. And yes, I expect ssimu2 will suffer quite a bit since the change is expensive. |
|
|
|
Demiurge
|
2025-12-27 12:59:11
|
I will try to test this later just so I can demonstrate and prove it to the rest of the people here. Perhaps with an image of a yellow-red gradient. |
|
2025-12-27 01:00:20
|
The desaturation I mean. In my experience it's very consistent and very noticeable even on large solid objects. It's not at all specific to small, fine details |
|
2025-12-27 01:03:39
|
Although, it makes a lot of sense that it would be more noticeable on small details, since when those get resampled and the differences averaged, the gamma distortion is much greater when pixels of different values are being averaged together, rather than pixels of similar value. |
|
2025-12-27 01:03:47
|
That's just how resampling works. |
|
2025-12-27 01:04:37
|
The distortion from the gamma function is obviously more extreme when different values get (incorrectly) averaged together |
|
2025-12-27 01:11:51
|
Still, nothing to do with the quant table... making the AC quantization coefficients less coarse and more precise would probably be a waste of bits compared to just tuning the coarser quantization so the result is closer on average to the intended value rather than consistently beneath. |
|
2025-12-27 01:13:59
|
The important thing is doing it in a way that would be fast and convenient for fixed function hardware. |
|
2025-12-27 01:17:20
|
I might be wrong about it being a gamma problem, because otherwise we would expect to see a consistent darkening of the image too, wouldn't we? |
|
|
A homosapien
|
2025-12-27 01:18:04
|
It would be nice to have more examples of desaturation posted here for the public to see: https://github.com/libjxl/libjxl/issues/3616 |
|
|
|
Demiurge
|
2025-12-27 01:22:10
|
Agreed... I will try to make some contrived examples later... |
|
2025-12-27 01:22:26
|
To help study the problem |
|
|
NovaZone
|
2025-12-27 01:29:31
|
414 makes me wonder how long color shift/saturation has been an issue, from my own non scientific test https://discord.com/channels/794206087879852103/794206087879852106/1397517874209357955 |
|
|
|
monad
|
2025-12-27 01:30:16
|
misplaced my script for automating the search, so hopefully this suffices to satisfy some curiosity for now.
2 bytes off:
```
603707 81.07776755 f67665352.png.git445e9098.jxl
603705 82.02365899 f67665352.png.git445e9098_adjusted_d1.184808.jxl
603709 82.02383097 f67665352.png.git445e9098_adjusted_d1.184801.jxl
```
Actually, I expected worse, and colors are still better retained with the higher distance target in this case. |
|
|
|
Demiurge
|
2025-12-27 01:32:07
|
The desaturation issue looks like it has always been there, and just gotten slightly worse or better in certain releases |
|
2025-12-27 01:32:40
|
Even really old versions of libjxl has more noticeable desaturation than other codecs |
|
|
|
jonnyawsom3
|
2025-12-27 01:33:23
|
Roughly what I expected. Assuming the harsh quantization is one of the bigger issues with lossy currently, raising the chroma quality and lowering everything else slightly could be a better tradeoff. Probably worded this poorly but you get the idea |
|
|
|
Demiurge
|
2025-12-27 01:33:33
|
Yellow and orange especially |
|
|
|
jonnyawsom3
|
2025-12-27 01:38:02
|
None of our images have resampling |
|
|
|
Demiurge
|
2025-12-27 01:38:16
|
Yeah, that's the most obvious solution... A better solution is only possible by some sophisticated trickery |
|
|
|
jonnyawsom3
|
2025-12-27 01:39:27
|
Hey <@207980494892040194> how alive are you after Christmas? We could do some testing |
|
|
|
A homosapien
|
2025-12-27 01:39:54
|
I have some free time |
|
|
|
Demiurge
|
2025-12-27 01:40:06
|
Resampling is not so different. |
|
|
|
jonnyawsom3
|
2025-12-27 01:40:15
|
Not so different to what? |
|
|
|
Demiurge
|
2025-12-27 01:41:17
|
The DCT compression does not operate on linear values but on gamma-encoded values so it makes sense if it suffers the same problem that resampling algorithms suffer when operating on gamma-encoded values. |
|
2025-12-27 01:42:32
|
Gamma encoded values are being transformed directly |
|
2025-12-27 01:42:50
|
So that produces its own error pattern |
|
2025-12-27 01:45:17
|
That gamma encoding causes all of the rounding errors to have a consistent bias towards zero whenever multiple samples of different values are averaged together |
|
|
|
jonnyawsom3
|
2025-12-27 01:49:38
|
Gonna move to https://discord.com/channels/794206087879852103/804324493420920833/1454290006389555354 for further discussion/tests |
|
|
DZgas Ж
|
2025-12-27 08:10:07
|
I'm not interested in «improvements», but it definitely needs to work perfectly. Otherwise, something funny will happen: the 1.0 release is a newsbreak, a lot will be written about it, and then competitors will point out all these problems head-on and say, "Wow, what an unprepared codec, all my pictures are losing color at Q70" — and it will be me 🥴 |
|
|
AccessViolation_
|
2025-12-27 05:09:08
|
I'm playing around with photon noise synthesis. for some reason the noise added by `--photon_noise_iso` also creates a bunch of noise in the dark pupil, so the model doesn't work for this image |
|
2025-12-27 05:09:16
|
|
|
2025-12-27 05:09:59
|
I wonder if that's because the noise in the image is actually film grain, and requires a different LUT to look right |
|
2025-12-27 05:18:23
|
it might also be that the grain is larger than the pixels are, which I thought wasn't the case, but it might be. if that is the case, then obviously it won't work at all for this image. but that seems unrelated to the added noise in the dark areas |
|
|
_wb_
|
2025-12-27 07:41:43
|
your denoising is quite aggressive, a lot of detail is lost...
`--photon_noise_iso` models photon noise which is more visible in the darks than in the brights because the perceptual effect of one photon difference is also larger in the darks than in the brights. |
|
2025-12-27 07:43:22
|
for film grain it might be better to use a uniform or even inverted noise table, assuming it's pixel-sized to begin with (otherwise jxl's noise synthesis will not help) |
|
|
|
jonnyawsom3
|
2025-12-27 07:43:32
|
Photon noise is based on digital sensors, since now they're a lot more common than film. An inverted LUT might work okay for film though |
|
2025-12-27 07:44:09
|
It's times like this I wish we had a JXL art style editor for existing images, could just edit the LUT then |
|
|
TheBigBadBoy - 𝙸𝚛
|
2025-12-27 07:48:57
|
if someone wants I can try to denoise that image manually |
|
|
|
AccessViolation_
|
2025-12-27 08:04:40
|
this is sort of the conclusion I came to as well, the noise here seems to be most visible in the mid to high brightness range, and after further experimentation the film grain is also definitely larger than a pixel, it seems to be on the order of 3 to 6 pixels. but it appears more as irregular overlapping shingles rather than splotches which is why I didn't identify it at first. I only found out when I downscaled by 8 in both dimensions without interpolation, at which point the noise looked much finer - but still not proportional to the brightness like ISO noise is |
|
2025-12-27 08:06:22
|
the inverted noise table is interesting. I was thinking about how film gain noise plus photon noise should be modeled and I thought that for the film grain you'd need a uniform table, like a noise floor, and then *added* to that is a photon noise curve, but that wasn't based on anything concrete |
|
2025-12-27 08:10:07
|
that might be a bit too much work, given that it's this big ^^ |
|
|
|
TheBigBadBoy - 𝙸𝚛
|
2025-12-27 08:17:29
|
as you want |
|
|
|
AccessViolation_
|
2025-12-27 08:18:18
|
(image set download for those interested: <https://pixeldrain.com/u/acuWaWDJ>) |
|
2025-12-27 08:19:56
|
that's kind of you, thanks. but I don't need it because film grain contributes to the noise here as well |
|
2025-12-27 08:20:45
|
I'm looking into pure photon noise atm, that seems easier to model |
|
|
Jyrki Alakuijala
|
2025-12-30 05:33:34
|
I played a lot with many hypotheses around dct before and after gamma. I wasn't able to get reasonable compression rates if I did physical DCT. In all my experiments DCT was more beneficial to be applied on gamma converted values |
|
2025-12-30 05:38:27
|
Physical noise energy increases as roughly sqrt of energy. However, considering that the whole energy (pure signal + photon noise) is gamma compressed with roughly cubic root to approximate compression in receptors, photon noise can be most easy to perceive in mid intensities. |
|
|
Flynn's
|
2026-01-02 12:05:48
|
Hi,
I am currently evaluating jxl for a custom CV (computer vision) pipeline and found the overall capabilities delightfull (HDR, metadata, float32, alpha, lossless/losy compression). The only downside for us is that it does not seem to have a *no compression mode*.
For us it would be usefull in intermediary steps when we have plenty of storage and i/o bandwidth, yet encoding (even low complexity), is "slow" (even a 50ms per frame / image when dealing with thousands is "slow"). And we are dealing with machines with very fast storage, but not so much cpu for encoding.
Did I miss something in jxl's support of a no compression path ? If not, is this a planned / possible thing in the future ? |
|
|
lonjil
|
2026-01-02 12:14:11
|
is 50 ms / frame what you get with `-e 1 -d 0`? |
|
|
|
jonnyawsom3
|
2026-01-02 12:16:58
|
I'd assume so, since nothing else comes close |
|
2026-01-02 12:23:29
|
Could you paste the console output from one of the encodings? That would give us a lot more info like resolution, encoder version and MP/s |
|
|
|
Flynn's
|
2026-01-02 12:24:06
|
yes, I use it through custom build of ffmpeg (jxl 0.11.1 used for build) and assoicated libs (libavcodec) with bindings, but yes, effort is 1 and distance is 0 / lossless. |
|
2026-01-02 12:29:15
|
ok, I'll do that when I get back onto the setup. I'll tests again correctly then after. 50ms was a ballpark. It is obviously highly dependent on input sizes / dataset. Some where 100ms, some less from memory.
But the idea is that it is much faster for us in some cases to dump the unencoded data to disk than to encode it ... but then we lose a lot of "nice to have" (compat/debugable easily/metadata attached to frames/etc). And this would also be maintaining a "custom format" just for intermediary steps, even though jxl seems a good fit for storing the data after filtering / use into a S3... |
|
|
|
jonnyawsom3
|
2026-01-02 12:29:54
|
Doing a pretty rough test, FFMPEG is around 10x slower than cjxl for me with effort 1, so I think there's a lot of speed to gain |
|
|
username
|
2026-01-02 12:31:30
|
I wonder if that's due to how the compiler is optimizing it or overhead from either how FFMPEG is using libjxl or overhead from FFMPEG itself? |
|
|
RaveSteel
|
2026-01-02 12:31:39
|
decode is also much slower last I've tested |
|
2026-01-02 12:32:10
|
but that was months ago, so who knows |
|
|
|
_wb_
|
2026-01-02 12:41:44
|
It should be possible to make an 'uncompressed' mode that is just a fixed header to use 'prefix codes' that are fixed 8-bit or 16-bit, and then the image is just planar RGB, no compression at all. |
|
|
|
Flynn's
|
2026-01-02 12:41:53
|
well if that is the case I'll probably investigate with jxl cli too. Just having possibility to make a custom encoder path that is faster later on, would be enough for us. Thanks for the input. I'll get back when I have clean / comparable results btw cjxl and ffmpeg build. Probably early next week. |
|
|
|
_wb_
|
2026-01-02 12:41:56
|
Still tiled though |
|
2026-01-02 12:42:25
|
But e1 lossless compression should not be much slower than that |
|
|
|
jonnyawsom3
|
2026-01-02 12:44:08
|
```
3840x2160 24bpp image
cjxl e1 Wall 0.014s User 0.068s Kernel 0.05s
ffmpeg e1 rtime=0.180s utime=0.578s stime=0.016s
ffmpeg e2 rtime=0.436s utime=1.422s stime=1.375s
```
So at least my FFMPEG build isn't doing fast lossless properly, e2 should be 20x slower not 2x and we only fixed AVX2 compiling of effort 1 in the unreleased v0.12 |
|
|
|
Flynn's
|
2026-01-02 12:50:39
|
ok, interesting. I am not familiar with the "spec" of jxl itself. But would such a "mode" require new addendum to the spec ? (I am not familliar with how the jxl spec is managed / by whom).
Or would this be implicitly supported by existing encoders / decoders with such "fixed prefix codes" ? |
|
2026-01-02 12:52:16
|
But if you say e1 should be in the ballpark of uncompressed, that should be fine for us. If our build is similar to the one <@238552565619359744> just used (thanks for the lightning fast tests btw !) it's probably more that we shouldn't use ffmpeg for encoding in first place and maybe there is other errors in our compilation / version... |
|
|
|
jonnyawsom3
|
2026-01-02 12:56:27
|
Could be compiler, could be version, could be FFMPEG overhead. No real easy way to tell without compiling FFMPEG ourselves |
|
2026-01-02 01:16:36
|
Theoretically, effort 1 could be *faster* than uncompressed, since the bandwidth saved can be used on more encoding instead. While working on it a few months ago, we hit 11 GP/s. Admittedly it was a pure black image, but that means it's possible!
Since you mentioned metadata, cjxl will also let you use `--brotli_effort 0`, the default is 9. It gave me an extra 50 MP/s |
|
2026-01-02 01:18:55
|
I'd also recommend using these instead of v0.11 https://artifacts.lucaversari.it/libjxl/libjxl/latest/
Due to this fix not being backported <https://github.com/libjxl/libjxl/pull/4027> for this issue https://github.com/libjxl/libjxl/issues/4026
Along with the AVX2 fix I mentioned https://github.com/libjxl/libjxl/issues/4447 |
|
|
|
_wb_
|
2026-01-02 01:26:14
|
This would be within the existing spec and decode with existing decoders. Otherwise it wouldn't be very useful. |
|
|
|
jonnyawsom3
|
2026-01-02 01:33:15
|
Bear in mind, decompression speed is another matter https://github.com/libjxl/libjxl/issues/2843 |
|
2026-01-02 01:35:20
|
Right now encode is around 10x faster than decode for effort 1, we may want to look into ways of improving that
Effort 2 is the fastest for decode but 15x slower encode than 1 |
|
|
|
Demiurge
|
2026-01-02 06:39:15
|
Lossless e1 is insanely fast. Like in the same tier as world-record-breaking speed. Probably even faster than uncompressed. |
|
2026-01-02 06:40:28
|
When you reach speeds that are close to memcpy, then the bottleneck becomes memory transfer speeds |
|
2026-01-02 06:41:22
|
So having less bytes to transfer is better than uncompressed |
|
2026-01-02 06:42:47
|
Depends on your specific hardware of course but yeah it's one of the fastest codecs on the planet when in fast-lossless mode |
|
|
HCrikki
|
2026-01-02 06:52:58
|
someone's reference numbers with lossless e1
github.com/WangXuan95/Image-Compression-Benchmark |
|
|
|
jonnyawsom3
|
2026-01-02 07:16:26
|
> v0.9.0
So missing quite a lot |
|
|
Exorcist
|
2026-01-03 02:28:59
|
Also, FFmpeg don't support multi-frame JXL |
|
|
Traneptora
|
2026-01-03 09:05:56
|
wdym |
|
2026-01-03 09:07:03
|
libjxl transparently handles that for you |
|
|
|
Exorcist
|
2026-01-04 05:16:19
|
```
ffmpeg -i video.mkv test.jxl
ffmpeg version n7.1.2-7-g24c44c34dc-20251031 Copyright (c) 2000-2025 the FFmpeg developers
...
[image2 @ 0000021773867d40] The specified filename 'test.jxl' does not contain an image sequence pattern or a pattern is invalid.
[image2 @ 0000021773867d40] Use a pattern such as %03d for an image sequence or use the -update option (with -frames:v 1 if needed) to write a single image.
[image2 @ 0000021773867d40] Cannot write more than one file with the same name. Are you missing the -update option or a sequence pattern?
``` |
|
|
|
A homosapien
|
2026-01-04 05:35:28
|
ffmpeg has `jpegxl_anim`. Ffmpeg lacks muxing support |
|
2026-01-04 05:36:58
|
https://discord.com/channels/794206087879852103/794206170445119489/1444285004728238201 |
|
|
|
cioute
|
2026-01-05 06:04:26
|
Recommended range: 68 .. 96. Allowed range: 0 .. 100.
hmm... so is higher than 96 useless? |
|
|
|
runr855
|
2026-01-05 06:36:57
|
Quality 96 is equal to distance 0.46. I'd personally use distance 0.3 for images where you expect to zoom a lot, but the amount of storage you'll save isn't huge at that low of a distance. Quality 90 is equal to distance 1.0 which has been determined to be "visually lossless" at a certain standardized test, but personally I do believe it's a bit too aggressive |
|
2026-01-05 06:37:15
|
My recommendation is probably seen as extremely conservative though |
|
2026-01-05 06:42:33
|
What is your goal? I'm happy with distance 0.7 for general use for photography. -d 0.7 is roughly equal to quality 93 if you prefer using the quality metric |
|
2026-01-05 06:43:21
|
Please note this only applies to cjxl, I do believe some software like Affinity implement their own definition of the quality setting |
|
2026-01-05 06:47:20
|
Would be great if companies publicized data on how their implementation related to the underlying encoder |
|
2026-01-05 06:48:25
|
Do note if you intend to use your images on a website or somewhere else where perfect quality isn't needed, I'd personally be much more aggressive and choose a higher distance (lower quality setting) |
|
|
|
RaveSteel
|
2026-01-06 12:36:26
|
<@&807636211489177661> |
|
|
Orum
|
2026-01-06 03:15:48
|
hopefully this will be closed in 2026? 🥺 https://github.com/libjxl/libjxl/issues/4376 |
|
|
Quackdoc
|
2026-01-06 03:53:12
|
no |
|
2026-01-06 03:53:14
|
[chad](https://cdn.discordapp.com/emojis/862625638238257183.webp?size=48&name=chad) |
|
|
|
Traneptora
|
2026-01-07 03:10:49
|
It does you just need to use -f image2pipe |
|
2026-01-07 03:11:47
|
`ffmpeg -i video.mkv -c:v libjxl_anim -f image2pipe animated.jxl` |
|
2026-01-07 03:12:10
|
it has supported it for a few months at least |
|
|
|
A homosapien
|
2026-01-07 05:04:53
|
I learn something new everyday |
|
|
|
Demiurge
|
2026-01-08 10:19:17
|
Usually ffmpeg is supposed to be smart enough to just do `ffmpeg -i input.mov output.jxl` and in an ideal world that's how it would be... |
|
|
|
Traneptora
|
2026-01-09 08:26:05
|
if you do `.jxl` it defaults to the `image2` muxer, not the `image2pipe` muxer |
|
2026-01-09 08:26:28
|
based on file extension |
|
2026-01-09 08:26:46
|
personally I think animated JXL should use a separate file extension |
|
2026-01-09 08:26:53
|
as they're functionally different from stills |
|
2026-01-09 08:27:11
|
unlike lossy/lossless which are used in much the same way |
|
|
Magnap
|
2026-01-10 05:36:29
|
What do you expect to be cheaper, upsampling a completely black or transparent 1024x1024 px group by a factor of n or decoding n² such groups? |
|
|
|
jonnyawsom3
|
2026-01-10 06:10:27
|
Groups can be up to 1024x1024 and upsampling can go up to 8x, so you can use a single group with LZ77 only |
|
|
|
_wb_
|
2026-01-11 01:20:20
|
Decoding is likely cheaper than upsampling if there's a good fast path for long lz77 or single-symbol histograms. |
|
|
|
A homosapien
|
2026-01-11 02:05:30
|
<:FrogSupport:805394101528035328> |
|
|
K
|
2026-01-11 02:37:48
|
questions:
Jxl don't have layering ability does it? |
|
|
|
A homosapien
|
2026-01-11 02:52:13
|
It does |
|
|
|
K
|
2026-01-11 02:58:40
|
Really? Interesting...
I'll do research.
Hopefully the future will make translation easier with layering |
|
|
|
monad
|
2026-01-11 03:37:58
|
animations, 0-duration layers, and even pages |
|
|
|
Orum
|
2026-01-11 07:28:51
|
I think I found JXL's arch-nemesis: https://www.youtube.com/watch?v=RNhiT-SmR1Q |
|
|
|
RaveSteel
|
2026-01-11 11:24:37
|
Simply record screenshots as animated JXL <:galaxybrain:821831336372338729> |
|
|
|
jonnyawsom3
|
2026-01-11 11:26:22
|
It shouldn't do any worse than PNG |
|
|
|
monad
|
2026-01-11 08:25:28
|
PNG is faster |
|
|
|
Orum
|
2026-01-11 08:37:45
|
it was more that JXL is just bad at that sort of image encoding (at least when it comes to lossless) |
|
|
|
jonnyawsom3
|
2026-01-11 09:13:44
|
Tried a few things but PNG was still 20% smaller, previously Jon used a single squeeze step to give the MA trees more context to work with |
|
2026-01-11 09:14:12
|
And there's Modular bit-packing, but that's another can of worms |
|
|
|
monad
|
2026-01-11 09:37:25
|
pretty sure libjxl can get closer than that, but not quickly |
|
2026-01-12 12:31:20
|
|
|
2026-01-12 01:22:45
|
|
|
|
|
jonnyawsom3
|
2026-01-12 01:23:18
|
Yeah, those are the cjxl settings I tried, then e11 too for good measure but no improvement |
|
|
|
monad
|
2026-01-12 01:24:32
|
of course you did |
|
2026-01-12 01:26:44
|
`cjxl -s pancake` when |
|
2026-01-12 05:16:04
|
turns out downsampling works on 3/4 of my screenshots. so, jxl wins?
```4 motus screenshots
Mpx/s real (mean)
B bpp (mean) Mpx/s CPU (mean) best of
59567 0.0143632 0.864728 1.9473 jixel (tries resampling with convert)
68479 0.0165121 1.8108 1.8137 ect_0.9.5_8mt-deflate
68514 0.0165205 1.4120 1.4136 ect_0.9.5_9mt-deflate
70124 0.0169088 26.74 26.78 ect_0.9.5_3mt-deflate
75739 0.0182627 0.0955985 0.0959280 cjxl_0.11.0_d0e10P0I0g3patches0
77126 0.0185971 100 100 ect_0.9.5_1mt-deflate
103535 0.0249650 0.42684 0.48653 cjxl_0.11.0_d0e10
159366 0.0384274 4.783 48.2 cjxl_0.11.0_d0e7
263717 0.0635892 111 160 cjxl_0.11.0_d0e1
305953 0.0737734 >8.e+03 >8.e+03 original
1894610 0.456841 5.306 52.2 cjxl_0.11.0_d0e3``` |
|
2026-01-12 05:30:05
|
there is also enough byte headroom you don't really need to spend 1.5 minutes encoding the images which can't be resampled. |
|
|
|
Traneptora
|
2026-01-12 07:35:59
|
<@384009621519597581> can you add Hydrium to <#822120855449894942> ? |
|
|
|
AccessViolation_
|
2026-01-12 10:16:03
|
cool project btw |
|
|
|
cioute
|
2026-01-13 03:55:06
|
Has jpegxl conceptual cons? |
|
|
|
_wb_
|
2026-01-13 08:42:42
|
You mean like inherent limitations/disadvantages of the format? |
|
|
|
cioute
|
2026-01-14 01:10:43
|
Yes. Maybe exists objective reasons to not adopt/use jpegxl? |
|
|
|
AccessViolation_
|
2026-01-14 01:14:00
|
in my opinion there are some things that could have been done better, but they're all about features that other formats don't have *at all*, so JPEG XL is still a lot beter because it has those features |
|
2026-01-14 01:17:17
|
for example, all the additional custom channels a JPEG XL can have can only use Modular mode encoding, and it would have been nice if they could use VarDCT mode encoding as well. but other competing formats *don't even have* support for arbitrary custom channels, so it's not a reason to not use JPEG XL |
|
2026-01-14 01:20:48
|
I'm curious why you want to know? |
|
|
|
HCrikki
|
2026-01-14 01:29:09
|
there's no particular 'cons'. *your own workflow or stack* may favour generating and serving images in one specific format (that suits you) and thats fine. |
|
2026-01-14 01:31:18
|
one should evaluate wether they even need to use newer formats in the first place. one single average video consumes far more bandwidth than all the images you'll view that day. checked one movie on netflix? it consumed more bandwidth than a month's worth of image viewing |
|
2026-01-14 01:33:37
|
images look good just as long as theyre not bit-starved, even if you stick to oldschool jpeg and png (which have universal support across the entire imaging ecosystem, unlike newer formats which will take time) |
|
|
|
_wb_
|
2026-01-14 02:01:40
|
in terms of operability, the old jpeg will always be unbeatable |
|
|
nacereal
|
2026-01-14 02:03:02
|
Hi. Is there a nice place to read up on the algorithms used in libjxl, specifically as it relates to the MA tree constructions and predictor selection? I'm a student reading through some of the papers and trying to map it to the source and it's a bit overwhelming. I appreciate the help! |
|
|
|
_wb_
|
2026-01-14 02:03:51
|
there's a high-level overview here: https://arxiv.org/abs/2506.05987 |
|
2026-01-14 02:05:38
|
several of the entropy coding techniques used in jxl are discussed in depth in Luca's phd thesis: https://www.lucaversari.it/phd/main.pdf
(including hybriduint configs, context maps, MA trees) |
|
|
|
nacereal
|
2026-01-14 02:06:07
|
Thank you! |
|
|
|
_wb_
|
2026-01-14 02:10:13
|
for predictor selection we don't really have any great algorithm right now, the approach in libjxl is basically just to collect all residuals according to a subset of the predictors (a subset of just 1 or 2 of them at low effort settings, more at higher effort) and use the one with the lowest entropy in each leaf node of the context tree |
|
2026-01-14 02:11:20
|
or rather to collect a sample of all residuals, to reduce the memory cost (the size of the sample can be selected using the -I parameter in cjxl) |
|
|
|
nacereal
|
2026-01-14 02:11:33
|
I'm looking into it because I'm doing an undergrad thesis course and my focus is trying to improve (even marginally) the lossless compression scheme in the reference implementation of jxl |
|
2026-01-14 02:16:02
|
So far I've gotten a high-level grasp of prediction and context modeling, but I've been struggling to map it to the current source code to basically convince myself of how it works. I honestly think I'm just too much of a noob with cpp projects on this level |
|
|
|
_wb_
|
2026-01-14 02:17:50
|
most of the lossless stuff is here: https://github.com/libjxl/libjxl/tree/main/lib/jxl/modular
and here: https://github.com/libjxl/libjxl/blob/main/lib/jxl/enc_modular.cc |
|
2026-01-14 02:20:13
|
but yeah, libjxl is not exactly very easy to understand |
|
2026-01-14 02:21:50
|
we should probably at some point make a more readable encoder from scratch, with more of a focus on readable and modifiable code |
|
|
|
jonnyawsom3
|
2026-01-14 04:19:47
|
Making modular mode's code more modular would be nice |
|
2026-01-14 04:27:11
|
Adding on to that, efforts <10 use Weighted or Gradient, effort 10 uses all predictors (By default, it can be overridden in cjxl with `-P`)
Previously we did some work on lossless to improve progressive and planned to add a new predictor set to optimize for it, but the selection logic seemed to break for most coding tools (Predictor, RCT and pallete selection), so that could be a place to start if you want to give a sizable boost to density (Around 25% smaller in our best case by manually picking an RCT with pallete disabled) |
|
|
|
veluca
|
2026-01-14 07:38:14
|
You could try implementing the DP algorithm for tree learning with a single property from 4.2.1 from my thesis 😄 (or a two-layer version thereof) |
|
|
|
_wb_
|
2026-01-14 11:51:09
|
https://discord.com/channels/794206087879852103/804008033595162635/1460938481936371807
Taking this out of <#804008033595162635>, I wonder if we shouldn't actually add this, that is, an effort setting that is as close to uncompressed as we can get. |
|
2026-01-14 11:53:29
|
Basically e1 but without lz77 and YCoCg, predictor 0 and predefined prefix codes that just map 8-bit numbers to 8-bit numbers, so the 'encoding' is just a memcpy after converting interleaved channels to planar. |
|
2026-01-14 11:56:27
|
Basically using jxl just as an uncompressed format, like ppm but it can have a colorspace and it works in a browser. |
|
|
|
veluca
|
2026-01-14 12:17:29
|
what for? |
|
|
|
Orum
|
2026-01-14 12:28:52
|
any case where you need uncompressed speed |
|
|
|
5peak
|
2026-01-14 12:28:54
|
IMHO the stereo mode could be defined in the standard in order to avoid any issues in the future, but can be done later. |
|
|
pangboy
|
2026-01-14 12:51:14
|
Hi, is there any progress on the lightweight profile? |
|
|
|
jonnyawsom3
|
2026-01-14 01:02:42
|
What do you mean? |
|
|
|
veluca
|
2026-01-14 01:07:11
|
what are use cases in which you'd need more speed than current e1? 😛 |
|
|
|
jonnyawsom3
|
2026-01-14 01:09:22
|
Faster decoding maybe? |
|
|
|
pangboy
|
2026-01-14 01:10:44
|
This is the text I was referring to. I was wondering if there are any plans or discussions regarding the 'Hardware profile' mentioned here. |
|
|
|
jonnyawsom3
|
2026-01-14 01:11:49
|
Ah right. There is a hardware encoder now, but it doesn't have a specific profile |
|
|
|
username
|
2026-01-14 01:13:22
|
there was someone in here a few days/weeks ago who's requirement was absolute real time speed and said that storage/size was not a problem and asked if JXL had an uncompressed mode |
|
2026-01-14 01:13:41
|
actually here I found it: https://discord.com/channels/794206087879852103/794206170445119489/1456619487746064547 |
|
|
|
pangboy
|
2026-01-14 01:16:01
|
I see. Does that mean there are no plans for a specific profile in the near future? |
|
|
|
Orum
|
2026-01-14 01:24:49
|
decode is still slow even with e1 (and fast decode tuning) |
|
|
|
veluca
|
2026-01-14 01:26:19
|
(fast decode does nothing with e1) |
|
|
|
jonnyawsom3
|
2026-01-14 01:26:22
|
Fast decode doesn't effect efforts 1-3, and 2 is the fastest other than FD4 |
|
|
|
_wb_
|
2026-01-14 01:26:59
|
Not in the near future. It will only be relevant if there is demand for hw decode. |
|
|
|
veluca
|
2026-01-14 01:27:19
|
I guess it could make sense to have a mode that is effectively a memcpy (+- interleaving), but that seems fairly specialized |
|
|
|
_wb_
|
2026-01-14 01:28:31
|
For hw encode though there is an interest in a spec change/relaxation to allow toc at the end or some other mechanism that allows hw encode without frame buffer |
|
|
|
AccessViolation_
|
2026-01-14 01:28:52
|
I don't think it would necessarily be bad if hardware decoders in digital cameras only supported the set of features that their cameras produced (or you could do a hybrid approach, where images that aren't tagged as coming from that camera, or those that fail to decode, fall back to a complete software implementation). you don't really need profiles for that use case, in fact doing this without standardized profiles means it's less likely people will try to create limited software encoders too |
|
|
|
Orum
|
2026-01-14 01:29:01
|
well in any case decoding is still a bottleneck at times |
|
2026-01-14 01:29:14
|
and PPM isn't very fun due to lack of metadata |
|
|
|
monad
|
2026-01-14 01:30:26
|
replaces all other formats, and now BMP |
|
|
|
AccessViolation_
|
2026-01-14 01:32:06
|
or maybe digital cameras will opt to support JXL decode fully, and instead use hardware acceleration for specific parts of the codec, rather than all or nothing hardware decoding. who knows |
|
|
|
jonnyawsom3
|
2026-01-14 01:35:00
|
I know Jon mentioned doing the specialised YCoCg for effort 2 and 3 to make them significantly faster, so I wonder how much room there is for a purely decode oriented setting for 0. No RCT, RLE, small groups, ect. Depends how good of a fast path is possible. |
|
2026-01-14 01:41:24
|
Libjxl isn't far off from that already. Instead of ordering LF first along with the TOC, I have a file where it goes LfGlobal, LfGroup x 2, HfGroup x 4, LfGroup, HfGroup x 7, LfGroup
It means libjxl doesn't decode until 98% of the image is loaded, and Oxide only loads 1 complete LF block at a time
https://github.com/libjxl/libjxl/issues/4328 |
|
|
|
5peak
|
2026-01-14 02:25:58
|
ASIC will solve this problem for ever. Just need to gain momentum in the marketplace and mindsets. Takes time_t. |
|
2026-01-14 02:27:24
|
Just l 👀 k at the NETINT. |
|
|
|
AccessViolation_
|
2026-01-14 02:27:40
|
oh yeah don't some AMD CPUs have something like user-programmable FPGAs inside? |
|
2026-01-14 02:27:46
|
I vaguely remember something like that |
|
|
|
5peak
|
2026-01-14 02:28:06
|
They bought Xilinx. |
|
|
|
jonnyawsom3
|
2026-01-14 02:32:57
|
https://xilinx.github.io/Vitis_Libraries/codec/2022.1/benchmark/jxlEnc.html |
|
|
|
_wb_
|
2026-01-14 02:40:57
|
My proposal would be to not touch 18181-1, but to allow in 18181-2 to have `jxlp` (partial codestream boxes) that are out of order; these boxes have an index that currently has to increase in the order of appearance in the file, but if we relax that requirement, an encoder would be much more flexible in the order in which it outputs stuff. Indeed, chunked libjxl would also benefit from that, in the sense that it could produce a codestream that has a section order that makes sense, but written in jxl file with out of order `jxlp` boxes.
Then a decoder would need to do seeking or buffering to properly decode such a file, but it would be easy to write a simple tool to fix the order (or to just concatenate all the `jxlp` boxes in the right order and turn it into a simple `jxlc` box). In fact, a tool like `cjxl` could do that postprocessing by default.
The clean way to do this would be to not allow this in Levels 5 and 10, but to define a new Level 15 for this so existing decoders know (or should know) they may not support this, but it would be easy to make a tool to turn a Level 15 file into a Level 10 file.
WDYT about such a proposal, <@179701849576833024> ? For now this is just me brainstorming, but if we want to consider this path, it could be a good idea to make libjxl and jxl-rs support decoding such files already (even if not efficiently but just by buffering the bitstream until it can go in streaming mode again), so it will already work in most applications by the time it would become spec. |
|
|
|
veluca
|
2026-01-14 02:49:47
|
I hate it 😛 |
|
2026-01-14 02:50:17
|
you can already avoid buffering if you are OK with editing parts of the file afterwards |
|
2026-01-14 02:50:23
|
libjxl does that |
|
|
|
jonnyawsom3
|
2026-01-14 02:53:01
|
Sounds like it would completely disable the progressive nature of JXL, or cause loading in random ordering |
|
2026-01-14 02:54:39
|
I guess the use case of such an aggressive streamed encoder wouldn't really want progressive anyway, but the less work on the end user the better. We're already stuck with non-progressive, non-optimized, 4:2:0 q100 JPEGs because people don't set the flags |
|
2026-01-14 02:56:21
|
Also, that still doesn't account for the TOC at the start, right? So you'd still need to buffer anyway |
|
|
|
_wb_
|
2026-01-14 03:02:02
|
as far as I understood, editing parts of the file afterwards is not always feasible or requires too many system-level complications in some of the use cases of hw encode. But I don't know to what extent it's really a dealbreaker for adoption of the hw encoder or just a "it would be nice". There are some cultural obstacles when I'm communicating with hw folks and many things tend to get lost in translation (literaly). |
|
|
|
5peak
|
2026-01-14 03:03:44
|
Yep, Verilog or SystemVerilog are different languages. |
|
|
|
cioute
|
2026-01-14 03:05:07
|
Because i'm kinda angry about jpegxl adoption is so slow. The response i usually receive is “If jpegxl is so cool, then why doesn’t anyone use it? It definitely must have objective disadvantages.” Well, now i'm looking for them. |
|
|
|
veluca
|
2026-01-14 03:05:44
|
I think <@794205442175402004> is referring to translations to/from Japanese 😛 |
|
|
|
5peak
|
2026-01-14 03:06:36
|
There was a time when browser had plug-ins. Who here remembers Netscape? |
|
|
|
jonnyawsom3
|
2026-01-14 03:06:56
|
I use an Oxide based plugin |
|
|
|
5peak
|
2026-01-14 03:07:08
|
Oh well, C is linugua franca. |
|
|
|
AccessViolation_
|
2026-01-14 03:07:32
|
there was a plugin that enabled JPEG XL in Firefox, but I remember it had some issues |
|
|
|
5peak
|
2026-01-14 03:08:08
|
Retarded via PNG. |
|
|
|
A homosapien
|
2026-01-14 03:08:31
|
Because it wasn't in Chrome the first time. |
|
|
|
5peak
|
2026-01-14 03:08:55
|
Chromium to be precise. |
|
2026-01-14 03:09:19
|
Distorted market. |
|
2026-01-14 03:09:26
|
So badly. |
|
|
|
jonnyawsom3
|
2026-01-14 03:11:05
|
Was in Chrome, then wasn't, now it's in Chrome, Safari, Firefox(soon), Windows, Linux, Adobe, Apple.... |
|
|
whatsurname
|
2026-01-14 03:41:50
|
Well, it would have higher adoption of Chrome was the only browser that does not support it, but it's only available on Safari
Having at least two major browsers even like Safari + Firefox/Edge would give people more confidence
Chrome does play a big role, but saying it's just because it wasn't in Chrome is dishonest |
|
|
|
jonnyawsom3
|
2026-01-14 03:46:53
|
Edge is Chromium |
|
|
|
whatsurname
|
2026-01-14 03:50:21
|
They can have different decisions, like Edge didn't support AVIF until 2024 |
|
2026-01-14 03:51:09
|
And I hope that won't happen again |
|
|
|
_wb_
|
2026-01-14 04:19:46
|
I don't think they really can have different decisions: Edge can decide not to enable something that Chrome does enable by default, but Edge is unlikely to implement and maintain something that Chrome doesn't have. If Chrome would have kept jxl in the codebase but not build it by default, then Edge could maybe have decided to enable it, but Chrome removed it completely. |
|
2026-01-14 04:22:44
|
Essentially there are only two major browsers: Chrome/ium (including Edge etc) is probably around 70%, Safari 28%, all the rest together 2%. |
|
|
|
Orum
|
2026-01-14 04:26:54
|
"I am the 2%" 💪 |
|
|
|
whatsurname
|
2026-01-14 04:28:43
|
Is that only for mobile?
It's 66/15/8/4 for Chrome/Safari/Edge/Firefox according to cloudflare |
|
|
|
jonnyawsom3
|
|
|
_wb_
|
2026-01-14 04:32:20
|
I don't know if anyone has really global stats that include everything, every source of stats has some inevitable bias regarding desktop vs mobile, different regions, etc |
|
|
|
whatsurname
|
2026-01-14 04:34:05
|
Yeah I saw that, hope the evaluation goes well🙏 |
|
|
|
AccessViolation_
|
|
|
whatsurname
|
2026-01-14 04:41:50
|
They can if they think it's worthy, like iirc vertical tabs is supported in Edge before Chromium added it |
|
|
|
5peak
|
|
|
veluca
|
2026-01-14 06:16:25
|
that's UI though, very different from blink |
|
|
Pheubel
|
2026-01-14 06:43:51
|
how do you think the average joe will name jxl files/the extension? "jpeg xl" (djay-peg-eks-el), "jxl" (djay-eks-el) or the wildcard "jxl" (djeks-el) |
|
|
|
A homosapien
|
2026-01-14 07:28:38
|
Some projects refused to adopt JXL *because* it wasn't in any major browser at the time.
Apple's adoption in 2024 certainly changed things for the better. But I believe my point still stands, JXL's adoption would have been much faster if it was in Chromium in 2021 or 2022. |
|
|
|
5peak
|
2026-01-14 07:41:29
|
Wishful thinking. It would be faster if there were at least three competing world wild web browser engines. |
|
|
|
A homosapien
|
2026-01-14 08:06:39
|
"Everything is Chrome~~ in the future~~!" |
|
|
|
monad
|
2026-01-14 08:36:04
|
the average joe will pronounce it "photo" or "meme" or in some cases "gif" |
|
|
|
Pheubel
|
2026-01-14 08:36:19
|
in a way, the fact that browsers have been behind might be a blessing in disguise, as i know my art friend was very annoyed at webp's because nothing else could use it |
|
|
|
Traneptora
|
2026-01-14 11:46:03
|
problem here is the TOC is still before it all so to write the TOC you need to buffer the whole frame to know the endpoints |
|
2026-01-14 11:48:15
|
Because it's new. There's a small number of implementations and it version 1.0 of the main library isn't even our yet |
|
|
|
jonnyawsom3
|
2026-01-14 11:50:03
|
Yeah, I mentioned that here https://discord.com/channels/794206087879852103/794206170445119489/1461011063976886395. Right now libjxl has the worst of both worlds, having to buffer for TOC but still outputting LfGlobal last |
|
|
|
Traneptora
|
2026-01-14 11:51:07
|
ah right |
|
2026-01-14 11:51:37
|
Hydrium uses toc perm to send the file in the order the tiles are sent |
|
2026-01-14 11:52:17
|
I recently figured out how to use presets to avoid buffering all the coefficiente |
|
2026-01-14 11:52:57
|
now I only need to store one tile worth and only buffer the encoded stream |
|
2026-01-14 11:53:23
|
makes life easier |
|
2026-01-14 11:53:31
|
less ram at least |
|
2026-01-14 11:53:55
|
hydrium is pretty low ram even when encoding a standard frame which is the default |
|
|
|
jonnyawsom3
|
2026-01-15 12:13:20
|
It's a shame the tiled images are so slow to decode, wonder if a kReplace/kAdd fastpath would help |
|
|
|
lonjil
|
2026-01-15 12:44:30
|
this appears to be a demonstration of their High Level Synthesis tooling in compiling libjxl into gateware: <https://github.com/Xilinx/Vitis_Libraries/tree/master/codec/L2/demos/jxlEnc> |
|
2026-01-15 12:45:15
|
also I notice that they've got a bunch of stuff in "master" that's not in the newer "main" branch 🤦♀️ |
|
|
|
whatsurname
|
2026-01-15 01:10:57
|
Does it matter? I'm pretty sure Edge has patched blink as well, even some smaller forks do |
|
|
|
lonjil
|
2026-01-15 01:14:58
|
Pretty sure Edge has the windows codec stuff hooked up in addition to Chromium's regular codec support |
|
2026-01-15 01:15:48
|
E.g. if I recall correctly, for a while Edge didn't support AVIF by default, but did if you installed the AVIF OS support thing from the Microsoft store |
|
|
|
whatsurname
|
2026-01-15 01:34:13
|
As you said, it wasn't in *any* major browser
When they decided to remove it in Chromium, Firefox was behind a flag in nightly and further development stopped, and no signal from Safari
Chromium doesn't always need to be the first browsers to add new features
And one good thing about Chromium (or browsers in general) is they get new versions adopted pretty fast, unlike the other of the ecosystem where people are stuck on an old version forever (like many users are not able to update to new Windows/Android)
So even when browser support is a bit falling behind, they can catch up in a short time |
|
|
|
jonnyawsom3
|
2026-01-15 01:36:49
|
> When they decided to remove it in Chromium, Firefox was behind a flag in nightly and further development stopped
> Chromium doesn't always need to be the first browsers to add new features
Those seem a bit contradictory. It took guaranteeing an entire new decoder to get Firefox development back on board |
|
|
|
whatsurname
|
2026-01-15 01:58:27
|
By adding new features I mean enabled by default |
|
|
|
username
|
2026-01-15 02:24:19
|
I think they just do this for Media Foundation stuff (video) and not Windows Imaging Codec stuff (still images) |
|
2026-01-15 02:25:00
|
you don't need the WebP extension in the Microsoft store to use WebP support in Chromium Edge for example |
|
2026-01-15 02:26:45
|
IMO Microsoft are being weird and trying to larp Edge as it's own thing by wanting to have control over JPEG XL being enabled or not |
|
|
|
Pheubel
|
2026-01-15 02:07:56
|
It's annoying that you have to be on windows 11 to download the jxl plugin from the windows store. I am a certified windows 11 hater |
|
|
|
username
|
2026-01-15 02:09:32
|
use this instead: https://github.com/saschanaz/jxl-winthumb |
|
|
|
Pheubel
|
2026-01-15 02:12:22
|
I wonder how jxl support is/will be on the major Linux distros, I've dabbled with it a couple of months ago but plan on dual booting on my laptop for a more in depth exploration |
|
|
|
monad
|
2026-01-15 03:03:37
|
It's pretty good. My 2-year-old OS still uses my manual installation and I don't get thumbnails, but packages are distributed by now <https://repology.org/project/libjxl/versions> |
|
|
|
RaveSteel
|
2026-01-15 03:04:03
|
JXL support is first class since at least 2-3 years ago |
|
|
Fahim
|
2026-01-15 03:04:04
|
Fedora has been using JXL wallpapers by default for a while so libjxl is shipped alongside, Ubuntu will start shipping libjxl out of the box shortly IIRC - outside of that, JXL support has been plumbed through kimageformats and gdk-pixbuf (amongst other relevant libs) so most Qt and GTK apps get JXL support implicitly, in my experience |
|
|
|
RaveSteel
|
2026-01-15 03:05:02
|
wasn't gdk-pixbuf deprecated by glycin? at least for JXL |
|
|
|
Pheubel
|
2026-01-15 03:05:08
|
the power of "fine, i'll do it myself" truly is impressive |
|
|
|
Fahim
|
2026-01-15 03:05:27
|
Probably, I don't dabble much in the GNOME/GTK world so I don't actively keep up with the developments |
|
|
|
RaveSteel
|
|
|
Fahim
|
2026-01-15 03:06:59
|
But anyways, JXL support on Linux is good with minimal issues overall in my experience - I've seen some random ones that I don't recall seeing in a while like e.g. Ark (KDE's archive manager)'s image preview from inside archives having completely borked aspect ratio for the JXL images I was checking but that's about it |
|
2026-01-15 03:08:55
|
And yeah, they use libjxl currently and there's an open issue about swapping over to jxl-rs https://gitlab.gnome.org/GNOME/glycin/-/issues/245 |
|
|
|
RaveSteel
|
|
|
Orum
|
2026-01-15 04:17:05
|
anyone used vipsdisp with JXL? |
|
2026-01-15 04:17:22
|
seems to freeze when I try to open a <:JXL:805850130203934781> with it |
|
2026-01-15 04:18:32
|
|
|
|
|
RaveSteel
|
2026-01-15 04:37:56
|
JXLs load for me, but are completely broken |
|
2026-01-15 04:38:07
|
|
|
|
|
HCrikki
|
2026-01-15 05:08:21
|
Theres more support for jxl on linux than that misleading repology table suggests. Also not factored in millions of autoupdating installs for runtimes and apps like gnome (flatpak and snaps give consistent support everywhere) |
|
|
|
Quackdoc
|
2026-01-15 05:23:17
|
that depends on the application graphical framework 9/10 times |
|
|
Kleis Auke
|
2026-01-15 05:36:38
|
This is likely due to the issue described in PR <https://github.com/libvips/libvips/pull/4830>. I'm not sure about the freeze though. |
|
2026-01-15 05:38:41
|
Just wondering, are you testing this on Windows? |
|
|
|
Orum
|
2026-01-15 05:40:05
|
linux desktop, KDE on wayland |
|
|
|
Kleis Auke
|
2026-01-15 05:40:35
|
I'll try to reproduce on Fedora. |
|
2026-01-15 06:16:49
|
It works fine for me with libvips 8.18 and 8-bit JPEG XL images. It could be possibly due to the new Vulkan renderer introduced in GTK 4.16, which can be worked around by setting the `GSK_RENDERER=gl` env variable (I need to set this system-wide on my old GTX 1070 GPU). |
|
|
|
5peak
|
2026-01-15 06:58:17
|
R374RD3D! |
|
|
|
jonnyawsom3
|
2026-01-15 07:30:30
|
You don't have to speak in code, this isn't TikTok... Though I do agree it's a bit silly of Microsoft to arbitrarily restrict it to Windows 11 |
|
|
|
HCrikki
|
2026-01-15 07:44:16
|
the extension? i doubt it was intentional and just an arbitrary number they chose during private development |
|
2026-01-15 07:46:10
|
store apps are supposed to be consistent between win10 and win11 so the only logical way for an app/extension wouldve since the store apps that would depend on extensions being available *expect them*.
nothing but a check blocks it from installing on win10 |
|
|
|
Traneptora
|
2026-01-15 08:18:17
|
when does win10 hit EOL anyway? |
|
|
|
Orum
|
2026-01-15 08:19:15
|
last year |
|
|
|
jonnyawsom3
|
2026-01-15 08:19:53
|
3 months ago |
|
|
|
Traneptora
|
|
|
HCrikki
|
2026-01-15 08:29:08
|
shouldnt matter in the context of store apps and extensions. at least that was the promise of winstore - apps being installable and updatable whatever your base win10 and newer release channel |
|
|
|
5peak
|
2026-01-16 05:32:16
|
It is artificially restricted. |
|
2026-01-16 05:32:43
|
BBD |
|
2026-01-16 05:33:09
|
Broken By Design™ |
|
|
|
AccessViolation_
|
2026-01-16 08:58:53
|
that word is a slur against autistic people, and using it can evoke a lot of negative emotions in the people around you |
|
2026-01-16 08:59:15
|
I'm sure that wasn't your intention, but I just wanted to let you know so you can decide for yourself whether you want to keep using it |
|
|
|
5peak
|
2026-01-16 09:40:12
|
Better? |
|
|
spider-mario
|
2026-01-16 11:49:48
|
(on that note – “autistic people” tends to be preferred over “people with autism”
https://onlinelibrary.wiley.com/doi/10.1002/aur.2864
https://neuroqueer.com/person-first-language-is-the-language-of-autistiphobic-bigots/
https://theautisticadvocate.com/i-do-not-have-autism/
) |
|
|
|
AccessViolation_
|
2026-01-16 12:08:35
|
edited, thanks for letting me know |
|
|
|
Pheubel
|
2026-01-16 12:27:58
|
as someone with autism, i give you the autism pass to call anti user design autistic |
|
|
|
AccessViolation_
|
2026-01-16 03:25:32
|
idk, different people have different responses to things |
|
|
|
monad
|
2026-01-16 03:26:40
|
the language police don't allow the distribution of such vouchers, it would defeat the point |
|
|
|
lonjil
|
2026-01-16 03:32:55
|
making anti-user designs is very un-autistic |
|
|
|
AccessViolation_
|
2026-01-16 03:44:29
|
LMAO yeah |
|
2026-01-16 03:48:17
|
ugh, don't make me tap the sign
https://xkcd.com/1357/ |
|
|
|
monad
|
2026-01-16 04:47:07
|
i have no idea what's being threatened with "tap the sign", or what that comic has to do with this, but maybe I can at least logically retort "don't make me make you tap the sign" |
|
|
|
Orum
|
2026-01-16 04:48:40
|
https://tenor.com/view/simpsons-tap-the-sign-dont-make-me-dont-make-me-tap-the-sign-do-not-talk-to-driver-gif-22090654 |
|
|
|
AccessViolation_
|
2026-01-16 04:51:41
|
ironically, the sign that is being tapped has a rule written on it, whereas the point I tried to make was that most people are not rule enforcers ("the language police") but rather just speaking out when others are rude to others |
|
|
|
jonnyawsom3
|
2026-01-16 04:53:05
|
<:JXL:805850130203934781> |
|
|
|
AccessViolation_
|
2026-01-16 04:58:48
|
"don't make me tap the sing" in this context just means "I've had to say this a couple of times in other places already" |
|
|
|
monad
|
2026-01-16 05:12:29
|
hm, then if the comic is the content of your message, I guess the retort is "you're an asshole" |
|
|
|
AccessViolation_
|
2026-01-16 05:28:40
|
to be clear, I don't think you're an asshole, that's not what I tried to say at all. your comment about the thought police implied to me that you think people shouldn't be calling out/acting on others for saying hurtful things because that'd be akin to acting like it's illegal. and so my comment to *that* is that those people are rather just calling out rude behavior from assholes and showing them the door. not because they think it shouldn't be allowed, but because they don't like it despite being allowed |
|
2026-01-16 05:29:09
|
I assumed the comic would convey that to some degree, it didn't, that's on me |
|
|
|
Demiurge
|
2026-01-16 08:29:12
|
I don't think people should be sensitive about slur word usage unless you work at a Sunday school or something like that. Most of the time when people use slurs or when people cuss it's usually not out of malice and it's healthier if people grow thicker skin and not allow those words to hurt them, and understand that the person using those words probably didn't have any malice directed at them. |
|
2026-01-16 08:29:44
|
Everyone just needs to relax in general and love themselves and each other. |
|
2026-01-16 08:34:39
|
Even if you think there's something wrong with you because you have a diagnosis, you should not let it get under your skin. At the end of the day, you are the only person who defines who you are, and you don't need to make your own identity revolve around the labels that others shove at you. |
|
|
|
monad
|
2026-01-16 08:57:02
|
<:Agree:805404376658608138> the idea that autistic people are helpless and need white knights to protect them, even from words not directed at anyone, is insulting |
|
|
|
lonjil
|
2026-01-16 09:37:45
|
Why would I think there's something wrong with me? It's the fuckers using slurs who think that. |
|
2026-01-16 09:38:16
|
I've got pretty thick skin but I've come to realize that there's no reason to ever put up with shit. |
|
|
|
spider-mario
|
2026-01-16 09:38:41
|
why would “people finding derogatory use of a word insulting” be allowed to be insulting but not the derogatory use of the word? |
|
2026-01-16 09:39:40
|
policing the “language police” is still policing |
|
|
|
jonnyawsom3
|
2026-01-16 09:40:45
|
In England we take everything in jest, if someone complains then we stop |
|
2026-01-16 10:46:20
|
<@&807636211489177661> It happened again... |
|
|
|
_wb_
|
|
|
jonnyawsom3
|
2026-01-16 10:48:21
|
Same 'brand' as last time too, so we might want to replace the invite links to stop it from automatically rejoining |
|
|
|
username
|
2026-01-16 10:50:33
|
how many active invite links does this server have anyways? |
|
2026-01-16 10:50:53
|
there's a panel somewhere that admins can see |
|
2026-01-16 10:57:12
|
actually since this is a public community server invite links might not even be getting used for this |
|
|
|
Demiurge
|
2026-01-16 10:57:49
|
Slurs and cuss words are, I've observed, most often used for humorous intent and punctuation/emphasis. You should never accept being treated with disrespect, but on the flip side, you should be mindful and understanding of others' intent. Not assuming the worst. And also, the more you love and accept yourself for who you are, the more you are capable of laughing at yourself and the less it matters what words people use. |
|
|
|
monad
|
2026-01-16 11:00:09
|
by definition a derogatory use of a word is insulting. so the first characterization is quite silly |
|
|
|
spider-mario
|
2026-01-16 11:03:03
|
then which “words not directed at anyone” were you referring to? |
|
|
|
veluca
|
2026-01-16 11:03:22
|
I feel like this is a good time to say that this might be a discussion better done in <#806898911091753051> |
|
|
|
Demiurge
|
2026-01-16 11:03:53
|
There are entire communities of people who use slurs and cuss words in literally every sentence and not because they are filled with anger and hatred but because they just take nothing seriously and treat nothing as sacred. |
|
|
|
monad
|
2026-01-16 11:04:37
|
"It is artificially retarded" |
|
|
|
spider-mario
|
2026-01-16 11:08:07
|
do you consider it invalid to view this as derogatory? why would it be any less valid than considering “white knighting” not done on your specific behalf to be insulting? |
|
2026-01-16 11:08:43
|
I am not convinced of the premise that they are not filled with such negative feelings |
|
|
|
monad
|
2026-01-16 11:12:48
|
I consider it not directed at a person. |
|
|
|
AccessViolation_
|
2026-01-17 12:51:37
|
still with the telegram group join shortlinks? we could add that domain as a banned word in the discord automoderator maybe |
|
|
|
monad
|
2026-01-17 01:38:41
|
something like that sounds much more robust. |
|
|
|
Quackdoc
|
2026-01-17 02:33:38
|
is `RGB_D65_SRG_Rel_Lin` right for scRGB? |
|
|
|
spider-mario
|
2026-01-17 03:47:43
|
yes |
|
2026-01-17 03:48:09
|
https://en.wikipedia.org/wiki/ScRGB#Origin_of_sc_in_scRGB
> The origin of the sc in scRGB is shrouded in mystery. Officially it stands for nothing.
😂 |
|
|
|
Quackdoc
|
2026-01-17 03:48:42
|
lmao |
|
2026-01-17 03:48:50
|
"super cool rgb" |
|
|
|
Demiurge
|
2026-01-17 05:45:33
|
Some people are just so used to talking that way, they punctuate every sentence with profanity and slurs yet they do it in the most zany and silly way lile they don't take anything they say seriously, and invite you over for dinner and introduce you to everyone while using the most casual profanity... It's like a hillbilly thing. |
|
2026-01-17 05:55:27
|
It's clear after talking to these people in person that cussing is clearly as natural as breathing to them, but not because they are full of hate and rage but just because they are a bunch of silly clowns who don't take themselves or what they say that seriously, with jokes and absurdities weaved into everything they say seemingly effortlessly |
|
|
|
jonnyawsom3
|
|
|
Quackdoc
|
2026-01-18 06:24:02
|
for some reason this image becomes absolutely massive in jxl, the original jxr its from is 34M https://files.catbox.moe/esrdzo.jxl the jxl is 74.9M
```
height x width: 2160 x 3840
Pixel depth: SixteenFbit
channels: 4
Pixel format: RGB
colorspace is: rgba64half, scRGB
``` |
|
2026-01-18 06:25:27
|
for context a tiff encoded from jxrdecapp is `66M` |
|
2026-01-18 06:26:28
|
oh wait, im saving as 64f my bad |
|
2026-01-18 06:26:31
|
```
box: type: "JXL " size: 12, contents size: 4
JPEG XL file format container (ISO/IEC 18181-2)
box: type: "ftyp" size: 20, contents size: 12
box: type: "jxll" size: 9, contents size: 1
box: type: "jxlc" size: 74853086, contents size: 74853078
JPEG XL image, 3840x2160, (possibly) lossless, 32-bit float (8 exponent bits) RGB
num_color_channels: 3
num_extra_channels: 0
have_preview: 0
have_animation: 0
Intrinsic dimensions: 3840x2160
Orientation: 1 (Normal)
Color space: RGB, D65, sRGB primaries, Linear transfer function, rendering intent: Relative
``` |
|
|
|
jonnyawsom3
|
2026-01-18 06:26:37
|
Immedeate thought was this, but t- yeah https://github.com/libjxl/libjxl/issues/3511 |
|
|
|
Quackdoc
|
2026-01-18 06:26:48
|
ah yeah probably |
|
|
|
jonnyawsom3
|
2026-01-18 06:27:16
|
Was gonna say you're setting it to float16, so it shouldn't have mattered. But f16 stored as f32 is the perfect storm for the regression |
|
|
|
Quackdoc
|
2026-01-18 06:28:02
|
jxr can save as 128bpp so im just defaulting to f32 |
|
|
|
jonnyawsom3
|
2026-01-18 06:35:28
|
I'd be curious what range the actual values have, I'd assume it's not *really* 128bpp but just has that capability |
|
2026-01-18 06:36:28
|
I know .HDR files were a pain since they're not exactly float, so storing as f32 was the only 'guarantee' for precision, but then that pallete bug was the only thing taking it down to the 'real' bitdepth |
|
|
|
Quackdoc
|
2026-01-18 06:42:31
|
jxr is scrgb and the sources are typically game screenshots so there is a good chance it does actually use it. |
|
|
|
jonnyawsom3
|
2026-01-18 06:51:03
|
f16 I could understand since it's fairly common for HDR, but full f32 seems unlikely to me |
|
|
Tirr
|
2026-01-18 07:13:04
|
<@&807636211489177661> <:BanHammer:805396864639565834> |
|
|
|
Quackdoc
|
2026-01-18 02:56:29
|
keep in mind that for scrgb, the minimum is 16bit per channel, 32bit per channel wouldn't be hard to hit at all |
|
2026-01-18 03:31:50
|
oh right and rust f16 is not in a great spot, image-rs doesnt support f16 and using floats is kinda necessary to get the entire benefit of scrgb |
|
|
dogelition
|
2026-01-18 04:31:06
|
iirc windows screenshots are lossless 16 bit and nvidia ones are 32 bit lossy |
|
2026-01-18 04:32:48
|
don't know if there's a good reason for lossy 32 over lossy 16 |
|
|
|
jonnyawsom3
|
2026-01-18 04:50:38
|
Last I checked most game engines weren't running in Rust, and GPUs preferred lower bitdepths |
|
|
|
Quackdoc
|
2026-01-18 05:10:00
|
I mean for my program |
|
2026-01-18 05:10:12
|
I did wind up adding 16bit, but only when the source is in 16bit
```
.rw-r--r-- 75M quack 18 Jan 12:51 /tmp/test-32bit.jxl
.rw-r--r-- 31M quack 18 Jan 13:01 /tmp/test16bit.jxl
.rw-r--r-- 43M quack 18 Jan 12:58 /tmp/test16bit.png
.rw-r--r-- 100M quack 18 Jan 13:00 /tmp/test16bit.tiff
.rw-r--r-- 100M quack 18 Jan 12:57 /tmp/test32bit.tiff
``` |
|
2026-01-18 05:10:19
|
it saves a lot [dogelol](https://cdn.discordapp.com/emojis/867794291652558888.webp?size=48&name=dogelol&lossless=true) |
|
2026-01-18 05:10:50
|
but I got at least one screenshot someone sent me for testing of GTA that does indeed use rgba128bpp |
|
2026-01-18 05:13:34
|
updated code is here, im not bothering with lossy for now but it will save a ton of space https://codeberg.org/Quackdoc/jxr_to_jxl |
|
|
|
RaveSteel
|
2026-01-18 05:17:33
|
Codeberg seems to be down atm |
|
|
CrushedAsian255
|
2026-01-18 05:18:46
|
Any news on jxl + chrome? also i miss this server (haven’t been active lately) |
|
|
|
jonnyawsom3
|
2026-01-18 05:19:08
|
Theoretically, even 31bit would allow pallete to work again, could be a neat test |
|
|
|
RaveSteel
|
2026-01-18 05:19:26
|
JXL was added to chrome and now has 100% adoption. all images are now JXLs |
|
|
|
jonnyawsom3
|
2026-01-18 05:19:47
|
Scroll up in <#803574970180829194> for the past week or two |
|
|
|
Quackdoc
|
2026-01-18 05:26:28
|
working for me, ip issue? |
|
|
|
RaveSteel
|
2026-01-18 05:27:17
|
works again now |
|
2026-01-18 05:31:36
|
Works nicely. Is it intentional that alpha is stripped? |
|
|
|
Quackdoc
|
2026-01-18 05:31:38
|
i made a release that has a windows binary because fuck compiling on windows sucks, but in any case, if anyone wants to try it, it works, though only for scrgb, not pq |
|
2026-01-18 05:32:11
|
yeah, jpegxl-rs for some reason really breaks itself with alpha and I suspect most jxr images only have a meaningless alpha channel |
|
2026-01-18 05:32:39
|
at least considering that only screenshotting tools are the sources ive seen anyways, i can add alpha if there is an image with a meaningful channel to test |
|
|
|
RaveSteel
|
2026-01-18 05:32:40
|
I suspect the same, all of my JXRs have alpha, but no image data there it seems |
|
2026-01-18 05:33:20
|
I converted this Microsoft example JXR to JXL |
|
2026-01-18 05:33:33
|
With alpha the image is much larger than the JXR, while being much smaller if alpha is stripped |
|
|
|
Quackdoc
|
2026-01-18 05:33:35
|
its possible that maybe mpv could generate them lol |
|
|
|
RaveSteel
|
2026-01-18 05:33:52
|
I don't think mpv can write JXRs |
|
2026-01-18 05:34:03
|
It can't even read them lol |
|
|
|
Quackdoc
|
2026-01-18 05:34:22
|
no, but mpv can have translucent windows, which would be the only case where an alpha channel would have significant |
|
|
|
RaveSteel
|
2026-01-18 05:34:27
|
true |
|
2026-01-18 05:34:49
|
let me check what happens when I screenshot a video with alpha |
|
2026-01-18 05:35:59
|
yep, JXL with alpha |
|
|
|
Quackdoc
|
2026-01-18 05:36:29
|
yeah, I suspect to generate a jxr with alpha, you need a video with alpha fullscreened and running in HDR mode |
|
2026-01-18 05:36:40
|
and ofc a screenshot using windows gamebar |
|
|
|
RaveSteel
|
2026-01-18 05:37:18
|
I would love to try it, but I don't have an HDR monitor |
|
|
|
Quackdoc
|
2026-01-18 05:37:37
|
I dont have a windows machine that can do this properly [dogelol](https://cdn.discordapp.com/emojis/867794291652558888.webp?size=48&name=dogelol&lossless=true) |
|
2026-01-18 05:37:47
|
my brother uses atlasOS which has kinda broken hdr support |
|
|
|
RaveSteel
|
2026-01-18 05:38:19
|
ah, one of the "download our debloated windows ISO, better for gaming!" thingies |
|
|
|
Quackdoc
|
2026-01-18 05:39:10
|
yup. it actually works well for him since it solved the issue of massive random battery drain, kinda |
|
2026-01-18 05:39:18
|
still not as good as linux, but better then win10 and win11 |
|
|
|
RaveSteel
|
2026-01-18 05:39:31
|
probably |
|
2026-01-18 05:50:45
|
At which effort are you encoding? |
|
|
|
Quackdoc
|
2026-01-18 06:04:32
|
7, im sure ill add a flag at a later date but 7 is a good default |
|
2026-01-20 03:15:06
|
> Warning: --color_space ignored because the image is not XYB encoded.
<:PepeSad:815718285877444619> |
|
|
|
A homosapien
|
2026-01-20 03:16:52
|
This is libjxl v0.11? |
|
|
|
Quackdoc
|
2026-01-20 03:17:07
|
Probably |
|
2026-01-20 03:17:17
|
yes |
|
2026-01-20 03:17:38
|
does v0.12 allow color managent on lossless |
|
|
|
A homosapien
|
|
|
Quackdoc
|
2026-01-20 03:17:57
|
nice, ~~if only it was released~~ |
|
|
|
A homosapien
|
2026-01-20 03:17:59
|
Man we need to release it soon |
|
|
|
Quackdoc
|
2026-01-20 03:28:14
|
someone sent me this, was hoping djxl could tonemap it to a reasonable brightness but maybe not https://files.catbox.moe/r91whf.jxl
even when I make it lossy its way too hot |
|
2026-01-20 03:28:43
|
|
|
2026-01-20 03:29:06
|
I wonder if there is any way to change exposure range since |
|
2026-01-20 03:33:11
|
tev can make it decent, but I was hoping djxl would be enough |
|
2026-01-20 03:39:59
|
well I need to sleep, ill see about replicating the issue on windows tommorow if I get some free time at work |
|
2026-01-20 03:40:46
|
oops wrong chat |
|
|
|
A homosapien
|
2026-01-20 03:41:21
|
This is the best result I could get straight from djxl |
|
2026-01-20 03:41:43
|
Using PQ transfer curve instead of a Linear one |
|
2026-01-20 03:41:52
|
At least it's not blindingly bright |
|
|
|
jonnyawsom3
|
2026-01-20 04:22:40
|
Just dividing the values by 4 got me this in Krita, both djxl and the standalone tonemapping tool fell flat though |
|
2026-01-20 04:26:04
|
I wonder where it's going wrong, the pipeline *should* be scaling the 0-4 values into 0-1 for int output |
|
2026-01-20 04:37:18
|
Unless it's because the image is really 32f sRGB instead of scRGB? Would explain why it looks fine with just a division and no tonemapping, but trying to change the colorspace while encoding or decoding had no effect |
|
|
|
Traneptora
|
2026-01-20 04:55:46
|
Did they ever fix one of the big cms bugs |
|
|
|
A homosapien
|
2026-01-20 05:05:20
|
Which bug would that be |
|
|
|
Quackdoc
|
2026-01-20 11:37:20
|
nah its scrgb, we can see it when we look at tev |
|
2026-01-20 11:37:30
|
? |
|
|
|
jonnyawsom3
|
2026-01-20 12:04:24
|
<@604964375924834314> any ideas for this? Maybe there's something we're missing, but I'm surprised libjxl isn't rescaling the range |
|
|
|
Traneptora
|
2026-01-20 12:06:57
|
https://discord.com/channels/794206087879852103/804324493420920833/1409591307340615725 |
|
2026-01-20 12:07:04
|
meant to link it and forgor |
|
|
|
spider-mario
|
2026-01-20 12:08:10
|
any chance the `intensity_target` does not actually match the encoded data? |
|
|
|
RaveSteel
|
2026-01-20 12:08:12
|
The Adobe Gainmap Demo app shows it properly it seems |
|
2026-01-20 12:08:30
|
at leats with the default view |
|
|
|
Traneptora
|
2026-01-20 12:10:01
|
What about mpv |
|
|
|
spider-mario
|
2026-01-20 12:10:02
|
ah, wait, it’s lossless floating-point linear sRGB |
|
2026-01-20 12:10:14
|
so then it’s just that the original data goes to 3.78 |
|
2026-01-20 12:10:32
|
`cjxl` does not automatically rescale such data to 0-1 |
|
2026-01-20 12:11:20
|
it behaves pretty much like EXR in this regard |
|
|
|
Quackdoc
|
2026-01-20 01:13:42
|
ah interesting |
|
2026-01-20 01:14:06
|
doesn't work with scrgb I'm assuming because it truncates data outside of 0.0..1.0 |
|
2026-01-20 01:14:16
|
nice to see |
|
2026-01-20 01:15:01
|
I like that, but I wish when doing --color_space=<sRGB line> it would |
|
2026-01-20 01:45:35
|
ah, I mean in the decode process
edit: to be actually clear instead of what I posted before, I wish djxl could color management if requested |
|
|
|
Traneptora
|
2026-01-20 01:46:57
|
can be controlled with --gamut-mapping-mode |
|
|
|
Quackdoc
|
2026-01-20 01:47:17
|
wait really? I'll test that tonight then |
|
|
|
spider-mario
|
2026-01-20 02:10:38
|
for this sort of image file, it doesn’t interact well with jxl’s design: the tone mapping relies on `intensity_target` to know what the maximum luminance in the image is (instead of having to scan the whole image to determine it); `intensity_target` is specified to indicate the luminance of 1.0; the 3.78 of the input has to be preserved if it’s to be truly lossless |
|
2026-01-20 02:11:41
|
it would be best to normalise the input before encoding (e.g. using [`exrnormalize`](http://scanline.ca/exrtools/)), and adjust `intensity_target` accordingly if it’s really meant to be that bright |
|
2026-01-20 02:14:35
|
(or possibly to use libjxl’s `exr_to_pq`) |
|
|
|
Quackdoc
|
2026-01-20 02:24:36
|
ah interesting that's a bit of a downer, though would this still be an issue if we were to convert to xyb? |
|
|
|
spider-mario
|
2026-01-20 02:25:57
|
in the current state of things, it would, although “philosophically”, it would probably make it more “acceptable” to perform that hypothetical rescaling when encoding |
|
2026-01-20 02:26:35
|
(but since the current file is lossless, it can be decoded to EXR, rescaled and reencoded without having to use XYB) |
|
|
|
Quackdoc
|
2026-01-20 02:27:41
|
yeah, I'm just playing around a few ideas. I'm thinking of encoding to jxl xyb for general use, and exr for lossless archival now |
|
|
|
spider-mario
|
2026-01-20 02:27:41
|
(or maybe PFM – it seems we only write 16-bit EXRs) |
|
|
|
Quackdoc
|
2026-01-20 02:28:03
|
pfm I don't think supports 32bit floats does it? at least nothing I've tested supports it |
|
|
|
spider-mario
|
2026-01-20 02:29:13
|
`djxl` seems to write one and `tev` to open it |
|
|
|
Quackdoc
|
2026-01-20 02:29:52
|
ah, I must have messed up my code then |
|
|
DNFrozen
|
2026-01-20 02:36:20
|
hey i haven't paid much attention to jxl in the last 2 years
can someone summarize the current situation?
(like browser support or OS support) |
|
|
|
Quackdoc
|
2026-01-20 02:37:44
|
chrome about to support it, Firefox eventually™️ Linux most de supported perfectly, apple ecosystem good support, android supported only with third party apps |
|
|
|
DNFrozen
|
2026-01-20 02:42:08
|
what changed google's mind about jxl? i thought they just wanted to promote their webp format |
|
|
|
username
|
2026-01-20 02:45:02
|
> i thought they just wanted to promote their webp format
AVIF not WebP.
> what changed googles mind about jxl?
I guess they just couldn't ignore it any longer since It's been one of the most requested features for multiple years straight that other people outside of the Chrome Media team but related to web standards had taken notice |
|
|
|
Quackdoc
|
2026-01-20 02:45:29
|
yeah, and with rust they ran out if reasons lol |
|
2026-01-20 03:02:46
|
do you think it would be worth defaulting to converting it to HLG for lossy and keeping scrgb for lossless?
I thought about PQ but its possible the 10knit limit may get hit in some edge cases. |
|
2026-01-20 03:08:50
|
well "converting" |
|
|
|
Orum
|
2026-01-20 03:10:03
|
if 10,000 nits is ever not enough I don't want to be looking at that image.... |
|
2026-01-20 03:10:49
|
https://tenor.com/view/face-creepy-face-scary-face-face-melting-melting-face-gif-15742598 |
|
|
|
Quackdoc
|
2026-01-20 03:50:31
|
its a rough life |
|
2026-01-20 03:50:43
|
I haven't seen an image but it is possible |
|
|
|
ignaloidas
|
2026-01-20 04:37:06
|
looking at sun directly seems to be roughly equivalent to ~31000 nits if I'm getting my math right, so yeah, would never want over 10000 nits myself |
|
|
VcSaJen
|
2026-01-20 04:39:57
|
Might be useful for illumination via artificial windows in basements and such. Very sci-fi and requires holographic screens, tho. |
|
|
|
dogelition
|
2026-01-20 04:44:08
|
note that HLG has a weird color volume because of the way the EOTF is constructed, so if you set the peak to 1000 nits then you can encode 1000 nits white, but not a pure red/green/blue of the same intensity as is present in 1000 nits white. very confusing
interestingly, in video HLG can actually encode (some? all? i haven't checked) of these technically out-of-HLG values by going beyond limited range. but in a full range image you can't do that |
|
|
|
spider-mario
|
2026-01-20 05:28:13
|
it depends quite a bit on on how high in the sky it is; Wikipedia has it at 600 000 nits at the horizon or 1600 000 000 nits at noon |
|
2026-01-20 05:28:22
|
(https://en.wikipedia.org/wiki/Orders_of_magnitude_(illuminance)#Luminance ) |
|
2026-01-20 05:30:28
|
(edited to fix my off-by-3-orders-of-magnitude error) |
|
2026-01-20 05:31:44
|
so there’s quite a bit of margin before reaching “daylight sun” levels |
|
|
|
Quackdoc
|
2026-01-20 06:15:37
|
yeah, I'm not sure what the best solution is for a user oriented default. in the end, scrgb is hard since it just as too much data |
|
|
|
_wb_
|
2026-01-20 06:18:10
|
10000 nits is roughly how bright the sky is on a clear day, the sun is much brighter than that. |
|
2026-01-20 06:20:03
|
So if you would want to make a display that can pretend to be a window to the outside world, 10000 nits sustained and over most of the area would actually be needed. |
|
|
|
Quackdoc
|
2026-01-20 06:38:27
|
yeah, scrgb is certainly special, representing it in jxl is easy, but I really want to try and leverage the cms capabilities too for end users. |
|
|
|
dogelition
|
2026-01-20 06:46:48
|
what are end users gonna do with the image though, other than viewing it? |
|
|
|
Quackdoc
|
2026-01-20 06:47:36
|
hard to say, not my business, some may want to tonemap, some may want to just view it since its just a simple jxr to jxl tool |
|
2026-01-20 06:47:46
|
I'm thinking of adding a --normalize flag maybe |
|
2026-01-20 06:48:04
|
jpegxl-rs won't work for me tho, I'll need to use sys bindings |
|
|
|
dogelition
|
2026-01-20 06:48:53
|
i think bt.2100 pq as default with the option to keep the data in scrgb as an interchange format makes sense |
|
2026-01-20 06:49:38
|
there's little point in preserving the information in the jxr beyond 10k nits as it wasn't visible when captured anyway |
|
|
|
Quackdoc
|
2026-01-20 06:49:45
|
PQ just has too many limitations though, with HLG I can just use the transfer as is and map 1.0 go the brightest nits |
|
|
|
dogelition
|
2026-01-20 06:49:58
|
what limitations? |
|
|
|
Quackdoc
|
2026-01-20 06:50:00
|
maybe, I'm super hesitant to make that assumption |
|
2026-01-20 06:50:40
|
for one it locks you into wasting bits which is bad for efficiency, not the worst thing ever but a 800nit image has a lot of spare data left |
|