|
|
veluca
|
2023-12-03 01:20:46
|
You probably want prng more than you think 😛 |
|
2023-12-03 01:20:59
|
Especially if you don't allow multiple entries in the table |
|
2023-12-03 01:21:05
|
Collisions are *bad* |
|
|
Traneptora
|
|
|
veluca
|
2023-12-03 01:22:14
|
In particular, you really don't want patterns that are somewhat likely to occur to cause collisions |
|
|
|
Traneptora
|
2023-12-03 01:22:41
|
so youd have say 4bytes in a table, you store its location in the table |
|
2023-12-03 01:23:06
|
and on a hit, you double check and if it works use an LD pair |
|
|
|
veluca
|
2023-12-03 01:24:14
|
That's the standard implementation, yeah |
|
2023-12-03 01:24:28
|
Usually on collision you'd just replace the entry |
|
2023-12-03 01:24:37
|
For faster versions |
|
2023-12-03 01:25:16
|
Other implementations keep a BST in each table entry to look at many possible occurrences |
|
|
|
Traneptora
|
2023-12-03 02:30:04
|
a BST? |
|
2023-12-03 02:30:06
|
what's that |
|
|
|
veluca
|
2023-12-03 02:30:45
|
binary search tree |
|
2023-12-03 02:31:48
|
you can also use suffix arrays, but IIRC all ths attempts at getting those to go faster than whatever brotli-11 does have failed |
|
|
|
Traneptora
|
2023-12-03 03:01:57
|
hm, turning on lz77 for the hf metadata modular stream was big |
|
2023-12-03 03:02:21
|
apparently I had a lot of waste there |
|
2023-12-03 03:03:43
|
something I'm struggling with is how to set Lz77MinSymbol tho if tokens extend throughout the alphabet |
|
2023-12-03 03:04:35
|
like say for ans, we're limited to 8bit tokens so what if they all occur |
|
2023-12-03 03:05:26
|
since it's based on the token, not the hybrid integer |
|
|
|
veluca
|
2023-12-03 03:30:47
|
depends on the hybrid integer encoding |
|
2023-12-03 03:31:00
|
if say you do 000, you'll never get a token higher than 20 or so |
|
2023-12-03 03:31:27
|
and with say 440 or so 100 is still a very safe upper bound |
|
2023-12-03 03:31:42
|
IIRC libjxl does 224, and that's likely enough for most things |
|
|
|
Traneptora
|
2023-12-03 11:54:38
|
what if it's not, is the question |
|
|
|
veluca
|
2023-12-03 11:55:03
|
depends on the hybrid uint you use |
|
2023-12-03 11:55:29
|
it's enough for the default one as long as you don't have 60 or so bits per channel |
|
2023-12-03 11:56:08
|
and the non-default ones are chosen only if they are enough 😛 |
|
|
|
Traneptora
|
2023-12-03 11:56:48
|
I'm looking primarily at the HF coefficient stream at this point |
|
|
|
veluca
|
2023-12-03 11:57:06
|
if you don't do distance 1e-5, 224 will be enough |
|
|
|
Traneptora
|
2023-12-03 11:57:20
|
ah, okay |
|
|
|
veluca
|
2023-12-03 11:57:43
|
I did not compute the exact distance you can get down to |
|
|
|
Traneptora
|
2023-12-03 11:57:43
|
distance 1e-5? |
|
|
|
veluca
|
2023-12-03 11:57:55
|
but 0.1 is enough, and there's no reason to go below xD |
|
2023-12-03 11:58:26
|
you need something like `-log(distance) * 4 * (some constant I cannot compute now) >= 224` |
|
2023-12-03 11:58:41
|
you need some small number for that to happen xD |
|
2023-12-03 11:58:56
|
(there's probably an additive constant of `12` or so too) |
|
|
|
Traneptora
|
2023-12-03 11:59:11
|
so far libhydrium has fixed quality that ends up ssimulacra2ing at 85 or so |
|
2023-12-03 11:59:22
|
for photos |
|
|
|
veluca
|
2023-12-03 11:59:55
|
yeah you'll be fine |
|
2023-12-04 12:00:07
|
I'll be surprised if you ever see a symbol above 80 |
|
|
|
Traneptora
|
2023-12-04 12:00:13
|
I also cap rle length to 128 |
|
|
|
veluca
|
2023-12-04 12:00:25
|
that should not matter |
|
|
|
Traneptora
|
2023-12-04 12:00:33
|
not sure if that is ideal |
|
2023-12-04 12:00:45
|
idr why I chose 128 |
|
|
|
veluca
|
2023-12-04 12:00:50
|
I'm surprised you get any rle at all on HF |
|
|
|
Traneptora
|
2023-12-04 12:01:02
|
I could just turn it off |
|
2023-12-04 12:01:08
|
probably no point |
|
2023-12-04 12:01:23
|
my cluster map for HF is fun tho |
|
2023-12-04 12:01:42
|
I found separating out prev into separate clusters helped |
|
2023-12-04 12:01:49
|
and I use 7 1 0 |
|
2023-12-04 12:02:06
|
er, 7 1 1 |
|
|
|
veluca
|
2023-12-04 12:02:21
|
so you entropy code the sign bit? |
|
|
|
Traneptora
|
2023-12-04 12:07:57
|
apparently it helps |
|
2023-12-04 12:08:10
|
from experimentation |
|
|
VcSaJen
|
2023-12-04 12:44:06
|
I see that some people use jxl as a benchmark of OS speed, like comparing linux and windows. Doesn't it show more about specific libjxl builds than about OSes? |
|
|
|
Traneptora
|
2023-12-04 01:13:16
|
it doesn't say much about OSes themselves but I haven't seen that used as a benchmark personally to compare operating systems |
|
|
|
VcSaJen
|
2023-12-04 01:52:37
|
https://www.phoronix.com/review/threadripper-7995wx-linux-5/2 |
|
|
190n
|
2023-12-04 02:02:41
|
it's phoronix, they test everything |
|
|
gb82
|
2023-12-04 07:20:20
|
based |
|
|
|
Traneptora
|
2023-12-04 07:21:06
|
look at the g++ options and then go ??? |
|
2023-12-04 07:21:17
|
libjxl forces -O2 but it's still funny |
|
|
yurume
|
2023-12-04 09:24:26
|
oh btw I recently learned that GCC has moved SLP vectorization from -O3 to -O2 about a year ago |
|
2023-12-04 09:25:38
|
I always had some concern for projects that default to -O2, thus not benefiting from vectorization when compiled with GCC, but that is now the past (and that past turned out to be recent enough for me to not know) |
|
2023-12-04 09:26:46
|
for me vectorization was the main reason to use -O3, so it's significant |
|
|
spider-mario
|
2023-12-04 05:00:39
|
fwiw, we’re soon going to stop doing that |
|
2023-12-04 05:01:03
|
we’re cleaning up the cmake build a bit, and removing the forced -O2 is part of that PR |
|
|
Demiurge
|
2023-12-04 11:02:09
|
Ubuntu and Windows are garbo, what else is new :) |
|
|
|
afed
|
2023-12-04 11:05:54
|
for libjxl it's mostly gcc |
|
|
MSLP
|
2023-12-04 11:06:00
|
I wonder how much of this is different default compilers for those systems, ie. what would be performance of Debian Trixie testing run under WSL on Win11 |
|
|
|
Traneptora
|
2023-12-05 02:51:46
|
im a little bit surprised by -fPIE instead of -fPIC |
|
|
|
yurume
|
2023-12-06 08:41:53
|
out of curiosity: is there any non-libjxl encoder ever attempted? |
|
|
Tirr
|
2023-12-06 08:45:05
|
[hydrium](https://github.com/Traneptora/hydrium) by <@853026420792360980>, and [zune-jpegxl](https://crates.io/crates/zune-jpegxl) |
|
|
|
yurume
|
2023-12-06 08:48:26
|
oh wait, how I did miss hydrium after all |
|
2023-12-06 08:48:36
|
I thought it is a decoder until right now |
|
|
Jyrki Alakuijala
|
2023-12-06 11:17:54
|
libjxl-tiny could be considered -- and possibly the hardware efforts based on it |
|
|
|
spider-mario
|
2023-12-06 03:32:37
|
PR which is now merged |
|
|
|
afed
|
2023-12-06 04:07:07
|
was there any cmake changes for jpegli, to compile libjpeg-compatible dlls also for windows?
https://discord.com/channels/794206087879852103/804324493420920833/1181260718016823369 |
|
|
|
spider-mario
|
2023-12-06 04:08:42
|
no specific effort to that end, but it should be easier to do now that libjxl at least builds again on windows |
|
|
|
Traneptora
|
2023-12-06 11:22:57
|
Lynne contacted me and asked me to help her design JXL encapsulation in AVTransport, a transport and storage container she is working on (formerly QProto) |
|
2023-12-06 11:23:31
|
The design goals include progressive decode and seek |
|
2023-12-06 11:37:18
|
my proposal was basically:
- ignore 18181-2, because Exif et.al. is already specified. only encalsulate codestresms
- Define a Codestresm to be a header followed by one or more Frames
- Define a Frame to be a FrameHeader followed by one or more DataSection
- Each Header, FrameHeader, and DataSection is a Section
- Each Packet MUST NOT cross Section boundaries.
- Sections MUST NOT be reordered.
- Sections SHOULD occur in their own packets.
- Zero-size Sections SHOULD NOT not be packetized.
- Container-level orientation fields MUST be zero.
- If the image is not XYB encoded, container-level color data, if present, SHALL agree with the codestream.
- If the image is XYB encoded, and the container-level color metadata does not agree with the codestream data, the codestream color data takes precedence.
- A Frame is either Presented or Not Presented. A Presented Group contains zero or more complete Not Presented Frames followed by exactly one Presented Frame.
- For an animated image, a Presented Frame is defined to have nonzero duration. For other images, a Presented Frame is type Regular or SkipProgressive.
- Each Presented Group MUST occur in separate packets. |
|
2023-12-06 11:40:08
|
Any other thoughts and siggestions? |
|
2023-12-06 11:42:48
|
The container can tag presented frames as I or P, based on whether they backreference or not |
|
2023-12-06 11:44:48
|
One tossup is jbrd |
|
|
Quackdoc
|
2023-12-07 07:47:59
|
`cjxl -e 3 -d 1` vs `cjxl -e 3 -d 1 --faster_decoding=2` the speed is beccoming quite nice, it's a shame that `--faster_decoding=2` is the exact same as `--faster_decoding=4`
https://cdn.discordapp.com/attachments/673202643916816384/1182221413357195276/image.png
https://cdn.discordapp.com/attachments/673202643916816384/1182221413856313384/image.png
https://cdn.discordapp.com/attachments/673202643916816384/1182221277776314398/image.png
https://cdn.discordapp.com/attachments/673202643916816384/1182221278430634014/image.png |
|
|
|
Traneptora
|
2023-12-07 05:56:13
|
does JBRD typically benefit from compression? |
|
|
_wb_
|
2023-12-08 07:18:42
|
JBRD is already brotli compressed |
|
2023-12-08 07:19:09
|
Which is why we don't allow it in a brob box — that would be pointless |
|
2023-12-08 07:22:22
|
Since the JBRD can contain any unrecognized app marker content, which is often very compressible, we defined it so that JBRD is always Brotli compressed — the encoder can of course choose how much effort to spend on the brotli encoding |
|
|
|
Traneptora
|
2023-12-08 02:37:49
|
can jbrd data be uncompressed |
|
2023-12-08 02:38:03
|
I ask because AVTransport can compress packets with Zstd |
|
2023-12-08 02:38:12
|
and I was wondering if it would make sense to disallow it for JBRD packets |
|
|
|
veluca
|
2023-12-08 03:04:30
|
brotli can not-compress IIRC |
|
|
|
Traneptora
|
2023-12-08 03:38:08
|
I guess it probably makes the most sense to not disallow Zstd compression and just add a footnote that says jbrd data is already brotli-compressed so Zstd is not recommended |
|
2023-12-08 03:38:27
|
but not forbidden, as theoretically a sender could compress it with "not compressed" and then use the protocol-level Zstd |
|
2023-12-08 04:09:59
|
Is a `jbrd` box permitted to occur after the codestream in a 18181-2 container file? |
|
|
|
afed
|
2023-12-08 04:56:32
|
but brotli has better compression for this type of data or less deps is critical? |
|
|
|
Traneptora
|
2023-12-08 04:57:55
|
I don't know, but it probably makes more sense to just not disallow it |
|
2023-12-08 04:57:59
|
as it's more work for implementation |
|
2023-12-08 04:58:11
|
most packets already aren't compressed, as most of the time it makes no sense |
|
2023-12-08 04:58:16
|
it's mostly there for compressing subtitle packets |
|
|
|
afed
|
2023-12-08 05:02:59
|
subtitles I think are also better compressed with brotli and isn't brotli support mandatory for jxl as standard or it's become optional? |
|
2023-12-08 05:13:49
|
subtitles as text data, markup/tags, even subs as uncompressed images are very suitable for brotli (better than zstd) |
|
|
|
Traneptora
|
2023-12-08 05:36:27
|
I'm referring to AVTransport |
|
2023-12-08 05:36:39
|
it can optionally compress packets with Zstd |
|
2023-12-08 05:36:52
|
subtitles are unrelated to how JXL is encasulated inside AVTransport |
|
2023-12-08 05:37:01
|
but it's an example of why compressed packets are supported |
|
|
|
afed
|
2023-12-08 06:02:34
|
i see, i used to compare brotli on typical subtitles and even brotli 5-6 was better than zstd 22 with 80x faster compression, decompression was slower, but for such speeds and sizes it doesn't matter
but mostly what i see is that everyone is using zstd for some internal compression |
|
|
lonjil
|
2023-12-08 06:41:17
|
does this have anything to do with Brotli having a built in dictionary, perhaps? |
|
|
|
afed
|
2023-12-08 06:56:14
|
yeah, but also higher compression in general (but slower decompression) and on large data the dictionary has a negligible impact |
|
|
|
Traneptora
|
2023-12-08 07:27:53
|
faster decompression actually matters |
|
2023-12-08 07:28:07
|
it's the primary reason Arch switched from .pkg.tar.xz to .pkg.tar.zst |
|
2023-12-08 07:29:19
|
when file sizes get large enough that the difference in file size is not negligible, the decompression speed will tend to matter a lot |
|
2023-12-08 07:29:56
|
that being said the fixed dictionary of brotli def helps in that regard |
|
|
|
spider-mario
|
2023-12-08 07:31:08
|
true, although xz decompression was quite slow, much more so than brotli |
|
2023-12-08 07:31:37
|
brotli is quite fast to decompress |
|
|
|
Traneptora
|
2023-12-08 07:31:57
|
in either case, I think for a transport protocol IMO it makes more sense to use a generic compression algorithm than a text-focused algorithm, like brotli |
|
2023-12-08 07:32:04
|
Zstd is generic in that regard |
|
|
|
spider-mario
|
2023-12-08 07:33:18
|
so is brotli, save for its dictionary |
|
2023-12-08 07:33:25
|
reportedly, its original application was font compression |
|
|
|
Traneptora
|
2023-12-08 07:34:47
|
hm. that's the other case where compressed packets likely will be used in avt, so I'll ask Lynne what she thinks |
|
|
|
afed
|
2023-12-08 08:06:23
|
yeah, but brotli decompression is not as slow as lzma and it is also a generic compressor (inherently very similar to zstd and if given the same optimization would probably have even higher decompression speeds but slightly slower compression and also with the potential for better density) |
|
|
|
Traneptora
|
2023-12-08 08:06:59
|
that being said she might care about certain requirements like "how lightweight an implementation must be" |
|
2023-12-08 09:29:06
|
I ran the idea past lynne and she thinks it's a good idea. especially considering that browsers already support brotli anyway |
|
|
|
afed
|
2023-12-08 09:37:04
|
just for jbrd or also for something else? |
|
|
|
Traneptora
|
2023-12-08 09:37:16
|
no, for the avtransport compression |
|
2023-12-08 09:37:33
|
compression is not defined specifically for jbrd packets, it's defined for any packet but is usually disabled |
|
|
|
afed
|
2023-12-08 09:38:13
|
so it'll be possible to compress subtitles and such? |
|
|
|
Traneptora
|
2023-12-08 09:42:29
|
subtitles, fonts, etc. |
|
|
OkyDooky
|
2023-12-11 07:26:13
|
Anybody familiar with Android app development know how difficult it would be to add encoder/decoder support in a Flutter gallery app lile Aves? I looked at Flutter's relationship with JXL support a few months back and it was...not great, to say the least. |
|
|
|
Quackdoc
|
2023-12-11 07:52:31
|
easy, take my media-kit fork which builds JXL rebase the simple patch to update it, build that into aves, take aves avif fallback support and add jxl to it |
|
2023-12-11 07:53:05
|
aves just uses MPV for playback so its actually pretty easy, you do run into the standard size limitations, but 90% of jxl images should be compatible for now |
|
2023-12-11 07:54:18
|
that or take jxl-oxide plumb that up to flutter since flutter integration with rust is really good,more effort, but much better for long run |
|
|
|
_wb_
|
2023-12-11 08:22:15
|
Yes, there is no obligatory order. |
|
|
|
Traneptora
|
2023-12-11 11:18:10
|
Ah okay good |
|
|
|
OkyDooky
|
2023-12-11 07:32:50
|
Thank you, guys. <@184373105588699137> would you be willing to paste some of your info (like the link to your fork) into the issue tracker for JXL support in Aves?
https://github.com/deckerst/aves/issues/56
I think it would be better than me dharing screenshots or trying to act as a go-between for people who know what they're talking about way more than I do. |
|
|
|
Quackdoc
|
|
|
OkyDooky
|
2023-12-12 02:47:58
|
Thanks, duck healer. I just got the notification from the thread.
(<@184373105588699137>) |
|
|
qdwang
|
2023-12-13 01:34:22
|
hi guys, if i want to use the latest libjxl(not cutting edge nightly version), should i build the `v0.9.x` branch? or the `v0.9-snapshot` tag? |
|
|
jonnyawsom3
|
2023-12-14 11:56:58
|
Part of me did wonder, would it be possible to add a WASM decoder to this progressive loading demo? Or at least update the warning since Chrome has no support currently
https://github.com/google/attention-center |
|
|
diskorduser
|
2023-12-17 07:39:01
|
The latest libjxl is just 0.8.2 |
|
|
fab
|
2023-12-17 09:33:56
|
<@226977230121598977> 10:32am update improves Firefox nightly design |
|
|
DZgas Ж
|
2023-12-17 09:42:10
|
fuck them, now i use Google chrome downloaded from the Google website |
|
|
|
OkyDooky
|
2023-12-18 06:48:09
|
Cut your nose to spite their face. I like it. Lok
(<@226977230121598977>) |
|
|
|
DZgas Ж
|
|
|
Traneptora
|
2023-12-27 07:27:47
|
did -e10 get disabled? |
|
2023-12-27 07:28:11
|
```
JPEG XL encoder v0.10.0 26d32cab [AVX2]
Invalid flag value for --effort: Valid range is {1, 2, ..., 9}.
``` |
|
|
|
veluca
|
2023-12-27 07:42:47
|
--allow_expert_options |
|
|
|
Traneptora
|
2023-12-28 03:03:43
|
why should you need to pass --allow_expert_options |
|
2023-12-28 03:03:52
|
they should still *work* |
|
|
|
afed
|
2023-12-28 03:13:03
|
too slow for normal use, so that people make sure they really need it before using |
|
|
|
Traneptora
|
2023-12-28 03:56:27
|
just feels weird that you need an "I'm sure" button |
|
|
|
yurume
|
2023-12-28 03:57:04
|
but otherwise people will mindlessly put `-e 10` and conclude it's too slow |
|
|
|
Traneptora
|
2023-12-28 03:57:17
|
I mean, it's not documented |
|
2023-12-28 03:57:27
|
it says 1 though 9 |
|
2023-12-28 03:57:45
|
unless you use -h -h -h |
|
2023-12-28 03:58:11
|
zstd has a similar --ultra command that enables 19 through 22 |
|
2023-12-28 03:58:20
|
and it's weird |
|
|
|
yurume
|
2023-12-28 03:58:54
|
maybe then `e10` should be a non-numeral switch like `-e bruteforce=10`? |
|
|
|
Traneptora
|
2023-12-28 03:58:59
|
contrast with xz which just says in the docs that it doesn't make sense to -9 everything, unlike gzip |
|
2023-12-28 03:59:33
|
yea, or even -e bruteforce or -e placebo |
|
|
|
yurume
|
2023-12-28 03:59:35
|
I have seen enough people just using `xz -9` and made everything needlessly slow, so I don't think xz makes a good precedent |
|
|
|
Traneptora
|
2023-12-28 04:00:07
|
xz -9 tho tbf mostly makes the dictionary too large |
|
2023-12-28 04:00:24
|
which is more an issue of memory, not cpu |
|
|
|
Quackdoc
|
2023-12-28 04:06:11
|
yeah but lets be honest, how many people does this actually stop https://cdn.discordapp.com/emojis/867794291652558888.webp?size=48&name=dogelol&quality=lossless |
|
2023-12-28 04:06:27
|
maybe im bias since I hang around the compression folk in general |
|
2023-12-28 04:06:38
|
but its certainly not only once or twice ive seen it, ofc can just make e10 better :D |
|
|
|
jonnyawsom3
|
2023-12-28 04:50:51
|
The main issue with e10 is using practically a GB of RAM per MP |
|
|
|
qdwang
|
2023-12-28 05:16:18
|
Hi guys, is it possible to check the distance used for a converted JXL file? |
|
|
|
Demiurge
|
2023-12-28 05:35:51
|
For a new image format trying to gain adoption, it's important it doesn't accidentally shoot early adopters in the foot in a way that leaves them unpleasantly surprised or leaves a weird taste in the mouth. Like handing out options like e10 to people who don't know how different it is from e9 |
|
|
|
yurume
|
2023-12-28 05:41:08
|
I think there is no such metadata recorded. in comparison you can guess the *effort* (`-e#`) based on features used. |
|
|
monad
|
2023-12-28 07:12:24
|
I suggest `-e braindead` or change the permissive flag to `--allow_dumb_options`, perchance dissuading more people. |
|
|
|
qdwang
|
2023-12-28 08:31:34
|
thank you. I'll have a try |
|
|
w
|
2023-12-28 09:05:48
|
it shouldnt be under -e |
|
|
Jim
|
2023-12-28 09:29:21
|
-eeeeeeeeeeeeeeeeeeeeeeeeeee is much better. Having to look up and get the exact number of e's would keep people from accidentally using it while preventing the need for --allow_expert_options <:kekw:808717074305122316> |
|
|
|
veluca
|
2023-12-28 09:47:49
|
if it was produced by libjxl, you can reverse-engineer it from the bitstream |
|
2023-12-28 09:47:54
|
it's a bit of a pain though |
|
|
|
jonnyawsom3
|
2023-12-28 10:30:56
|
I was going to say, for an extremely rough idea if you have the original file too, you could run ssimulacra2 on it to get a quality value |
|
|
Kejchi
|
2023-12-28 10:35:02
|
Hey, guys. Can you help me please? I want to apply lossless recompression to a jpeg file. I do "cjxl.exe file.jpeg file.jxl" and it works great. But I want to copy the attributes from the old file to the new file. The ones that are "Created, Modified, Accessed". I know for sure that irfanview knows how to save attributes, but it doesn't know how to recompress, only convert. |
|
|
damian101
|
2023-12-28 10:44:13
|
I think those are filesystem attributes? |
|
|
|
Kejchi
|
|
RockPolish
|
2023-12-28 11:02:52
|
for the modified date in powershell you can do `(Get-Item file.jxl).LastWriteTime = (Get-Item file.jpeg).LastWriteTime` |
|
|
|
Kejchi
|
2023-12-28 11:05:28
|
Thank you. Already thinking how to write a script that will take all the images, recompress them and change attributes. |
|
2023-12-28 11:32:40
|
This is what I was able to write. Thanks again.
`$files = Get-ChildItem -Path . -Filter "*.jp*g" -File
foreach ($file in $files) {
$name = $file.BaseName
$jxl = "$name.jxl"
& .\cjxl.exe $file $jxl
$newFile = Get-Item -Path $jxl
$newFile.CreationTime = $file.CreationTime
$newFile.LastWriteTime = $file.LastWriteTime
$newFile.LastAccessTime = $file.LastAccessTime
}
pause` |
|
|
|
RockPolish
|
2023-12-28 11:34:28
|
looks good, glad to have helped |
|
|
CrushedAsian255
|
2023-12-28 12:28:01
|
lol I use xz -9ek and just let it run overnight |
|
2023-12-28 12:28:17
|
That is when I’m not using SquashFS |
|
|
|
jonnyawsom3
|
2023-12-28 12:50:03
|
Since Jpeg recompression is so fast and efficient, you *could* set it to `-e 9` too for some extra savings, although it *will* slow down the process to a second for large images
Also, smart idea to filter both jpg and jpeg extensions, I wouldn't have thought of that |
|
|
|
Kejchi
|
2023-12-28 01:05:17
|
Does the effort parameter affect recompression?! Omg, I didn't know that. And if I try `--allow_expert_options`, can I put `-e 10`?
I already rewrote a script for powershell 7 with parallel execution.
`$files = Get-ChildItem -Path . -Filter "*.jp*g" -File
$files | ForEach-Object -Parallel {
$name = $_.BaseName
$jxl = "$name.jxl"
& .\cjxl.exe $_ $jxl
$newFile = Get-Item -Path $jxl
$newFile.CreationTime = $_.CreationTime
$newFile.LastWriteTime = $_.LastWriteTime
$newFile.LastAccessTime = $_.LastAccessTime
} -ThrottleLimit 10` |
|
|
|
jonnyawsom3
|
2023-12-28 01:06:30
|
~~un~~fortunately `-e 10` is only for lossless encoding from pixels, and I'd highly discourage using it on jpegs even if it were possible due to their usual large dimensions |
|
2023-12-28 01:09:25
|
I'd try a modest folder of images on both default and `-e 9` to see how much of a difference in size and speed it makes for you, it might not be worth it if you're converting everything, and you can always transcode back to the original jpeg, then run on max settings later |
|
|
|
Kejchi
|
2023-12-28 01:12:05
|
We need testers with lots of free time 😅 |
|
|
|
jonnyawsom3
|
2023-12-28 01:47:07
|
Well, since it's *mostly* singlethreaded anyway, most could just run in the background |
|
|
|
qdwang
|
2023-12-28 02:27:05
|
why the recommend quality range is 68 - 96? Is 96 a optimal value for quality and size? If i want a visual lossless quality, should I go for 96, 97, 98 or 99? |
|
|
yoochan
|
2023-12-28 02:36:55
|
You should go for -d 1.0 (d for distance) |
|
2023-12-28 02:37:28
|
Is your source jpeg or png? |
|
|
|
_wb_
|
2023-12-28 03:47:18
|
q90/d1 is supposed to be visually lossless in normal viewing conditions. If you want to remain visually lossless when zooming in, or keep some margin for further editing, you can use a better quality, but for image delivery q90/d1 is more or less the best quality you'll need. Typically you can get away with d2-3 (q70-80). |
|
|
|
jonnyawsom3
|
2023-12-28 03:54:30
|
d2-3 for web use, d1 for normal viewing, d0.3 for zooming/high quality is my rough guideline |
|
|
|
qdwang
|
2023-12-28 03:58:52
|
souce is 14bit raw |
|
|
|
Quackdoc
|
2023-12-28 04:07:51
|
i just always do 0.5 universally |
|
|
|
qdwang
|
2023-12-28 04:32:36
|
Can I think **Butteraugli Distance** like this:
* 1 is visually lossless for 100% zoom level viewing
* 0.5 is visually lossless for 200% zoom level viewing
* 0.25 is visually lossless for 400% zoom level viewing
* 0.125 is visually lossless for 800% zoom level viewing |
|
|
|
spider-mario
|
2023-12-28 04:40:33
|
I think this implies a stricter fit than we have gone for |
|
|
|
lonjil
|
2023-12-28 04:42:46
|
What does 100% zoom mean in terms of pixels per degree, anyway? |
|
|
|
spider-mario
|
2023-12-28 04:48:48
|
from what I remember, a viewing distance of ~900 pixels away from the screen |
|
2023-12-28 04:50:25
|
so about 16 PPD |
|
|
|
damian101
|
2023-12-28 05:05:05
|
when interpreted as sRGB transfer and displayed at 80 nits peak brightness... |
|
|
|
qdwang
|
2023-12-28 06:05:18
|
It seems d0.5 can still have compression pattern on the photo when increasing the brightness of the shadow part. |
|
|
|
veluca
|
2023-12-28 07:41:50
|
that's not entirely surprising - increasing the brightness is not something the encoder considers when deciding what artefacts are visibile |
|
|
|
damian101
|
2023-12-28 08:00:01
|
jxl assumes 80 nits peak brightness and sRGB transfer curve |
|
|
|
veluca
|
2023-12-28 08:25:26
|
> and sRGB transfer curve
no it doesn't assume that 🙂 |
|
|
|
damian101
|
2023-12-28 08:29:18
|
it does, if no source metadata is present |
|
2023-12-28 08:30:43
|
And it always targets 80 nits, even for transfer curves like PQ or HLG, unless that has been fixed (should be 10000 and 1000 respectively instead) |
|
|
|
Quackdoc
|
2023-12-28 08:30:49
|
I wish jxl had cicp support which afaik it doesn't and will only save it as an ICC, this is what happens in the case of ffmpeg when encoding a video to a jxl sequence https://cdn.discordapp.com/attachments/587033245061873759/1189712501475127296/image.png?ex=659f291c&is=658cb41c&hm=d64dac483c1e5030d31aee63bbe447286e28c4d4a007054c4a15aebcf5ce2ea4& |
|
|
|
damian101
|
2023-12-28 08:31:31
|
Yes |
|
2023-12-28 08:31:43
|
also because I need my gamma 2.2 transfer |
|
|
|
spider-mario
|
2023-12-28 08:32:14
|
it supports a subset of CICP |
|
2023-12-28 08:33:17
|
and `cjxl` should definitely set intensity_target appropriately for PQ and HLG input; if it doesn’t, please file a bug with details |
|
2023-12-28 08:34:04
|
hm, did we lose that code |
|
|
|
Quackdoc
|
2023-12-28 08:37:06
|
all I know is that im glad my editor allows me to specify input format properly :D |
|
|
|
damian101
|
2023-12-28 08:38:34
|
already reported it in <#848189884614705192> a while ago...
https://discord.com/channels/794206087879852103/848189884614705192/1164541492510068777
https://discord.com/channels/794206087879852103/848189884614705192/1173651910167904296 |
|
2023-12-28 08:38:47
|
where are jxl bug reports filed? |
|
2023-12-28 08:38:50
|
GitHub? |
|
|
|
spider-mario
|
2023-12-28 08:45:24
|
yes |
|
2023-12-28 08:45:28
|
I don’t seem to be encountering the issue |
|
2023-12-28 08:45:48
|
```shell
$ tools/cjxl .../ClassE_507.png 507.jxl
JPEG XL encoder v0.10.0 88671ac53 [AVX2,SSE4,SSE2]
Encoding [VarDCT, d1.000, effort: 7]
Compressed to 179.1 kB (1.406 bpp).
944 x 1080, 1.474 MP/s [1.47, 1.47], 1 reps, 32 threads.
$ tools/jxlinfo 507.jxl
JPEG XL image, 944x1080, lossy, 16-bit RGB
intensity_target: 10000.000000 nits
min_nits: 0.000000
relative_to_max_display: 0
linear_below: 0.000000
Color space: RGB, D65, Rec.2100 primaries, PQ transfer function, rendering intent: Relative
``` |
|
|
|
Demiurge
|
2023-12-29 01:07:27
|
libjxl and jpegli have, in my experience, very bad blurring and compression artifacts in dark images and in dark regions of images. |
|
2023-12-29 01:10:03
|
Also cjpegli in particular tends to darken the entire image in my experience, compared to cjxl |
|
|
|
damian101
|
2023-12-29 01:18:15
|
you can increase target-intensity to improve that... |
|
|
|
Demiurge
|
2023-12-29 01:42:51
|
I used lagom.nl to make sure the contrast and gamma of my monitor are ok |
|
2023-12-29 01:43:51
|
Has anyone noticed excessive blurriness in libjxl and jpegli, or is it only me? |
|
2023-12-29 01:44:11
|
in dark regions I mean |
|
|
|
damian101
|
2023-12-29 01:44:37
|
well, how bright is your monitor? |
|
|
|
Demiurge
|
2023-12-29 01:44:58
|
Actually the brightness is turned down as low as I can. |
|
2023-12-29 01:45:01
|
But it's still pretty bright. |
|
2023-12-29 01:47:41
|
I always thought, that the whole point almost, when it comes to HDR, and HDR formats such as JPEG XR and JPEG XL, is highly detailed and textured shadows, that cause the image to really pop, almost like a 3d effect. |
|
2023-12-29 01:48:08
|
JPEG XR, a much older format, does an excellent job at preserving detailed shadows. |
|
2023-12-29 01:49:03
|
So it came as a surprise to me, to observe that JPEG XL seems to be just as terrible as regular old JPEG when it comes to sloppily blurring away and obliterating all of the detail in darker parts of the image. |
|
|
|
damian101
|
2023-12-29 01:49:12
|
yes, I can't repeat with identical commands that I used back then |
|
2023-12-29 01:49:19
|
has been fixed I guess |
|
|
|
Demiurge
|
2023-12-29 01:50:13
|
while at the same time, even in the same image, the bright, high-contrast areas are preserved extremely well, while the low-contrast dark areas look like a heavily compressed mess |
|
2023-12-29 01:50:45
|
destroying the "perceptual uniform quantization" ideal and claim |
|
2023-12-29 01:51:56
|
as well as the idea of a "perceptual-based quality setting" and "no need to test quality settings for each image" |
|
2023-12-29 01:53:09
|
It's an Achilles heel it looks like to me... or is it just the peculiarity of my monitor? Does anyone else notice this problem with dark regions? |
|
|
|
damian101
|
2023-12-29 02:16:40
|
low-contrast areas area always an issue, with JPEG XL much less than with AVIF |
|
|
|
Demiurge
|
2023-12-29 02:20:19
|
Yes, AVIF also tends to have this problem too, but not always. Sometimes, JPEG XL is even worse, at least when compared to rav1e. I should offer a demonstration with a good test image. Also, the ancient JPEG XR was known to be very good at preserving detail in dark areas. |
|
|
|
damian101
|
2023-12-29 02:22:09
|
hmm, maybe you encode at lower quality than me... |
|
|
|
Demiurge
|
2023-12-29 02:29:36
|
Well, I try to encode at -d 1 since that's what receives the most tuning. |
|
2023-12-29 02:29:57
|
And it's supposed to be the threshold of transparency. |
|
2023-12-29 02:35:35
|
wait, how interesting... The latest git version is not having a problem with it at all |
|
2023-12-29 02:35:41
|
except jpegli |
|
2023-12-29 02:36:50
|
jpegli is causing the dark parts of the image to get blacked out |
|
2023-12-29 02:37:04
|
changing the colors of the entire image |
|
2023-12-29 02:38:47
|
But only in XYB mode... |
|
2023-12-29 02:38:56
|
Weird. |
|
|
|
Traneptora
|
2023-12-29 02:39:22
|
the problem is that the video is untagged |
|
2023-12-29 02:39:37
|
if the video is properly tagged then the encoder will forward it to libjxl |
|
|
|
Demiurge
|
2023-12-29 02:41:01
|
I'm using https://en.wikipedia.org/wiki/File:Paris_Night.jpg as a test image and encoding with `cjpegli --chroma_subsampling=444 --xyb Paris_Night.jpg Paris_Night.xyb.jpg` |
|
|
|
damian101
|
2023-12-29 02:41:07
|
only if you're watching on a dull sRGB screen |
|
|
|
Demiurge
|
2023-12-29 02:42:32
|
Well, tuning the default quality settings of an HDR-focused format, with a dull sRGB screen as the intended default target, sounds like a silly proposition |
|
2023-12-29 02:43:00
|
At least at first glance |
|
|
|
damian101
|
2023-12-29 02:43:05
|
in that case it's different |
|
2023-12-29 02:43:22
|
because PQ is an absolute transfer curve |
|
2023-12-29 02:43:36
|
with brightness from 0-10'000 nits |
|
2023-12-29 02:44:14
|
but behaviour for brightness higher than 300 nits is extrapolated |
|
2023-12-29 02:44:19
|
from the testing data |
|
|
|
Traneptora
|
2023-12-29 02:44:22
|
not quite, its brightness is from 0 to intensity target |
|
2023-12-29 02:44:28
|
which is 10,000 by default if untagged |
|
|
|
Demiurge
|
2023-12-29 02:44:32
|
Well in any case I notice that the latest version of libjxl seems to do really good on this image. (Aside from a bug in xyb jpegli that changes the look of the entire image.) |
|
|
|
Traneptora
|
2023-12-29 02:44:37
|
the intensity target can be different from 10,000 tho |
|
|
|
damian101
|
2023-12-29 02:44:46
|
it should never be anything else |
|
|
|
Traneptora
|
2023-12-29 02:44:55
|
it can be tagged as something else |
|
|
|
Demiurge
|
2023-12-29 02:45:09
|
Does anyone have any other good images to use as a test? Images that contain detailed dark regions? This image on wikipedia is not very good quality |
|
|
|
Traneptora
|
2023-12-29 02:46:14
|
I use this one |
|
|
|
Quackdoc
|
2023-12-29 03:00:11
|
I was testing HLG video tho hmmm |
|
2023-12-29 03:00:54
|
also is intensity_target == 1.0 or to the brightest pixel in the image? |
|
|
|
Demiurge
|
2023-12-29 03:01:05
|
Hmm... |
|
2023-12-29 03:01:42
|
`cjxl -d 1` has significantly BETTER performance in dark regions now compared to when I tested v0.8 |
|
|
|
Traneptora
|
2023-12-29 03:01:52
|
if the video is tagged |
|
2023-12-29 03:02:05
|
it *should* work |
|
2023-12-29 03:02:15
|
what does the `ffmpeg -i input.mkv` line say? |
|
|
|
Demiurge
|
2023-12-29 03:03:51
|
However cjpegli does this when `--xyb` is used... |
|
|
|
Quackdoc
|
2023-12-29 03:05:37
|
I dont have the video on hand since it's on my linux boot, but it was a normal HLG recognized by MPV at least (well it was netflixes chimera modified to hlg but it worked fine) |
|
|
|
Traneptora
|
2023-12-29 03:06:04
|
if it doesn't map it over, it's a bug |
|
2023-12-29 03:06:11
|
HLG should be supported |
|
|
|
Quackdoc
|
2023-12-29 03:06:16
|
hmmm, I just tested another HLG video and it did work fine indeed |
|
2023-12-29 03:12:55
|
ill have to try manually specifying color_trc and color_primaries then |
|
|
|
spider-mario
|
2023-12-29 08:25:56
|
it should if the peak luminance in the image is less than 10000 |
|
2023-12-29 08:25:59
|
it won’t affect cjxl’s interpretation of PQ when reading the image |
|
|
|
damian101
|
2023-12-29 10:33:43
|
yes, but it can't be if it's SMPTE 2084 PQ |
|
|
|
spider-mario
|
2023-12-29 10:33:55
|
it definitely can |
|
2023-12-29 10:34:08
|
not every image will make use of the full 0-10000 range |
|
2023-12-29 10:34:49
|
nor should they, given that there is hardly any monitor that can emit that |
|
|
|
damian101
|
2023-12-29 10:34:50
|
doesn't matter |
|
|
|
spider-mario
|
2023-12-29 10:35:01
|
it does, given that this is what intensity_target means |
|
|
|
damian101
|
2023-12-29 10:35:45
|
no, intensity_target here refers to what brightness the peak of the transfer curve targets |
|
|
|
spider-mario
|
|
|
damian101
|
|
|
spider-mario
|
2023-12-29 10:36:02
|
it has this side effect for non-HDR transfer curves, but that’s not its purpose |
|
2023-12-29 10:36:10
|
and if the transfer curve is PQ, it won’t affect that |
|
|
|
damian101
|
2023-12-29 10:38:21
|
cjxl and jxl butteraugli interpret intensity_target always as the peak brightness of the transfer curve, including PQ
it's the same with zlib and its nominal_luminance |
|
|
|
spider-mario
|
2023-12-29 10:38:56
|
they don’t |
|
2023-12-29 10:39:02
|
```shell
$ tools/cjxl --intensity_target=4000 507.png 507.jxl
JPEG XL encoder v0.10.0 88671ac53 [AVX2,SSE4,SSE2]
Encoding [VarDCT, d1.000, effort: 7]
Compressed to 179.1 kB (1.406 bpp).
944 x 1080, 1.518 MP/s [1.52, 1.52], 1 reps, 32 threads.
$ tools/cjxl --intensity_target=10000 507.png 507.jxl
JPEG XL encoder v0.10.0 88671ac53 [AVX2,SSE4,SSE2]
Encoding [VarDCT, d1.000, effort: 7]
Compressed to 179.1 kB (1.406 bpp).
944 x 1080, 1.397 MP/s [1.40, 1.40], 1 reps, 32 threads.
``` |
|
2023-12-29 10:39:04
|
see, same size |
|
|
|
damian101
|
2023-12-29 10:39:43
|
well, that's not how it was a couple months ago |
|
|
|
spider-mario
|
2023-12-29 10:39:45
|
in your tests, are you sure the transfer curve is correctly communicated as being PQ? |
|
|
|
damian101
|
2023-12-29 10:39:59
|
definitely |
|
2023-12-29 10:40:15
|
what does jxlinfo say about the files? |
|
|
|
spider-mario
|
2023-12-29 10:40:56
|
```shell
$ tools/jxlinfo 507-4000.jxl
JPEG XL image, 944x1080, lossy, 16-bit RGB
intensity_target: 4000.000000 nits
min_nits: 0.000000
relative_to_max_display: 0
linear_below: 0.000000
Color space: RGB, D65, Rec.2100 primaries, PQ transfer function, rendering intent: Relative
$ tools/jxlinfo 507-10000.jxl
JPEG XL image, 944x1080, lossy, 16-bit RGB
intensity_target: 10000.000000 nits
min_nits: 0.000000
relative_to_max_display: 0
linear_below: 0.000000
Color space: RGB, D65, Rec.2100 primaries, PQ transfer function, rendering intent: Relative
``` |
|
|
|
damian101
|
2023-12-29 10:41:13
|
very interesting |
|
2023-12-29 10:41:45
|
so it's basically become maxCLL metadata now |
|
|
|
spider-mario
|
2023-12-29 10:41:47
|
ah, it’s possible that there was a bug in 0.8 about setting it to 10000 by default when it’s PQ |
|
2023-12-29 10:41:55
|
it’s what it was meant to be all along |
|
|
|
damian101
|
2023-12-29 10:42:40
|
unless it's used on HLG transfer function, where HLG transfer is probably adapted to intensity_targe I assume |
|
2023-12-29 10:43:17
|
sadly I can't test jxl butteraugli because libjxl-metrics-git from the AUR doesn't build for me for some reason... |
|
|
|
spider-mario
|
2023-12-29 10:43:56
|
right, for HLG, it determines the peak luminance to use for the OOTF when converting from HLG to XYB (where things will be absolute) |
|
2023-12-29 10:44:04
|
and then back to HLG when decoding |
|
2023-12-29 10:44:43
|
so, short of any bug, HLG images should roundtrip to the same signal (modulo quality) |
|
2023-12-29 10:45:14
|
(as should PQ, except intensity_target won’t have an effect on quality there) |
|
|
|
damian101
|
2023-12-29 10:45:48
|
do you know by any chance how HLG peak is supposed to be signaled in video? |
|
2023-12-29 10:46:00
|
pretty sure it's not maxCLL |
|
|
|
spider-mario
|
2023-12-29 10:46:09
|
it’s not supposed to be |
|
2023-12-29 10:46:16
|
the HLG signal itself is independent from that |
|
2023-12-29 10:46:34
|
it gets rendered to whatever peak the display is capable of |
|
|
|
damian101
|
2023-12-29 10:46:42
|
wtf |
|
2023-12-29 10:47:03
|
oh, this scene-referred nonsense mentality again 💀 |
|
|
|
spider-mario
|
2023-12-29 10:47:16
|
this is a nice video on HLG from one of its creators: https://youtu.be/XmZMyLOXB28 |
|
|
|
damian101
|
2023-12-29 10:47:36
|
I guess I'll always use 1'000 nits HLG then |
|
|
|
jonnyawsom3
|
2023-12-29 04:40:20
|
If I had to guess, I'd say it would be from Jyrki's pixel based quality metric (I can't remember the right wording but they'll know what I mean) |
|
|
|
Demiurge
|
2023-12-29 11:48:44
|
There's no such thing as a 10000 nits display afaik |
|
|
|
Quackdoc
|
2023-12-29 11:51:35
|
I think there are a couple around but nothing consumer afaik only ces stuff |
|
|
|
damian101
|
2023-12-30 12:10:38
|
I don't think so, highest I know of is 4000 nits, of which there exist a couple |
|
2023-12-30 12:11:29
|
I mean, it would be possible for dual layer LCD, but only at the cost of extreme power consumption... |
|
|
|
Quackdoc
|
2023-12-30 12:18:27
|
4000 would be something commercially for sale, there are higher ones that have been showcased but never made for purchase |
|
2023-12-30 12:18:59
|
iirc ces 2018 had a 10k nit on display? |
|
|
|
damian101
|
2023-12-30 12:19:33
|
is it an LED wall? |
|
2023-12-30 12:20:26
|
wait, I was at CES 2018 |
|
|
|
Quackdoc
|
2023-12-30 12:20:28
|
I dunno do you have any idea how long ago 2018 was now xD |
|
2023-12-30 12:20:42
|
https://www.forbes.com/sites/johnarcher/2018/01/11/why-sonys-8k-10000-nit-85-inch-tv-is-the-best-ive-ever-seen/?sh=95d57c427050 |
|
2023-12-30 12:20:43
|
ah found it |
|
|
|
damian101
|
2023-12-30 12:21:27
|
yes, 10k nits is great for headlines |
|
2023-12-30 12:21:54
|
but pretty useless outside of demo tech |
|
2023-12-30 12:23:24
|
great for indirect lighting though, if you want to have sunlight in your room around the clock |
|
2023-12-30 12:23:43
|
but there's definitely cheaper ways for that |
|
|
|
Demiurge
|
|
|
jonnyawsom3
|
2023-12-30 11:29:34
|
I considered getting a HDR display last night, thought "Oh, well OLED shouldn't be that expensive nowadays..." £1K... Maybe it can wait a while longer |
|
|
|
w
|
2023-12-30 11:34:36
|
just try it, get annoyed by dynamic brightness, and return it |
|
|
|
jonnyawsom3
|
2023-12-30 11:37:15
|
To do that I'd need to find a grand in the first place |
|
|
|
w
|
2023-12-30 11:37:24
|
credit card |
|
|
|
jonnyawsom3
|
2023-12-30 11:37:41
|
Already in debt |
|
2023-12-30 11:37:46
|
Oh the joys of England |
|
|
|
w
|
2023-12-30 11:37:54
|
get a new credit card |
|
2023-12-30 11:38:10
|
itll be fine if youre returning it anyway |
|
|
|
jonnyawsom3
|
2023-12-30 11:38:10
|
Free money glitch |
|
2023-12-30 11:39:43
|
Ironically I found out my phone is HDR the other day after 6 years of using it, it just never gets enabled unless it's a downloaded video or the Youtube app |
|
|
|
w
|
2023-12-30 11:40:48
|
i'm still hdr hater |
|
|
|
spider-mario
|
2023-12-30 12:12:57
|
I used to be a sceptic |
|
2023-12-30 12:12:58
|
```
2018-09-12 21:06:31 spider-mario boh, ça sert juste à se faire éblouir la gueule, ça, non ?
``` |
|
2023-12-30 12:13:01
|
but I have warmed up to it |
|
2023-12-30 12:13:59
|
(google translate’s rendition is not at all the intended meaning) |
|
2023-12-30 12:14:17
|
(it’s using the figurative meaning of https://en.wiktionary.org/wiki/%C3%A9blouir, but I meant it literally) |
|
|
|
Demiurge
|
2023-12-30 11:11:55
|
Why would anyone hate more detailed and less washed out images? |
|
|
|
Traneptora
|
2023-12-30 11:15:01
|
what |
|
2023-12-30 11:15:42
|
the reason w dislikes HDR is cause it often works poorly |
|
2023-12-30 11:16:09
|
SDR content on HDR screens, or HDR content on SDR screens, always is an issue |
|
2023-12-30 11:16:15
|
and will always be an issue |
|
|
|
Quackdoc
|
2023-12-30 11:17:19
|
well SDR content on HDR screens isn't *that* bad, especially in comparison to the other way around |
|
|
|
Traneptora
|
2023-12-30 11:18:06
|
well yes and no, because you need to assign an SDR blacklevel, whitelevel, and contrast ratio |
|
2023-12-30 11:18:17
|
which is entirely subjective |
|
2023-12-30 11:18:24
|
there's no correct way to do it |
|
|
|
Quackdoc
|
2023-12-30 11:20:04
|
at the very least, it's not that hard to make it (almost) universally look fine and acceptable, unlike HDR |
|
|
bonnibel
|
2023-12-30 11:32:20
|
i never enable hdr on my screen because basically everything is sdr except for some movies |
|
|
|
jonnyawsom3
|
2023-12-30 11:33:13
|
That's how I went 6 years without encountering HDR on my phone |
|
|
|
bonnibel
|
2023-12-30 11:33:18
|
so having it on 99% of the time is just an "make everything look slightly worse" button |
|
|
|
lonjil
|
2023-12-30 11:34:25
|
I wonder how KDE's upcoming always-on HDR will do in that department |
|
2023-12-30 11:34:46
|
They want SDR content to look as similar as possible to when you use SDR mode |
|
|
|
bonnibel
|
2023-12-30 11:35:35
|
hopefully better than windows's hdr mode
no matter how i tweaked it i always got grey whites or crushed blacks |
|
|
|
lonjil
|
2023-12-30 11:38:23
|
did you see this? https://zamundaaa.github.io/wayland/2023/12/18/update-on-hdr-and-colormanagement-in-plasma.html |
|
|
|
Quackdoc
|
2023-12-30 11:38:29
|
well considering they allow you to set color intensity and brightness, it should be a lot better |
|
|
|
bonnibel
|
2023-12-30 11:41:16
|
> KWin now also uses gamma 2.2 instead of the sRGB piece-wise transfer function for sRGB applications, as that more closely matches what displays actually do in SDR mode
my display has a toggle between bt1886 and 2.4.... |
|
2023-12-30 11:41:59
|
since they mentioned the steam deck i do wonder if thatll get updated to plasma 6 at some point |
|
2023-12-30 11:42:17
|
ive also yet to figure out how to get 10 bit colour out of it </3 |
|
|
|
lonjil
|
2023-12-30 11:42:49
|
mine has "Blueish" "Neutral" "Reddish" "sRGB", whatever those mean |
|
|
|
Quackdoc
|
2023-12-30 11:43:29
|
just remeber if its not calibrated dont trust it lel |
|
|
|
Traneptora
|
2023-12-30 11:43:58
|
I have two monitors, both SDR, and neither of them look the same color-wise |
|
2023-12-30 11:44:06
|
I've given up on trying to make it work |
|
2023-12-30 11:44:27
|
since the primary monitor is significantly brighter I know it has a different white point and different black point so I feel like it's probably a lost cause |
|
|
|
lonjil
|
2023-12-30 11:44:30
|
I have two monitors, and they look *reasonably* similar under Linux, but under Windows one of them is inexplicibly definitely completely wrong. |
|
|
|
Traneptora
|
2023-12-30 11:44:43
|
I just use SDR for both and they're both SDR |
|
2023-12-30 11:44:46
|
both look fine |
|
2023-12-30 11:44:56
|
the right monitor is a bit redder and darker |
|
2023-12-30 11:45:09
|
and I've given up trying to calibrate them, no point really IMO |
|
2023-12-30 11:45:15
|
both have sRGB as their monitor profiles from the manufacturer's website |
|
2023-12-30 11:45:26
|
like they're just sRGB profiles |
|
|
|
Quackdoc
|
2023-12-30 11:46:28
|
yeah if you really want to have a calibrated monitor, eyeballing can only go so far, luckly if you live in a city, you can usually pay someone 20 bucks or so to borrow a calibration tool or find someone to actually calibrate it for you |
|
|
|
Traneptora
|
2023-12-30 11:58:38
|
I lied |
|
2023-12-30 11:58:42
|
```
Tag #3 signature=“bTRC” offset=312 size=2060 type=“curv”
Tag #4 signature=“gTRC” offset=312 size=2060 type=“curv”
Tag #5 signature=“rTRC” offset=312 size=2060 type=“curv”
``` |
|
2023-12-30 11:58:44
|
woops |
|
2023-12-30 11:58:51
|
looks like they're `curv` not `para` |
|
|
|
lonjil
|
2023-12-31 12:00:37
|
the manual says that these are presets for the Red, Green, and Blue saturation sliders located under custom color options. Can't find any options or information about gamma... |
|
|
|
Traneptora
|
2023-12-31 12:00:53
|
> Illuminant: X=0.96419, Y=1.00000, Z=0.82487
lmao looks like the PCS illuminant isn't D50 |
|
2023-12-31 12:00:54
|
that's hilarious |
|
2023-12-31 12:00:58
|
wyd Acer |
|
2023-12-31 12:01:37
|
it's the same as the wtpt tag which means the PCS illuminant is probably D65 |
|
2023-12-31 12:01:41
|
not sure what htat means |
|
|
|
lonjil
|
2023-12-31 12:05:08
|
putting it into sRGB mode made all the colors brighter 🤔 |
|
|
kkourin
|
2023-12-31 12:08:18
|
I think that's D50? |
|
|
|
Traneptora
|
2023-12-31 12:08:25
|
is it? libpng warns that it isn't |
|
2023-12-31 12:08:51
|
oh yea, it is, hm |
|
2023-12-31 12:09:42
|
then the monitor itself is tagged as D50, huh. |
|
2023-12-31 12:10:27
|
I checked, this is D50 |
|
2023-12-31 12:10:28
|
> [0.9642, 1.0000, 0.8251] |
|
|
|
kkourin
|
2023-12-31 12:11:50
|
epsilon = 0.0003 🙂 |
|
2023-12-31 12:37:46
|
So your monitor whitepoint is D50? |
|
2023-12-31 12:38:26
|
I thought the factory settings are usually pretty blueis |
|
|
|
Traneptora
|
2023-12-31 12:38:30
|
the ICC profile I got from my manufacturer's website is labeled as D65 in the description but it has wtpt as D50 in the icc |
|
2023-12-31 12:38:38
|
which is odd |
|
2023-12-31 12:38:59
|
it doesn't *look* like D50 tho |
|
2023-12-31 12:39:02
|
so maybe I'm misreading it? |
|
|
|
kkourin
|
2023-12-31 12:40:04
|
Wanna send over the profile? Is this Windows color management or something else? |
|
2023-12-31 12:44:02
|
I guess if your monitor whitepoint is not really D50, but the profile says its D50, everything in a color managed setting that is doing chromatic adaptation would end up looking quite blue |
|
2023-12-31 12:49:47
|
I guess the rendering intent would affect things as well....? |
|
2023-12-31 12:55:51
|
As in, chromatic adaptation (and hence the destination profile's whitepoint tag) is only used in absolute colormetric rendering intent. Which is probably not selected in most scenarios? |
|
|
|
w
|
2023-12-31 04:42:32
|
You can get these without "HDR". High bit depth and wide color gamut. The rest of hdr is brightness and contrast which your eyes adapt to so it's entirely subjective. |
|
2023-12-31 04:44:33
|
it looks washed out because people will set the white level higher than normal, making darker "whites" look gray |
|
|
|
Quackdoc
|
2023-12-31 04:45:03
|
"HDR" transfers are significantly better for images even in the "SDR" range since you get a lot more data where it matters in comparison to something like srgb |
|
|
|
w
|
2023-12-31 04:45:55
|
yeah so just use a HDR transfer on a non HDR screen aka tonemapping and what HDR screens also do anyway, it looks exactly the same |
|
2023-12-31 04:46:01
|
(I tried) |
|
|
|
Quackdoc
|
2023-12-31 04:46:42
|
just get a good screen |
|
2023-12-31 04:46:44
|
https://cdn.discordapp.com/emojis/867794291652558888.webp?size=48&name=dogelol&quality=lossless |
|
|
|
w
|
2023-12-31 04:46:52
|
literally |
|
2023-12-31 04:54:40
|
I realized HDR is just color management and tonemapping in hardware |
|
|
|
Quackdoc
|
2023-12-31 05:02:10
|
HDR isn't even defined, the lowest common agreement for it is a transfer that can represent a lot of range |
|
2023-12-31 05:02:17
|
|
|
|
|
w
|
2023-12-31 05:09:29
|
is there even an agreement |
|
2023-12-31 05:09:51
|
with hlg and pq |
|
|
|
Quackdoc
|
2023-12-31 05:14:22
|
well both achieve the lots of range part of the equation, but the true chad is scRGB, srgb primaries that can go negative, and a linear transfer, then just brute force it with 16bits or 32bits of data |
|
|
|
Traneptora
|
2023-12-31 05:18:13
|
PQ is an absolute transfer |
|
2023-12-31 05:18:18
|
whereas HLG is display-referred |
|
2023-12-31 05:18:31
|
I don't really understand why you'd want display-referred HDR |
|
2023-12-31 05:18:46
|
it's a standard ICC profile |
|
2023-12-31 05:19:03
|
|
|
2023-12-31 05:19:11
|
it has the .icm file extension but it's an ordinary ICC profile |
|
|
|
Quackdoc
|
2023-12-31 05:24:13
|
in theory HLG should be quite flexible as to how it's displays, and should be more flexible oob for displays to handle at various brightness? |
|
2023-12-31 05:24:20
|
i forget, its been a while since i looked into it, but letting displays handle mapping is kinda dumb, srgb/gamma2.2 all over again |
|
|
starbix
|
2023-12-31 09:29:51
|
where can I find more information about the hornuss transform? I haven‘t been able to find a paper |
|
|
|
spider-mario
|
2023-12-31 09:39:09
|
you mean scene-referred (then you apply a display-dependent OOTF to get the display-referred output) |
|
2023-12-31 09:39:55
|
PQ is the display-referred one, but where said display is a theoretical 10000-nit display |
|
|
|
_wb_
|
2023-12-31 11:02:07
|
This is how it is defined, but that's not really a very intuitive description... |
|
2023-12-31 11:03:41
|
<@179701849576833024> how would you describe this transform? |
|
|
|
veluca
|
2023-12-31 11:07:42
|
Uhm |
|
2023-12-31 11:07:46
|
That's a good question |
|
2023-12-31 11:10:32
|
It tries to minimise the correlation between errors on pixels introduced by quantisation, while still storing the average of the 8x8 block |
|
|
|
starbix
|
2023-12-31 11:11:13
|
oh ok interesting, seems like it was specifically developed for jxl? |
|
|
|
veluca
|
2023-12-31 11:11:17
|
(it used to be called "identity", because it tried to behave the same as an identity, but without the DC) |
|
2023-12-31 11:11:37
|
If by developed you mean hacked together 🤣 |
|
2023-12-31 11:11:55
|
Nowadays I'd probably try to do something more principled |
|
|
|
starbix
|
2023-12-31 11:12:01
|
😂 lol i guess |
|
2023-12-31 11:13:23
|
honestly I was just curious about it because of its name |
|
|
|
veluca
|
2023-12-31 11:14:02
|
But it sort of achieves the result of being something you can use when you don't want to dct, without causing one pixel to accumulate massive error as you'd get by just storing DC and all pixels but one and recovering the missing one from that |
|
2023-12-31 11:14:20
|
The name is all <@794205442175402004> IIRC 😁 |
|
|
|
starbix
|
2023-12-31 11:15:06
|
ooh I somehow didn‘t realise people here are actually core devs |
|
|
|
_wb_
|
2023-12-31 11:16:50
|
The name was proposed by Jyrki. Originally we named it IDENTITY but we got a ballot comment complaining that this was a misleading name since it's not simply the no-op identity transform. |
|
|
|
jonnyawsom3
|
2023-12-31 11:16:54
|
JXL fanatics and founders here |
|
|
|
_wb_
|
2023-12-31 11:18:27
|
The name comes from https://en.m.wikipedia.org/wiki/Hornussen and this is a completely random and meaningless reference besides being something Swiss. |
|
|
|
w
|
2023-12-31 11:19:13
|
amazing |
|
|
|
jonnyawsom3
|
2023-12-31 11:19:38
|
Beautiful |
|
|
|
starbix
|
2023-12-31 11:20:01
|
oh yeah, it looks super dangerous with the long wiggly bat. never played it myself tho |
|
|
|
Tirr
|
2023-12-31 11:20:09
|
some-word-that-does-not-equal-to-identity |
|
|
|
w
|
2023-12-31 11:20:39
|
should have named it after me |
|
|
|
jonnyawsom3
|
2023-12-31 11:21:23
|
> 1.9.5 w
>
> w is w for the w of w x w which allows 8x8 wxw transformations |
|
|
|
_wb_
|
2023-12-31 11:21:35
|
If we could redo it, I would call it the NI transform |
|
2023-12-31 11:21:37
|
https://en.m.wikipedia.org/wiki/Knights_Who_Say_%22Ni!%22 |
|
2023-12-31 11:21:49
|
Which stands for Not Identity |
|
|
|
jonnyawsom3
|
2023-12-31 11:21:59
|
Even better |
|
2023-12-31 11:22:09
|
Maybe next version of the spec, eh? ;P |
|
|
|
_wb_
|
2023-12-31 11:22:13
|
But Hornuss works too |
|
|
|
kkourin
|
2023-12-31 11:44:09
|
The `chad` (chromatic adaptation) tag transforms D50 to D65 |
|
|
|
Traneptora
|
2023-12-31 11:48:43
|
ah, okay ty |
|
|
|
Deleted User
|
2024-01-01 10:10:36
|
<@768090355546587137> <@179701849576833024> your shit sucks |
|
2024-01-01 10:10:39
|
look at this GEG |
|
2024-01-01 10:11:28
|
also |
|
2024-01-01 10:11:31
|
there's not a reality where |
|
2024-01-01 10:11:35
|
you'll actually be |
|
2024-01-01 10:11:36
|
a real woman |
|
|
|
jonnyawsom3
|
2024-01-01 10:18:25
|
What |
|
2024-01-01 10:18:53
|
How'd you make/find that? |
|
2024-01-01 10:20:33
|
Oh okay, they left immediately |
|
2024-01-01 10:20:41
|
Interesting fellow |
|
2024-01-01 10:21:21
|
Or banned I guess |
|
|
Silikone
|
2024-01-02 12:11:16
|
>>>/g/ |
|
2024-01-02 12:14:38
|
That image came directly from a 4chan thread |
|
2024-01-02 12:14:57
|
Go figure |
|
|
|
190n
|
2024-01-02 01:36:09
|
https://tenor.com/view/packwatch-ripbozo-pitalonzo-alex-lafreniere-alex-iafreniere-gif-18890780 |
|
|
|
Silikone
|
2024-01-02 01:46:02
|
I encoded the entirety of Big Buck Bunny's source frames to lossless JXL. What's a good place to store them for free aside from shady and often banned sites like Mega? |
|
|
|
Quackdoc
|
2024-01-02 02:45:20
|
depends on how large it is, I have a couple sequences on google drive |
|
|
K
|
2024-01-02 06:42:53
|
Discord doesnt support jxl yet, any place to track that progress? The only one I found is: https://support.discord.com/hc/en-us/community/posts/1500001149681-JXL-Support |
|
|
|
jonnyawsom3
|
2024-01-02 08:54:58
|
At minimum, when chrome does |
|
|
|
Silikone
|
2024-01-02 09:04:24
|
18GB. Was 29 |
|
|
|
w
|
2024-01-02 09:16:27
|
on your own server |
|