|
Traneptora
|
2023-06-17 02:52:13
|
which doesn't seem to have any reason
|
|
2023-06-17 02:53:41
|
I inspected the markers too
|
|
2023-06-17 02:54:12
|
it appears to go `d8` `e0` `db` `c2` `sof0` then a bunch of `c4` and `da` and a `d9` at the end
|
|
2023-06-17 02:54:39
|
which looks entirely reasonable
|
|
|
_wb_
|
2023-06-17 03:56:06
|
If you compile libjxl with debug messages, you can see more stuff
|
|
2023-06-17 03:57:30
|
but yes, we could let libjxl return more descriptive error codes so cjxl/djxl can also output more useful stuff
|
|
|
|
Traneptora
|
2023-06-17 04:20:56
|
also, I suggested in #2579 that we add `--strip_alpha` to cjpegli
|
|
2023-06-17 04:21:23
|
which would default to stripping alpha channels from input if and only if they are entirely opaque
|
|
2023-06-17 04:21:53
|
and refuse and fail with error if the alpha channel isn't entirely opaque
|
|
2023-06-17 04:22:19
|
it would be very convenient for PNGs that have a superfluous alpha channel IMO
|
|
2023-06-17 04:22:40
|
could also be included in cjxl, if possible, perhaps defaulting to the above if lossy, and defaulting to retaining alpha if lossless? idk
|
|
2023-06-17 04:22:55
|
it's a thought
|
|
|
|
_wb_
|
2023-06-17 04:27:37
|
I wanted to add automatic alpha stripping to libjxl, but the issue is that alpha existing is an image-level property while alpha being trivial (entirely opaque) is a frame-level property
|
|
2023-06-17 04:28:18
|
and there's a pretty common case where the bottom layer in a layered image does have trivial alpha, but other layers do have nontrivial alpha
|
|
2023-06-17 04:29:13
|
libjxl is encoding frame by frame (layer by layer) so API-wise it's a bit tricky to do alpha stripping
|
|
2023-06-17 04:30:45
|
we could add it to cjxl but I think it's better to avoid putting the logic in cjxl because then any other libjxl-based applications are not getting it
|
|
2023-06-17 04:32:39
|
maybe if the frames are closed early enough, before the image header is actually written, the encoder could do automatic alpha stripping (with an option to keep it anyway, but there's no real use to preserving trivial alpha imo, even for lossless)
|
|
|
|
Traneptora
|
2023-06-17 04:32:55
|
well for cjpegli, it could be easier
|
|
2023-06-17 04:33:21
|
as there's no animation there
|
|
|
|
_wb_
|
2023-06-17 04:34:12
|
yeah for cjpegli it's easier.
|
|
2023-06-17 04:35:09
|
we could also make the png loader do the alpha stripping but again that will not help applications using libjxl
|
|
|
|
Traneptora
|
2023-06-17 04:42:35
|
That doesn't bother me, I care more about the PNG loading than the JXL side
|
|
|
VcSaJen
|
|
lonjil
Personally I've been trying to use "JXL" as the only name I use for the format.
|
|
2023-06-18 05:15:09
|
I've seen someone use "XL" to refer to JPEG XL.
|
|
|
elfeïn
|
2023-06-18 05:59:09
|
i like that actually
|
|
2023-06-18 05:59:19
|
susmogus.xl
|
|
|
|
_wb_
|
|
VcSaJen
I've seen someone use "XL" to refer to JPEG XL.
|
|
2023-06-18 06:23:04
|
Within JPEG sometimes that happens, talking about XL, XS, AI, Pleno etc because the prefix is the same each time 🙂
|
|
2023-06-18 06:26:22
|
Makes sense for nightly, dunno about releases...
|
|
|
|
Traneptora
|
2023-06-18 08:13:15
|
Interesting, jxl appears to be reompressing an 8-bit animation as a 32-bit float animation
|
|
2023-06-18 08:13:21
|
with distance=0
|
|
2023-06-18 08:13:27
|
I believe that's unintentional, right?
|
|
|
jonnyawsom3
|
2023-06-18 08:17:57
|
You mean from a GIF, or something else?
|
|
|
|
Traneptora
|
2023-06-18 08:18:05
|
from a JXL
|
|
2023-06-18 08:18:27
|
I have an 8-bit lossy RGBA JXL file (it's the animation_icos4d.jxl conformance sample)
|
|
2023-06-18 08:18:38
|
and if I run `cjxl -d 0 animation_icos4d.jxl test.jxl`
|
|
2023-06-18 08:18:43
|
it produces a 32-bit float JXL
|
|
2023-06-18 08:19:11
|
it also embeds an sRGB ICC profile in the new JXL file, rather than just tagging it as sRGB
|
|
2023-06-18 08:19:19
|
(the original is tagged as sRGB with enums)
|
|
2023-06-18 08:19:30
|
which is also weird but possibly unrelated
|
|
|
|
jonnyawsom3
|
2023-06-18 08:19:39
|
Ahh, guess it wasn't caught since JXLs only recently were able to be recompressed
|
|
|
|
Traneptora
|
2023-06-18 08:19:46
|
I'll open an issue
|
|
2023-06-18 08:35:17
|
https://github.com/libjxl/libjxl/issues/2581
|
|
|
monad
|
|
VcSaJen
I've seen someone use "XL" to refer to JPEG XL.
|
|
2023-06-19 06:48:11
|
Itching to share my excitement about Apple adoption, I asked my geekiest co-worker if they were interested in compression or media codecs. Not really, but interested in learning. I mentioned JPEG XL and their demonstrative response was, "I know of JPEG, and I've used Excel!"
|
|
|
|
_wb_
|
2023-06-19 07:58:38
|
https://youtu.be/UBX2QQHlQ_I
|
|
|
Jyrki Alakuijala
|
|
monad
Itching to share my excitement about Apple adoption, I asked my geekiest co-worker if they were interested in compression or media codecs. Not really, but interested in learning. I mentioned JPEG XL and their demonstrative response was, "I know of JPEG, and I've used Excel!"
|
|
2023-06-19 09:07:44
|
Excel is one better than WebP. Excel has 16384 columns and WebP has 16383.
|
|
2023-06-19 09:09:09
|
JPEG XL has 'enough' resolution it not to be a limit during its lifetime of 222 years 😛
|
|
|
TheBigBadBoy - 𝙸𝚛
|
|
monad
Itching to share my excitement about Apple adoption, I asked my geekiest co-worker if they were interested in compression or media codecs. Not really, but interested in learning. I mentioned JPEG XL and their demonstrative response was, "I know of JPEG, and I've used Excel!"
|
|
2023-06-19 09:51:42
|
That's why when I'm speaking about JPEG XL I always say "JXL" so that people don't get the wrong idea <:dogelol:867794291652558888>
|
|
|
|
Traneptora
|
2023-06-19 12:13:35
|
can we Backronym JXL to stand for Jpeg eXtended Life
|
|
|
|
Jyrki Alakuijala
|
2023-06-19 12:20:55
|
and JPEG LS for Jpeg Life Support
|
|
2023-06-19 12:22:14
|
I like recursive acronyms -- perhaps we could use JXL for JXL eXtended Life
|
|
|
w
|
2023-06-19 12:25:27
|
jpeg xtra large
|
|
|
|
jonnyawsom3
|
2023-06-19 01:01:14
|
Jpeg Xtra Light (For colors and filesize?)
|
|
|
diskorduser
|
2023-06-19 03:55:18
|
JPEG Excellent - JXL
|
|
|
|
VcSaJen
|
2023-06-19 03:57:13
|
ICC status:
IrfanView+Plugin: not supported (jpg works, jxl does not)
XnVIew MP: not supported (jpg works, jxl does not)
ImageGlass: not supported (jpg works, jxl does not) + wrong orientation
Paint.Net+Plugin: not supported (not color managed)
PaleMoon: not supported (not color managed)
Basilisk: not supported (not color managed)
WaterFox: supported only for red bench, not supported for other examples
darktable: works (except for CMYK, also not sure if orientation was supposed to be ignored)
Krita (pre-alpha): works
GIMP (development build): works
|
|
|
|
diskorduser
|
2023-06-19 04:00:13
|
nomacs, gwenview, eog?
|
|
2023-06-19 04:00:22
|
gthumb. adobe camera raw
|
|
|
|
w
|
2023-06-19 04:01:59
|
is that only image icc or both image and display icc
|
|
|
|
VcSaJen
|
2023-06-19 04:02:30
|
My display is close to sRGB, so I won't see the difference
|
|
|
|
w
|
2023-06-19 04:03:24
|
you should still be able to see a difference if you're calibrated
|
|
|
|
VcSaJen
|
2023-06-19 04:05:01
|
Supposedly IrfanView and XnView MP use display profile if color management is turned on.
|
|
|
spider-mario
|
2023-06-19 04:37:10
|
you can assign a BRG profile to your display to check that, but it's easier to check separately from image ICC, so with a normal RGB image (not BRG there too)
|
|
2023-06-19 04:37:42
|
also, I doubt it frequent that display ICC is supported but image ICC isn't
|
|
|
|
monad
|
2023-06-19 07:41:59
|
Why are we #3? We should at least be right behind AVIF.
|
|
2023-06-19 07:42:58
|
Not as poor as WebP, I guess.
|
|
|
|
_wb_
|
2023-06-19 07:43:35
|
Could be just alphabetical or something
|
|
|
|
monad
|
2023-06-19 07:44:12
|
Not quite.
|
|
|
lonjil
|
2023-06-19 08:13:39
|
what is that site?
|
|
|
|
Traneptora
|
2023-06-19 08:16:44
|
is that caniuse?
|
|
|
|
lonjil
|
2023-06-19 08:19:16
|
caniuse.com looks a bit different to me
|
|
|
|
elfeïn
|
2023-06-19 08:20:28
|
I thought AVIF was a video format?
|
|
|
|
lonjil
|
2023-06-19 08:20:38
|
that's AV1
|
|
2023-06-19 08:20:53
|
AVIF is the image format based on AV1
|
|
|
|
Traneptora
|
|
lonjil
caniuse.com looks a bit different to me
|
|
2023-06-19 08:23:03
|
that's how it looks to me, too
|
|
|
|
elfeïn
|
|
gb82
|
2023-06-19 09:20:58
|
HEIC supports animations right?
|
|
|
|
Traneptora
|
2023-06-19 10:36:59
|
I believe not
|
|
|
|
VcSaJen
|
2023-06-19 10:39:37
|
How the tables have turned...
|
|
|
|
monad
|
2023-06-20 04:28:22
|
> a bit
👀
|
|
2023-06-20 04:28:55
|
So the not great ordering is because I don't run JS.
|
|
|
|
jonnyawsom3
|
2023-06-20 12:44:34
|
Aww, cut out the middleman and improved it tenfold, so much for my first pull xD
<https://github.com/libjxl/libjxl/pull/2552>
<https://github.com/libjxl/libjxl/pull/2586>
|
|
|
|
_wb_
|
2023-06-20 01:01:56
|
oops
|
|
2023-06-20 01:01:59
|
sorry about that
|
|
2023-06-20 01:02:28
|
I just wanted to make the description of `-x color_space` a bit better and then I got carried away 🙂
|
|
|
Moritz Firsching
|
2023-06-20 01:08:38
|
do you still want to edit the documentation here <@238552565619359744> We can rebase if there are still improvements pending
|
|
|
|
jonnyawsom3
|
2023-06-20 01:16:04
|
Oddly enough wb seems to have already done most of what my pull did, *except* for the more detailed explanation of Effort, so there might still be one paragraph of use after all 😛
|
|
|
|
Moritz Firsching
|
2023-06-20 01:26:30
|
ok, I will take care of fixing the author check, changing the noreply author
|
|
|
|
jonnyawsom3
|
2023-06-20 01:28:53
|
Updated my PR to only include the Effort change, edited title too since it no longer fit
|
|
2023-06-20 01:32:04
|
Not quite as smooth as I imagined, but hey, gotta start somewhere and this is sure giving me a trial by fire of Github haha
|
|
|
|
_wb_
|
2023-06-20 02:40:56
|
heh we have a pretty strict contribution procedure, with the CLA and authors check and clang-format and then the actual CI still has to start 🙂
|
|
|
bonnibel
|
2023-06-20 03:00:06
|
how do you adjust the d parameter to obtain similar results at different pixel densities?
|
|
|
|
_wb_
|
2023-06-20 03:01:46
|
Similar results in terms of what?
|
|
|
|
bonnibel
|
2023-06-20 03:36:16
|
fidelity
|
|
2023-06-20 03:38:19
|
e.g. i'd imagine the threshold for visual losslessness is different if there's 4x the pixels packed into the same physical space?
|
|
2023-06-20 03:47:15
|
(Though I guess devices reporting higher pixel densities in media queries / srcset / etc are generally phones, where you're looking at them from a lot closer than you would at a desktop or laptop, so that does offset the difference...)
|
|
|
|
_wb_
|
2023-06-20 04:45:57
|
That's a good question, and if anyone knows an answer, I would be interested too. Obviously as pixels per inch goes up (or viewing distance goes up, or in general as pixels per visual angle goes up), you can get away with more distortion before it is noticeable. How exactly it scales though is probably not just linear.
|
|
2023-06-20 04:55:33
|
Common sense would be that LF distortions like banding in slow gradients remains visible longer as pixels per angle goes up, while HF distortions like short-distance ringing become invisible as pixels per angle goes up
|
|
|
|
Jyrki Alakuijala
|
|
bonnibel
(Though I guess devices reporting higher pixel densities in media queries / srcset / etc are generally phones, where you're looking at them from a lot closer than you would at a desktop or laptop, so that does offset the difference...)
|
|
2023-06-20 06:27:08
|
I believe that all devices are starting to have 'sufficient' pixel counts and image resolution is starting to disconnect from device resolution
|
|
|
|
gb82
|
2023-06-20 06:37:45
|
The lowest PPI you'll find now is a 24" 1080p monitor, maybe sometimes 27"
|
|
|
|
Jyrki Alakuijala
|
2023-06-20 06:47:18
|
it is possible to find 1080p, but utility is quite a bit higher on the $250 priced 4k monitors -- it would be difficult for me to understand why someone would buy a 1080p monitor nowadays
|
|
|
|
gb82
|
|
Jyrki Alakuijala
it is possible to find 1080p, but utility is quite a bit higher on the $250 priced 4k monitors -- it would be difficult for me to understand why someone would buy a 1080p monitor nowadays
|
|
2023-06-20 06:52:54
|
High refresh rate gaming
|
|
2023-06-20 06:54:31
|
Considering the incredibly low price points of high refresh rate IPS 1080p monitors at 24" & the proclivity many gamers have toward games like Valorant, CSGO, etc combined with the fact that their games will run better at 1080p, it makes a lot of sense. You can get a really nice 1080. 144hz IPS monitor for $120 USD if you're lucky
|
|
|
|
_wb_
|
2023-06-20 07:14:14
|
I always wonder if you really need a display that has a high refresh rate. I can see how having more game engine ticks per second is beneficial, as well as low ghosting, but that's in principle not related to the display fps.
|
|
|
|
lonjil
|
2023-06-20 07:19:44
|
1366x768 15.6" laptops are still commonly sold
|
|
|
|
elfeïn
|
2023-06-20 07:22:06
|
768 seems like such a weird number but it's just 0x300.
|
|
|
|
_wb_
|
2023-06-20 07:23:37
|
Yeah, it's from back in the days when 4:3 aspect ratio was standard and 1024 columns is a nice round number
|
|
|
fab
|
2023-06-20 08:11:18
|
But for reading do you actually prefer 144hz ?
|
|
2023-06-20 08:11:30
|
Because I don't game
|
|
2023-06-20 08:12:07
|
I have mental problems and I wonder if reading at 144hz is good
|
|
2023-06-20 08:12:15
|
Or like any rate
|
|
2023-06-20 08:12:32
|
On intern there isn't such information
|
|
2023-06-20 08:13:02
|
Do people buy a high refresh rate display for reading?
|
|
2023-06-20 08:13:10
|
In a laptop
|
|
|
yoochan
|
2023-06-20 08:13:17
|
e-ink for reading is nicer
|
|
|
|
fab
|
2023-06-20 08:13:33
|
For example I saw hp Victus
|
|
2023-06-20 08:13:59
|
Is there any advantage on it beside my xiaomi mi 11 lite 5G
|
|
2023-06-20 08:14:33
|
|
|
2023-06-20 08:14:44
|
I'm using slightly condensed font
|
|
2023-06-20 08:14:55
|
This good for dark
|
|
2023-06-20 08:15:22
|
But not the max I know for readability
|
|
2023-06-20 08:15:49
|
On desktop I downloaded GalmuriMono9
|
|
2023-06-20 08:15:58
|
The Wikipedia it reads fast
|
|
2023-06-20 08:16:08
|
And i have 60fps display
|
|
2023-06-20 08:16:31
|
But the letter t is horrible andtoo condensed
|
|
2023-06-20 08:16:47
|
In this font on mobile the r bothers me
|
|
2023-06-20 08:17:46
|
In most font except Orbit by Google fonts in the grotesk type of design the m it bothers me
|
|
2023-06-20 08:20:31
|
Victor Mono normal ttf is nice of the form
|
|
|
|
spider-mario
|
|
_wb_
I always wonder if you really need a display that has a high refresh rate. I can see how having more game engine ticks per second is beneficial, as well as low ghosting, but that's in principle not related to the display fps.
|
|
2023-06-20 08:20:45
|
I find that 60 fps vs. 120 fps makes a noticeable and appreciable difference
|
|
|
|
fab
|
2023-06-20 08:20:46
|
Not too big not huge
|
|
|
|
spider-mario
|
2023-06-20 08:20:51
|
120 vs. 144, though, not so sure
|
|
|
|
fab
|
2023-06-20 08:20:59
|
But probably is for 13pt
|
|
2023-06-20 08:21:06
|
I don't use 13pt
|
|
2023-06-20 08:21:12
|
I'm young 23
|
|
|
|
spider-mario
|
2023-06-20 08:21:28
|
when I had a 144 fps screen, I ran it at 120 (so that it would be a multiple of 30 and 60)
|
|
|
|
fab
|
2023-06-20 08:21:33
|
But at least ia Open source
|
|
|
|
lonjil
|
2023-06-20 08:25:11
|
going from 30fps to 40fps reduces the time per frame by ~8.33 ms. From 40 to 60, by ~8.33 ms. From 60 to 120, ~8.33ms. From 120 to 144, ~1.39 ms.
|
|
|
|
jonnyawsom3
|
|
Jyrki Alakuijala
it is possible to find 1080p, but utility is quite a bit higher on the $250 priced 4k monitors -- it would be difficult for me to understand why someone would buy a 1080p monitor nowadays
|
|
2023-06-20 09:40:28
|
Budget buyers or those tight on money immediately adds a large area, especially lately just $10 can make a difference, yet alone $150 from 1080 to 4K
|
|
2023-06-20 09:41:56
|
Not to mention secondary monitors and such
|
|
|
Fraetor
|
2023-06-20 09:55:54
|
When I recently looked at monitors it was pick two of:
- High resolution (Greater than 1080)
- High refresh rate (Greater than 75Hz)
- Accurate colours (Some form of VESA DisplayHDR)
If you wanted all three you were looking at a very expensive display.
|
|
|
|
spider-mario
|
2023-06-20 10:53:11
|
I got the M1 MacBook Pro pretty much for its display
|
|
2023-06-20 10:53:14
|
it’s excellent
|
|
2023-06-20 10:54:07
|
my desktop monitor is a typical 32" 4K IPS 60fps monitor covering P3, does the job but nothing to write home about
|
|
2023-06-20 10:54:41
|
it theoretically has an HDR mode but it’s pretty much useless
|
|
2023-06-20 10:56:39
|
if only because it applies disgusting sharpening in that mode
|
|
2023-06-20 10:57:37
|
(and ~300-400 cd/m² peak brightness and no local dimming of any kind)
|
|
|
|
gb82
|
2023-06-21 12:57:52
|
I'm switching to an M2 macbook air pretty soon, I'm excited to experience a color accurate true 10 bit LCD
|
|
2023-06-21 12:58:54
|
my current display is a 144hz 1080p 24" IPS. I think it gets the job done, I got it because it was cheap & I appreciate high refresh rate more than high resolution for what I do right now (a lot of text based stuff)
|
|
|
|
diskorduser
|
2023-06-21 12:59:48
|
Isn't it better to get a high dpi display for text based stuff?
|
|
|
|
gb82
|
2023-06-21 01:00:20
|
is it? I used to have a 4k 13" laptop & I didn't find it made text any more or less readable for writing anything (code, essays, etc)
|
|
2023-06-21 01:00:45
|
the text certainly looked better but my ability to read it did not change
|
|
|
fab
But for reading do you actually prefer 144hz ?
|
|
2023-06-21 01:01:07
|
i don't think it matters for reading
|
|
|
|
diskorduser
|
2023-06-21 01:01:29
|
But fonts look nice and sharp on high dpi displays
|
|
|
yurume
|
|
_wb_
I always wonder if you really need a display that has a high refresh rate. I can see how having more game engine ticks per second is beneficial, as well as low ghosting, but that's in principle not related to the display fps.
|
|
2023-06-21 01:08:44
|
it does matter for music video games, but I do agree that most gamers don't need far more than 60 Hz
|
|
2023-06-21 01:09:13
|
my own monitor supports 100 Hz but I always set it to 60 Hz because it's not worth
|
|
2023-06-21 01:09:26
|
(120 Hz would have been beneficial though)
|
|
|
|
gb82
|
|
_wb_
I always wonder if you really need a display that has a high refresh rate. I can see how having more game engine ticks per second is beneficial, as well as low ghosting, but that's in principle not related to the display fps.
|
|
2023-06-21 01:12:11
|
the perceived smoothness is noticeable. Spending an extra $100 on a monitor (at 1080p, hrr monitors are price competitive with 60hz monitors anyway, just making this point for the sake of the argument) is not that much of an expense when gamers spend infinitely more on the rest of their systems tailored specifically toward playing video games
|
|
|
|
yurume
|
2023-06-21 01:18:02
|
I think that perceived smoothness is more about postprocessing (e.g. temporal motion blurring) and less about refresh rates unless you are *really* sensitive to them
|
|
2023-06-21 01:19:40
|
i.e. most games can mask lower refresh rates with a bunch of postprocessing, so if you don't do postprocessing you indeed see benefits from higher refresh rates, but it's not the case for most (high-profile) games anyway
|
|
2023-06-21 01:20:34
|
it's like Apple's high-dpi (retina) devices---if you have subpixel rendering high-dpi displays are less significant. but if you have a guaranteed high-dpi device, you can avoid subpixel rendering at all
|
|
|
|
gb82
|
|
yurume
I think that perceived smoothness is more about postprocessing (e.g. temporal motion blurring) and less about refresh rates unless you are *really* sensitive to them
|
|
2023-06-21 01:20:51
|
you will *absolutely* notice 120hz in my experience. even just moving the mouse. Most gamers detest motion blur
|
|
|
|
yurume
|
2023-06-21 01:21:28
|
it greatly depends. I think FPS is probably one of genres where 120 Hz is beneficial
|
|
2023-06-21 01:21:43
|
and temporal motion blurring doesn't mean the uniform sampling (which *is* horrible, I agree)
|
|
|
|
gb82
|
2023-06-21 01:21:50
|
Obviously there are genres where you aren't going to notice >30fps
|
|
|
|
yurume
|
2023-06-21 01:23:10
|
anyway, the main reason you want higher refresh rates is that, you need to detect a minute change in object positions
|
|
2023-06-21 01:23:22
|
most games are not that strict
|
|
2023-06-21 01:24:16
|
in FPS aim accuracy is highly important and 120 Hz would indeed matter, but I'm not sure if the corresponding netcode is equally optimized (it's very hard, for various reasons including physical limitations)
|
|
2023-06-21 01:24:58
|
in music video games you may need sub-10ms latency to synchronize your input
|
|
2023-06-21 01:25:56
|
but it doesn't mean that you can indeed detect an interval smaller than 10ms, it means that you can avoid *drifting* your sense of rhythm more effectively
|
|
2023-06-21 01:26:19
|
as higher refresh rates make that drift more obvious
|
|
2023-06-21 01:26:48
|
besides from that, higher refresh rates are (while good to have) too highly rated
|
|
2023-06-21 01:27:30
|
maybe VR needs a highest available refresh rate (up to 240 Hz), but I doubt monitors need more than 120 Hz
|
|
|
|
gb82
|
|
yurume
anyway, the main reason you want higher refresh rates is that, you need to detect a minute change in object positions
|
|
2023-06-21 01:46:34
|
No, the main reason you want high refresh rates is that it feels nice. Games are supposed to be fun, and I hear that the increased smoothness that is decidedly different than the effect motion blur provides is attractive and adds a wow factor to games
|
|
|
|
yurume
|
2023-06-21 01:47:00
|
I mean, yeah, if games do not compensate for lower refresh rates
|
|
2023-06-21 01:47:21
|
but most games *do* compensate for that, and I believe we should talk under that assumption
|
|
|
|
gb82
|
2023-06-21 01:47:35
|
Coming from someone who doesn't play video games & doesn't care for them, the reasons I bought a HRR monitor:
- it feels noticeably more responsive to use doing literally anything at all, even just desktop stuff
- it was the same price as 60hz options for no downsides
|
|
|
|
yurume
|
2023-06-21 01:47:54
|
ah that's a good argument (to say about non-games)
|
|
2023-06-21 01:48:32
|
I'll indeed grab 120 Hz if I can, the only reason I didn't was I also needed a ultra widescreen monitor and 120 Hz is absurdly expensive in that range
|
|
|
|
gb82
|
|
yurume
I mean, yeah, if games do not compensate for lower refresh rates
|
|
2023-06-21 01:48:33
|
I don't think this fixes everything. I still think more temporal resolution is worth it for many. This is akin to saying "we don't need high resolutions if games compensate for them with powerful anti aliasing that negates the downsides of lower resolutions"
|
|
|
|
yurume
|
2023-06-21 01:49:02
|
(my monitor is 35in and has a native resolution of 3440 x 1440)
|
|
|
gb82
I don't think this fixes everything. I still think more temporal resolution is worth it for many. This is akin to saying "we don't need high resolutions if games compensate for them with powerful anti aliasing that negates the downsides of lower resolutions"
|
|
2023-06-21 01:49:47
|
do you think future monitors should support 240 Hz then? or is 120 Hz just enough?
|
|
2023-06-21 01:50:08
|
because you can't blindly increase temporal resolution
|
|
|
|
gb82
|
|
yurume
do you think future monitors should support 240 Hz then? or is 120 Hz just enough?
|
|
2023-06-21 01:50:32
|
As a non-gamer, I think monitors should standardize around what they see market demand for relative to how much it costs to satiate that demand
|
|
|
|
yurume
|
2023-06-21 01:50:46
|
this is a good argument for 120 Hz, which is an integral multiple of 24
|
|
|
|
gb82
|
2023-06-21 01:51:05
|
I agree that native 24fps would be super cool. Like yurume said though, 120hz does technically solve this
|
|
|
|
yurume
|
2023-06-21 01:52:48
|
an additional possible semi-argument is that many (most?) games synchronize input rates with refresh rates
|
|
2023-06-21 01:53:17
|
so if games are not super careful, they will only poll 60 times for 60 Hz monitors and 120 times for 120 Hz monitors
|
|
2023-06-21 01:53:31
|
that's really painful for some kind of games including music video games
|
|
2023-06-21 01:54:02
|
(commercial game engines are not helpful in that aspect either, you need some deep knowledge to separate them)
|
|
2023-06-21 01:54:23
|
but it's only a semi-argument, because it's not exactly about monitors
|
|
2023-06-21 01:56:29
|
yeah if you don't need a really big monitor 120 Hz seems now within a reach
|
|
2023-06-21 01:57:08
|
please note that you also need a powerful enough GPU, 120 Hz means twice bandwidth compared to 60 Hz
|
|
2023-06-21 01:57:25
|
(my old GTX 1050 could only cope with up to 85 Hz)
|
|
|
|
gb82
|
|
yurume
so if games are not super careful, they will only poll 60 times for 60 Hz monitors and 120 times for 120 Hz monitors
|
|
2023-06-21 02:02:01
|
<:PepeHands:808829977608323112>
|
|
2023-06-21 02:02:20
|
definitely
|
|
2023-06-21 02:02:36
|
My 4770k iGPU drove 144hz 1080p just fine
|
|
|
|
yurume
|
|
gb82
<:PepeHands:808829977608323112>
|
|
2023-06-21 02:12:52
|
I mean, I can't really blame game developers for that, it's so widespread problem that even arcade music video games are known to misbehave when you replace monitors (with a slightly different refresh rate), recent games typically detect the true refresh rate during the startup to avoid this issue.
|
|
|
|
Traneptora
|
2023-06-21 02:31:57
|
one nice advantage of 120 Hz monitors is that 120 is a multiple of 24
|
|
2023-06-21 02:32:04
|
so you can play 24fps content without any judder
|
|
2023-06-21 02:32:14
|
which is a bit awkward on 60 Hz
|
|
|
Quackdoc
|
2023-06-21 02:33:58
|
freesync helps a lot with that
|
|
|
|
w
|
2023-06-21 02:40:31
|
hrr is good for scrolling web pages and moving my mouse around
|
|
|
|
gb82
|
|
w
hrr is good for scrolling web pages and moving my mouse around
|
|
2023-06-21 02:47:11
|
real exactly
|
|
|
|
VcSaJen
|
|
_wb_
I always wonder if you really need a display that has a high refresh rate. I can see how having more game engine ticks per second is beneficial, as well as low ghosting, but that's in principle not related to the display fps.
|
|
2023-06-21 03:34:34
|
I don't understand why anyone would use 60Hz monitor. This was a great downgrade when transitioning from CRT to LCD. 60Hz sucked then, it still sucks now.
|
|
2023-06-21 03:35:28
|
Not to mention that scaling still sucks both on Windows and Linux. It's a blurry mess, even on OS apps.
|
|
|
Fraetor
When I recently looked at monitors it was pick two of:
- High resolution (Greater than 1080)
- High refresh rate (Greater than 75Hz)
- Accurate colours (Some form of VESA DisplayHDR)
If you wanted all three you were looking at a very expensive display.
|
|
2023-06-21 03:41:39
|
Super-wide gamut sucked on Windows until very recently. This year Win11 have Auto Color Management/Advanced Color, so people can finally start using them without being blasted with oversaturation.
|
|
|
|
gb82
|
2023-06-21 03:41:53
|
macOS color management still reigns supreme
|
|
|
BlueSwordM
|
|
gb82
I'm switching to an M2 macbook air pretty soon, I'm excited to experience a color accurate true 10 bit LCD
|
|
2023-06-21 04:11:39
|
Oh, you will be dissapointed 😔
|
|
2023-06-21 04:11:57
|
What you want is a high refresh rate high density high contrast screen 🙂
|
|
|
|
gb82
|
2023-06-21 04:12:14
|
I've seen the Mac screens, they look pretty darn good
|
|
2023-06-21 04:12:27
|
although ik the miniled displays on the Pro lineup are much better
|
|
|
|
BlueSwordM
|
|
gb82
I've seen the Mac screens, they look pretty darn good
|
|
2023-06-21 04:13:19
|
That's until you look at motion resolution 🤮
|
|
2023-06-21 04:13:37
|
Macbook M1 displays and later have abysmal response times.
|
|
|
|
gb82
|
2023-06-21 04:13:56
|
i know but I don't personally care for what I'll be doing
|
|
2023-06-21 04:14:09
|
& again, the Pro lineup has the good stuff anyhow
|
|
|
|
BlueSwordM
|
|
gb82
& again, the Pro lineup has the good stuff anyhow
|
|
2023-06-21 04:14:57
|
Even worse <:KekDog:805390049033191445>
That's where the poor screen response times were found 😂
|
|
|
|
gb82
|
2023-06-21 04:15:07
|
oh really? darn
|
|
2023-06-21 04:15:37
|
well I mean if you want a display with good response times, you're probably a gamer who isn't considering a Mac anyhow
|
|
|
|
BlueSwordM
|
|
gb82
well I mean if you want a display with good response times, you're probably a gamer who isn't considering a Mac anyhow
|
|
2023-06-21 04:16:13
|
The issue lies in the fact that you'll notice the poor motion performance while using the display...
|
|
2023-06-21 04:16:21
|
Oof, pinged you again 😔
|
|
|
|
gb82
|
|
BlueSwordM
Oof, pinged you again 😔
|
|
2023-06-21 04:16:29
|
its okay
|
|
|
BlueSwordM
The issue lies in the fact that you'll notice the poor motion performance while using the display...
|
|
2023-06-21 04:17:22
|
doing what, scrolling web pages? I acknowledge better response times & refresh rate matter in this use case but they aren't the most important factors for a laptop display for me personally. on my desktop where motion clarity is more apparent due to the larger panel I care a lot more
|
|
2023-06-21 04:17:29
|
also <#806898911091753051> mayhaps? lol
|
|
|
|
w
|
2023-06-21 04:28:58
|
if you want color accurate just buy a colorimeter
|
|
2023-06-21 04:29:10
|
it's gonna be not accurate after a few months anyway
|
|
|
|
diskorduser
|
|
w
it's gonna be not accurate after a few months anyway
|
|
2023-06-21 04:29:43
|
Even on high end monitors?
|
|
|
|
Quackdoc
|
2023-06-21 04:33:24
|
im pretty excited for wayland to have a fully color managed display pipeline, now we just need to wait another decade or two for it to come to fruition xD
|
|
|
|
w
|
|
diskorduser
Even on high end monitors?
|
|
2023-06-21 04:36:09
|
there's high end monitors and there's very high end monitors that are bundled with a colorimeter and there's very very high end monitors that have a built in colorimeter
|
|
|
|
gb82
|
|
Quackdoc
im pretty excited for wayland to have a fully color managed display pipeline, now we just need to wait another decade or two for it to come to fruition xD
|
|
2023-06-21 04:58:13
|
<:PepeSad:815718285877444619>
|
|
|
|
diskorduser
|
|
w
there's high end monitors and there's very high end monitors that are bundled with a colorimeter and there's very very high end monitors that have a built in colorimeter
|
|
2023-06-21 05:01:25
|
I see. Once I asked a photographer who owned a 5000$-7000$ monitor how often you calibrate. He said he does once a year because colors don't change often.
|
|
|
|
bonnibel
|
|
lonjil
going from 30fps to 40fps reduces the time per frame by ~8.33 ms. From 40 to 60, by ~8.33 ms. From 60 to 120, ~8.33ms. From 120 to 144, ~1.39 ms.
|
|
2023-06-21 07:34:21
|
when it comes to video instead of video games, i wonder if one can notice the difference between watching 30 or 60 fps video on a 120 Hz (simply repeat every frame 2 or 4 times) display vs a 144 Hz (not a multiple of 30 & 60 so the frame timings will be slightly off) display
|
|
|
|
Quackdoc
|
2023-06-21 08:19:55
|
it could lead to frame tearing or judder, but the vast majority of 120hz+ monitors have some kind of VRR so it's not really an issue, well unless you aren't in VRR range, but thankfully players like makes it easy to bring up CFR videos into VRR range trivially.
|
|
2023-06-21 08:20:15
|
vfr videos are a different story,
|
|
|
|
fab
|
2023-06-21 10:04:25
|
90 fps with
|
|
2023-06-21 10:04:51
|
51 79
|
|
2023-06-21 10:05:19
|
Nothing changes on Xiaomi mi lite 5g
|
|
2023-06-21 10:05:46
|
The animation are faster on Android 13 60 fps
|
|
2023-06-21 10:08:29
|
|
|
2023-06-21 10:08:55
|
Only this looks faster on 90hz
|
|
2023-06-21 10:10:59
|
|
|
2023-06-21 10:11:04
|
|
|
2023-06-21 10:11:44
|
I have to try galmuri 2.38.1
|
|
2023-06-21 10:12:04
|
But those fonts are already sufficient for 90hz
|
|
2023-06-21 10:15:54
|
Esme simple v2 has good comprenhsion of text at 110hz
|
|
2023-06-21 10:16:36
|
RimZim you can read at 143hz
|
|
2023-06-21 10:16:57
|
Is there anything more readable
|
|
2023-06-21 10:17:09
|
Who needs it
|
|
2023-06-21 10:24:23
|
|
|
2023-06-21 10:24:51
|
If you want the font for your computer here it Is
|
|
2023-06-21 10:25:10
|
I estracted thw mtz found on an esternal site
|
|
2023-06-21 10:25:22
|
With RAR mobile trial Application
|
|
2023-06-21 10:29:04
|
If someone can make a stylus extension with this font, I'd be grateful
|
|
2023-06-21 10:30:56
|
|
|
2023-06-21 10:31:08
|
This font I find also good
|
|
2023-06-21 11:34:03
|
Esme 59 41
|
|
2023-06-21 11:34:20
|
81 62 the font on wired
|
|
2023-06-21 11:34:51
|
Maia 41 73
|
|
2023-06-21 11:37:00
|
Louis 51 72
|
|
2023-06-21 11:38:02
|
I'm reporting the speed I can read
|
|
|
Oleksii Matiash
|
2023-06-21 11:38:16
|
Guys, could you please move to <#806898911091753051>?
|
|
|
|
fab
|
|
Oleksii Matiash
Guys, could you please move to <#806898911091753051>?
|
|
2023-06-21 11:38:26
|
Yes
|
|
|
|
w
|
2023-06-21 12:06:28
|
> Guys
|
|
|
|
fab
|
2023-06-21 12:10:19
|
I'm a guy
|
|
|
|
Oleksii Matiash
|
|
w
> Guys
|
|
2023-06-21 12:11:34
|
I'm sorry, English is by far not my native language, what is more appropriate word?
|
|
|
|
w
|
2023-06-21 12:11:46
|
i meant that it was just 1 guy
|
|
|
|
VcSaJen
|
2023-06-21 12:16:11
|
Using "guys" would be still appropriate, at least in my language.
|
|
|
|
w
|
|
|
VcSaJen
|
2023-06-21 12:42:05
|
It's a polite (in passive agressive way) way to refer to concrete person, without explicitly saying that's it's a concrete person.
|
|
|
|
w
|
2023-06-21 12:42:24
|
my problem was with the context
|
|
2023-06-21 12:43:14
|
do they mean to every person in the greater conversation, of which started yesterday? or the more recent
|
|
2023-06-21 12:44:20
|
the more recent blurb from the fab
|
|
2023-06-21 12:44:23
|
to be considered off-topic
|
|
|
|
jonnyawsom3
|
2023-06-21 12:46:32
|
Or... All of it?
|
|
2023-06-21 02:19:09
|
5 conversations, 3 reviews and half a dozen commits for a paragraph of text... I sure know how to make things complicated
|
|
2023-06-21 02:23:06
|
Ehh, it's my first one and each does have a distinct purpose and had a conversation requesting it, I'm just a bit amazed how often I was one word off, missing some spaces or such each time. At least it should be done now, and I know how to do it *slightly* more gracefully in future
|
|
2023-06-21 02:25:43
|
As a sidenote, I'd maybe move the Authors and Format checks to run along with the CLI, would've saved some time approving just to realise I need to add a new line
|
|
|
|
Moritz Firsching
|
2023-06-21 02:42:48
|
no worries, we squoos the commits anyhow
|
|
2023-06-21 02:44:22
|
yeah, perhaps we could at some point allow the formatting and author check wihtout approval I suppose... so far we have seen very little vandalism
|
|
2023-06-21 02:47:16
|
If we approved to run the CI once, then it should be fine to run automatically from then on, even in the same commit, I suppose
|
|
2023-06-21 02:47:37
|
Right now that is not happening, but it will be automatic after your first commit
|
|
|
|
jonnyawsom3
|
2023-06-21 02:49:42
|
Yeah, that sounds perfect
|
|
|
|
fab
|
2023-06-21 02:51:51
|
Noto Sans Sundanese miss characters please don't use ir
|
|
2023-06-21 02:52:23
|
Also Esme is better because Promotean has double interline
|
|
2023-06-21 02:52:49
|
So if is literally impossible to read Giuseppe Conte postsq
|
|
2023-06-21 03:20:59
|
https://github.com/tirr-c/jxl-oxide/actions/runs/5320223296
|
|
|
|
diskorduser
|
2023-06-21 04:15:43
|
Why is the windows binary is soooo smol and the linux one is fatter.
|
|
|
Tirr
|
2023-06-21 04:17:52
|
maybe runtime is dynamically linked for windows builds
|
|
2023-06-21 04:18:22
|
I guess it's the default behavior of MSVC linker
|
|
2023-06-21 04:19:03
|
ah or it's because of the debug information
|
|
2023-06-21 04:20:34
|
iirc MSVC linker drops separate file for debuginfo
|
|
|
|
diskorduser
|
2023-06-21 04:21:42
|
`❯ du /home/xxx/.cargo/bin/jxl-dec
5.5M /home/xxx/.cargo/bin/jxl-dec`
|
|
|
|
Tirr
|
2023-06-21 04:24:47
|
it seems like cargo install doesn't use profile configuration in Cargo.toml
|
|
2023-06-21 04:27:23
|
if you use cargo build in repository, the binary will contain debuginfo
|
|
|
|
Traneptora
|
2023-06-21 05:46:43
|
Where did the DCT_Params table come from?
|
|
2023-06-21 05:46:59
|
the spec lists a bunch of floating point numbers. How were they derived? asking because of fixed point decoder questions
|
|
|
|
lonjil
|
2023-06-22 03:56:43
|
does anyone have a recent copy of the spec? edit: nvm saw it in <#1021189485960114198>
|
|
|
|
gb82
|
2023-06-22 06:09:40
|
Trying to build libjxl from source on an M series Mac
|
|
2023-06-22 06:09:55
|
keeps getting `make: *** [all] Error 2` at around 62%
|
|
2023-06-22 06:11:10
|
doing:
```git clone https://github.com/libjxl/libjxl && cd libjxl && chmod +x deps.sh && ./deps.sh
mkdir build && cd build
cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_FLAGS="-O3 -march=native" -DCMAKE_C_FLAGS="-O3 -march=native" .. && cmake --build . -- -j$(nproc)```
|
|
2023-06-22 06:12:46
|
https://github.com/libjxl/libjxl/issues/2359
|
|
2023-06-22 06:13:25
|
i think it is similar to this. My error is in this .txt
|
|
|
|
Traneptora
|
|
gb82
i think it is similar to this. My error is in this .txt
|
|
2023-06-23 01:35:31
|
looks like it's using the headers installed `/opt/homebrew` rather than the ones packaged with it
|
|
|
|
gb82
|
2023-06-23 01:53:47
|
anything I can do about that?
|
|
|
|
Traneptora
|
2023-06-23 03:07:08
|
I'm not sure. I'm not a macOS user
|
|
|
|
fab
|
2023-06-26 08:12:14
|
Gi-iX-El
|
|
2023-06-26 08:12:34
|
People meme about the Italian pronunciation of jxl
|
|
2023-06-26 08:14:55
|
|
|
2023-06-26 08:15:17
|
I didn't write this shit
|
|
2023-06-26 08:15:40
|
But not only me memes about this
|
|
2023-06-26 08:16:05
|
I think jxl is efficient as vvc faster
|
|
2023-06-26 08:16:33
|
At crf 20.5
|
|
2023-06-26 08:17:20
|
But the problem when you go to normal distance it getnt the detail from lower distance
|
|
2023-06-26 08:17:33
|
For example d0.641s9 d0.539s8
|
|
2023-06-26 08:17:58
|
The image is encoded fast
|
|
2023-06-26 08:18:22
|
https://www.litaliaindigitale.it/news-nazionali/news-anno-2023/2023-06-news-giugno-2023/230614-rai-mux-b-inseriti-rai-sport-hd-in-h-265-hevc-e-rai-play-in-hbbtv-eliminato-rai-3-hd-provvisorio/
|
|
2023-06-26 08:18:53
|
Jxl also considers the re encoding of hevc
|
|
2023-06-26 08:19:26
|
But on normal Xiaomi images
|
|
2023-06-26 08:19:55
|
81 kb images has great denoising
|
|
|
derberg
|
|
fab
|
|
2023-06-26 12:04:24
|
The first comment in the screenshot is hilarious.
"18 months ago when libjxl barely compiled"
It literally compiled after using that command to pull in the submodules and installing dependencies 🤔
I used it on a Raspberry Pi, a postmarketOS running phone and my Arch Linux installation. In early-mid 2021.
|
|
2023-06-26 12:07:56
|
Two architectures, three distros.
|
|
2023-06-26 12:10:54
|
Somehow I have the feeling the person did not try to use good parameters.
Especially considering they don't mention them.
|
|
|
|
fab
|
|
derberg
The first comment in the screenshot is hilarious.
"18 months ago when libjxl barely compiled"
It literally compiled after using that command to pull in the submodules and installing dependencies 🤔
I used it on a Raspberry Pi, a postmarketOS running phone and my Arch Linux installation. In early-mid 2021.
|
|
2023-06-26 12:11:41
|
I don't agree with the first comment
|
|
|
|
derberg
|
2023-06-26 12:13:22
|
Yeah, I did not think that.
|
|
2023-06-27 12:57:51
|
Suuuure
|
|
|
|
elfeïn
|
2023-06-27 12:59:02
|
that's so sad
|
|
|
|
derberg
|
2023-06-27 12:59:20
|
Ah, sorry wrong chat
|
|
|
derberg
Ah, sorry wrong chat
|
|
2023-06-27 01:00:18
|
Wanted to put it into <#803574970180829194> but ctrl + k put me here instead of there
|
|
|
OkyDooky
|
2023-06-27 10:33:49
|
Is there a way to ... ‘requality’ a `*.jxl` file? I'm using `cjxl` to store losses files, but for the web, I’d like to reduce the quality to save size. The thing that’s coming to mind is using `djxl` to `*.png` then re compressing with the new quality setting, but that seems pretty stupid and `cjxl` docs say `*.jxl` isn’t a support input type.
|
|
|
username
|
|
Is there a way to ... ‘requality’ a `*.jxl` file? I'm using `cjxl` to store losses files, but for the web, I’d like to reduce the quality to save size. The thing that’s coming to mind is using `djxl` to `*.png` then re compressing with the new quality setting, but that seems pretty stupid and `cjxl` docs say `*.jxl` isn’t a support input type.
|
|
2023-06-27 10:37:19
|
I think after this pull request you should be able to use JXL files as input in cjxl: https://github.com/libjxl/libjxl/pull/2444
|
|
|
|
OkyDooky
|
2023-06-27 10:49:40
|
Ah, I’m on the older version and it’s not yet landed into nixpkgs-unstable (despite being merged at least a week ago) https://nixpk.gs/pr-tracker.html?pr=237913
(<@245794734788837387>)
|
|
|
|
jonnyawsom3
|
2023-06-27 10:53:56
|
If I recall we're not releasing new versions now until it's at 1.0, so you'd need to get it from Github Actions or build it yourself for now
|
|
|
|
OkyDooky
|
2023-06-27 10:54:03
|
I‘ll try an overlay to see if the latest version helps 🙏
|
|
|
|
VcSaJen
|
2023-06-27 11:37:49
|
Unofficial nightly builds used to be on https://artifacts.lucaversari.it/libjxl/libjxl/latest/ , but looks like it broke.
|
|
|
|
veluca
|
2023-06-27 02:43:36
|
uhm
|
|
2023-06-27 02:45:55
|
yeah something went wrong 2 weeks ago
|
|
2023-06-27 02:45:57
|
no idea what
|
|
2023-06-27 02:45:59
|
fixing it
|
|
2023-06-27 02:46:56
|
should be ok now?
|
|
|
|
gb82
|
|
fab
|
|
2023-06-28 01:02:32
|
> for anime and manga content
well duh
|
|
|
|
derberg
|
2023-06-28 01:35:16
|
Isn't JXL extremely good for that?
|
|
2023-06-28 01:35:55
|
In that Google Docs document comparing lossless image formats JXL destroyed AVIF for B/W comics (and from personal tests it looks like JXL files with a lot of black, e.g. due to terminal emulator being open on a screenshot, are the files that get me huge above average saving for PNG to JXL conversation)
|
|
|
|
jonnyawsom3
|
2023-06-28 01:37:27
|
> across a wide range of bpp
If I recall it's only modular or lossless that uses pallete, so they probably missed the small size by trying to lower the quality from the start
|
|
2023-06-28 01:38:11
|
I could be completely wrong, it's 3am, but it feels like something that'd happen
|
|
|
|
OkyDooky
|
2023-06-28 01:51:37
|
Could you (or someone) share the link? I haven't seen that one.
(<@230800661837512705>)
|
|
|
|
derberg
|
2023-06-28 01:55:21
|
Yeah, wait a moment.
It is a bit outdated tho
|
|
2023-06-28 01:56:16
|
https://docs.google.com/spreadsheets/d/1ju4q1WkaXT7WoxZINmQpf4ElgMD2VMlqeDN2DuZ6yJ8/edit#gid=174429822
|
|
2023-06-28 01:56:44
|
Screenshot of the interesting part of it
|
|
|
|
gb82
|
|
derberg
Screenshot of the interesting part of it
|
|
2023-06-28 02:11:03
|
EMMA?
|
|
|
|
derberg
|
2023-06-28 02:14:01
|
Proprietary something
|
|
2023-06-28 02:14:28
|
Created for challenges or something like that
|
|
2023-06-28 02:15:21
|
Cause apparently there are challenges for file compression
|
|
|
|
jonnyawsom3
|
2023-06-28 02:20:51
|
Yeah, there was a russian competition linked ages ago where a guy had equal compression to JXL in 50MB of memory footprint or something like that, but he 'wasn't ready' to release the source code and I think they went silent soon after
|
|
|
DZgas Ж
|
|
derberg
Screenshot of the interesting part of it
|
|
2023-06-28 02:42:47
|
Who is 0%
|
|
|
|
derberg
|
|
DZgas Ж
Who is 0%
|
|
2023-06-28 02:43:40
|
The title
|
|
2023-06-28 02:44:03
|
-e 9 -E3 -I 1
|
|
2023-06-28 02:44:52
|
So yeah, a bit outdated imo
|
|
2023-06-28 02:47:24
|
I wonder... BMF might lose on average against a bit saner options if the creator of the table retested
|
|
|
|
monad
|
2023-06-28 07:26:26
|
\> saner options
Like what? AFAIK, lossless hasn't seen relevant changes except at e3.
|
|
|
|
_wb_
|
2023-06-28 07:43:46
|
not that much has changed but there have been some small tweaks
|
|
|
|
derberg
|
|
monad
\> saner options
Like what? AFAIK, lossless hasn't seen relevant changes except at e3.
|
|
2023-06-28 01:14:21
|
Adding -g, higher -I
|
|
2023-06-28 01:18:26
|
Or -e 10 cause lol, it's a benchmark after all
Or -e 11 (if it comes out 👀)
|
|
|
|
afed
|
2023-06-28 01:27:03
|
larger groups are not always better
and the old -I 1 is the new -I 100 if I am not confused?
even if not, the overall diff will not be much noticeable, maybe only on some certain images and as far as i used my bruteforce script, -I 1 still might be the best
|
|
|
|
jonnyawsom3
|
2023-06-28 01:28:59
|
I thought the `I` was reversed the same time it switched from `s` to `e` for speed and effort
|
|
|
|
afed
|
2023-06-28 01:40:10
|
and it be good to have an e3 with lz77 runs, as discussed before
<@794205442175402004> would that require a lot of work?
|
|
|
|
derberg
|
|
afed
larger groups are not always better
and the old -I 1 is the new -I 100 if I am not confused?
even if not, the overall diff will not be much noticeable, maybe only on some certain images and as far as i used my bruteforce script, -I 1 still might be the best
|
|
2023-06-28 01:40:27
|
Well, I got several percent points improvements (for screenshots) when adding -g 3 and switching to -I 100 (when it changed from being 0..1 as you mentioned)
|
|
|
|
_wb_
|
2023-06-28 01:45:40
|
the old -I 1 is the new -I 100 (it went to 0..1 range to 0..100 range)
|
|
|
afed
and it be good to have an e3 with lz77 runs, as discussed before
<@794205442175402004> would that require a lot of work?
|
|
2023-06-28 01:47:55
|
<@179701849576833024> can estimate that better than me, but my gut feeling is that RLE will not help that much at e3 due to it using the weighed predictor. I would assume it is more useful at e2.
|
|
|
|
veluca
|
2023-06-28 01:48:38
|
I mean, it's not hard to try
|
|
2023-06-28 01:48:44
|
But I also think it will not help
|
|
2023-06-28 01:48:51
|
Neither speed nor compression
|
|
|
|
_wb_
|
2023-06-28 01:50:32
|
it could help a bit for decode speed (for images with big runs) and maybe compression
|
|
2023-06-28 01:52:34
|
it helps at e1, but I assume that's to some extent because e1 uses huffman which is not great when there are long runs (it still needs one bit per symbol). At e2+ we use ANS which is better at that kind of distributions (I mean when encoding it without RLE)
|
|
|
|
afed
|
2023-06-28 01:55:53
|
then maybe do the same as for e1/e2 if it's not a photo?
i've also done tests and on some images the larger groups are better, but on typical images it can be even much worse and overall it's not worth it
but, as was mentioned in these changes
<https://github.com/libjxl/libjxl/pull/2610>
maybe find some image characteristics like number of colors and other stuff where larger groups are always better, perhaps on some larger test data and choose the group size in a smarter way
|
|
|
|
_wb_
|
2023-06-28 02:06:39
|
Group boundaries (first row and first column of each group) are poorly predicted since groups are independent. With 128x128 groups, you have 255/16384 poorly predicted pixels, or about 1.5%. With 1024x1024 groups, that goes down to 2047/1048576 or about 0.2%. Also groups have some fixed overhead of a few bytes just for starting a new stream — so fewer groups is also better in that regard.
But on the other hand, more groups means local RCT and local palette can be more effective, e.g. an image that has thousands of colors in each 1024x1024 group (so palette cannot be used) may have some 128x128 regions with only a few distinct colors.
|
|
|
|
afed
|
2023-06-28 02:17:29
|
maybe even using e10 on a massive set of various images and collecting statistics would be useful for understanding what is best for which images, although i think this would require a supercomputer otherwise it would take ages
it's also sad that it's not possible to identify by usual tools with what options the image has been compressed
|
|
|
|
jonnyawsom3
|
2023-06-28 02:22:36
|
Wonder if a flag could embed the options used to generate the image inside the metadata
|
|
|
|
derberg
|
|
derberg
Well, I got several percent points improvements (for screenshots) when adding -g 3 and switching to -I 100 (when it changed from being 0..1 as you mentioned)
|
|
2023-06-28 02:25:26
|
To quote myself:
»in 0.6.1 I achieved about 53% new size (after converting 163552 screenshots by using cjxl -q 100 -m -s 9 -E 3 -I 1: 112216M → 59561M; ca. 46.9228986953732 % reduction«
And since 0.7.0 I add -g3 (and switched to -I 100) and I get ~52.8...% reduction on the same kind of files (input are PNG screenshots of my two monitors taken with xfce4-screenshooter).
|
|
2023-06-28 02:30:38
|
I still do it since the jxl files that xfce4-screenshoter saves are bigger than what I _usually_ get.
|
|
|
|
afed
|
2023-06-28 02:30:40
|
yeah -g3 is good for larger resolutions with lots of simple areas, but it's not good by default for all images
|
|
|
|
derberg
|
2023-06-28 02:31:23
|
Yeah, it is image dependent
|
|
2023-06-28 02:32:43
|
Maybe it would be good to have a table that did comparisons to the "expected good performing options" for each use case.
|
|
|
|
jonnyawsom3
|
2023-06-28 02:37:48
|
A case of heuristics yet again, figuring out if an image should be lossless or lossy, large group or small..
|
|
|
|
derberg
|
2023-06-28 02:41:10
|
The thing about the table is that they did it with 0.7.0 when -I 1 already switched to being -I 100
|
|
|
|
VcSaJen
|
2023-06-28 02:41:45
|
I wonder if any of image editors would implement "presets" in save dialog: anime, photo, screenshot, scan, etc.
|
|
|
|
derberg
|
2023-06-28 02:42:31
|
Doesn't hurt to suggest it on repos I guess
|
|
|
|
jonnyawsom3
|
2023-06-28 03:06:49
|
Good point, I've got a vague memroy of that happeneing with another format but I can't remember what
|
|
|
|
elfeïn
|
|
A case of heuristics yet again, figuring out if an image should be lossless or lossy, large group or small..
|
|
2023-06-28 07:12:53
|
Do a lowpass filter and a highpass filter, separately. If the highpass isn't far off from the lowpass, use lossy.
|
|
|
|
Traneptora
|
2023-06-28 07:13:53
|
best way to determine if lossless works well is to just try it, tbh.
|
|
|
|
elfeïn
|
2023-06-28 07:14:53
|
That's true too
|
|
|
|
jonnyawsom3
|
2023-06-28 07:14:55
|
I was tempted to suggest using the pallete check as a 'cheap' way to decide between modular or VarDCT, since obviously if it's using only a dozen colors it's probably not a photograph
|
|
2023-06-28 07:15:16
|
A lot of ways to do it, including brute force
|
|
|
|
elfeïn
|
2023-06-28 07:18:15
|
o ye
|
|
2023-06-28 07:18:25
|
i forgot about palletes
|
|
|
|
spider-mario
|
2023-06-28 07:20:03
|
fast lossless is very fast, so doesn’t take much time to try
|
|
|
|
jonnyawsom3
|
2023-06-28 07:37:37
|
Good point, I was about to say that's still the largest filesize for modular, but when it's bad for VarDCT it's usually 6x the size anyway so should work
|
|
|
|
fab
|
2023-06-29 07:08:33
|
Quality of latest libjxl is so natural
|
|
2023-06-29 07:08:41
|
Like 1897,6 mb RAm
|
|
2023-06-29 07:09:22
|
It's improving on screenshots thanks to Jon suggestions
|
|
2023-06-29 07:16:48
|
In general e9 cpu 8 in dark conditions have better fidelity
|
|
|
pshufb
|
2023-06-29 03:56:47
|
does adobe use libjxl?
|
|
|
|
_wb_
|
2023-06-29 04:02:01
|
officially I don't know but it would be extremely surprising if they wouldn't (and also an extreme coincidence that they produce bitstreams that exactly match the output of what libjxl produces)
|
|
|
|
Traneptora
|
2023-06-29 07:22:47
|
<@794205442175402004> regarding #2581, should I open a separate issue regarding the fact that recompressing JXL -> JXL turns an enum space into an ICC?
|
|
|
|
_wb_
|
2023-06-29 07:32:22
|
Nah the one issue is fine
|
|
|
|
pshufb
|
|
_wb_
officially I don't know but it would be extremely surprising if they wouldn't (and also an extreme coincidence that they produce bitstreams that exactly match the output of what libjxl produces)
|
|
2023-06-29 09:16:07
|
thanks
|
|
|
|
jonnyawsom3
|
2023-06-29 11:58:54
|
Thought I'd check, are reference frames used at all for animation currently? There's 2 lines for it in documentation but no info anywhere else and no implimentation that I'm aware of
|
|
2023-06-30 02:33:10
|
And a bonus question before I go to sleep
Are the progressive steps essentially the same as what you get when using `--resampling` so 2/4/8 groups of pixels are mixed into 1 color? Or is it more dependant on the pixels that get loaded first?
|
|
|
|
Traneptora
|
|
Thought I'd check, are reference frames used at all for animation currently? There's 2 lines for it in documentation but no info anywhere else and no implimentation that I'm aware of
|
|
2023-06-30 05:22:44
|
a frame can be referenced provided that
(1) it's not an LF frame
(2) it's not the Last Frame
(3) Its duration is zero, or it's tagged as reference-able.
I don't believe libjxl currently produces animations that have zero-duration reference-only frames, although I can definitely see it being possible with patches and fast lossless.
|
|
|
And a bonus question before I go to sleep
Are the progressive steps essentially the same as what you get when using `--resampling` so 2/4/8 groups of pixels are mixed into 1 color? Or is it more dependant on the pixels that get loaded first?
|
|
2023-06-30 05:24:52
|
Resampling is a tagged, explicit, nonseparable algorithm for upscaling that counts as the full image
|
|
2023-06-30 05:25:08
|
So an image that encodes 512x512 pixel data with "resample=2" tagged is considered a 1024x1024 image
|
|
2023-06-30 05:25:18
|
and decoders MUST resample it, using the specified algorithm
|
|
2023-06-30 05:26:02
|
Progressive Steps, provided by libjxl, are upscaled, partially decoded versions of the image, but which resampling algorithm is used is not documented, and I'm not sure if it is the same algorithm as specified in --resampling
|
|
2023-06-30 05:27:30
|
Should it be documented? probably
|
|
2023-06-30 05:28:08
|
in either case, libjxl's progressive steps are a feature of libjxl, and resampling is a feature of the JPEG XL codestream itself, that all decoders MUST implement
|
|
|
|
Deleted User
|
2023-06-30 11:00:39
|
Is XYB a perceptual lightness linear color space?
|
|
2023-06-30 11:00:43
|
Does it account for stuff like Heimholz?
|
|
|
|
yurume
|
2023-06-30 11:05:46
|
basically yes: https://en.wikipedia.org/wiki/LMS_color_space#Image_processing
|
|
|
|
Deleted User
|
|
yurume
basically yes: https://en.wikipedia.org/wiki/LMS_color_space#Image_processing
|
|
2023-06-30 11:06:19
|
Any comparison with JzAzBz?
|
|
2023-06-30 11:06:41
|
Love that space but it is too slow for realtime tone mapping.
|
|
|
|
Traneptora
|
|
Is XYB a perceptual lightness linear color space?
|
|
2023-06-30 11:37:13
|
it's nonlinear, as it has a biased cubic transfer
|
|
|
|
Deleted User
|
|
Traneptora
it's nonlinear, as it has a biased cubic transfer
|
|
2023-06-30 11:40:49
|
I mean perceptually linear.
|
|
2023-06-30 11:41:14
|
Which means, corresponding to the experimental data of changes of brightness being equal for an average human observer.
|
|
2023-06-30 12:23:25
|
Nevermind, I measured XYB and it seems like it is a bit distorted in some spots brightness-wise.
|
|
|
|
w
|
2023-06-30 12:25:38
|
how'd u measure it
|
|
2023-06-30 12:25:42
|
with ur eyes?
|
|
|
|
Deleted User
|
|
w
how'd u measure it
|
|
2023-06-30 12:36:06
|
Against experimental data and just comparing results to JaAzBz results.
|
|
|
|
jonnyawsom3
|
|
Traneptora
a frame can be referenced provided that
(1) it's not an LF frame
(2) it's not the Last Frame
(3) Its duration is zero, or it's tagged as reference-able.
I don't believe libjxl currently produces animations that have zero-duration reference-only frames, although I can definitely see it being possible with patches and fast lossless.
|
|
2023-06-30 12:43:14
|
Ahh, so it's essentially patches but across frames, and only when a flag is set so it can be referenced?
I imagine cjxl and the other implementations don't have a way to set that flag yet
|
|
|
|
_wb_
|
2023-06-30 02:28:09
|
currently libjxl internally has an EncodeFrame function that is just encoding a single frame independently — it might create a reference-only patch frame in the process, but it isn't going to look at any previous or future frames, it uses patches only in an intra-frame way
|
|
|
|
jonnyawsom3
|
2023-06-30 04:25:55
|
Another spontaneous thought, I remember a while ago there was a discussion about how lenient patches should be so it doesn't need to be mathematically identical to find a match. Could probably bind that to the distance, so lossless is still mathematically lossless, but the further you go the more it can replace subtle differences
|
|
|
|
OkyDooky
|
2023-07-01 02:13:48
|
Just FYI https://ffmpeg.org/pipermail/ffmpeg-devel/2023-July/311370.html
|
|
2023-07-01 02:15:31
|
I am wondering how would be possible to handle stereo paired images in the JPEG XL?
|
|
|
|
jonnyawsom3
|
2023-07-01 06:53:11
|
I know JXL was advertised as supporting less common use cases like thermal, stereo/3d images and such
|
|
|
|
OkyDooky
|
2023-07-01 11:58:35
|
You mean, like embedding encrypted messages inside an image?
(<@226977230121598977>)
|
|
|
|
DZgas Ж
|
|
You mean, like embedding encrypted messages inside an image?
(<@226977230121598977>)
|
|
2023-07-02 12:05:26
|
any data in original form
|
|
|
|
VcSaJen
|
|
DZgas Ж
any data in original form
|
|
2023-07-02 02:58:42
|
If you don't care about hiding it, you can just use EXIF.
|
|
|
|
_wb_
|
2023-07-02 06:16:48
|
Pixel values are just numbers so you can encode anything as an image
|
|
2023-07-02 06:17:53
|
And yes, you could also encode arbitrary info in jxl art (MA trees), but it would be more convenient to just encode it in the pixel values themselves 🙂
|
|
|
|
DZgas Ж
|
|
VcSaJen
If you don't care about hiding it, you can just use EXIF.
|
|
2023-07-02 07:21:07
|
Boring
|
|
|
190n
|
2023-07-03 12:19:54
|
i'm seeing that for a jxl which is a losslessly transcoded jpeg, decoding to pixels is several times _faster_ than decoding to jpeg -- is this expected?
|
|
2023-07-03 12:20:11
|
decoding to pixels also has better gains from adding threads
|
|
2023-07-03 12:21:44
|
very approx numbers as i haven't tried many iterations or many files. speeds in MP/s. my cpu has 16 logical threads.
```
threads: 1 16
dec to pixels 55 260
dec to JPEG 13 14
```
|
|
|
|
jonnyawsom3
|
2023-07-03 12:27:31
|
Decoding to jpeg is for compatibility more than anything as far as I'm aware
|
|
|
|
190n
|
2023-07-03 12:29:53
|
but this is a file that was losslessly transcoded from jpeg
|
|
2023-07-03 12:30:03
|
it's not decoding to pixels and then encoding a new jpeg, it's just recovering the original jpeg
|
|
|
|
jonnyawsom3
|
2023-07-03 01:25:03
|
But recovering the old jpeg means reversing the transformations and using the recostruction data, rather than just using the pixels already decoded
|
|
|
|
190n
|
2023-07-03 01:27:28
|
hm, maybe i need to learn more about how reconstruction works. i had thought that decoding to pixels would decode to jpeg and then just decode the resulting jpeg.
|
|
2023-07-03 01:29:59
|
i had understood that a use case for jpeg xl would be recompressing existing jpegs, and converting them back to jpeg on the fly for clients that don't support jpeg xl. is that not actually intended? it doesn't seem like a great idea if decoding to jpeg is this slow.
|
|
|
|
jonnyawsom3
|
2023-07-03 01:34:01
|
Bear in mind, I'm hungover and very tired at 2am from getting stuck in London last night, so take everything with a spoon of salt
Decode to pixels uses the normal JXL output and just converts it to whatever format you specify, I'm making assumptions based on the reconstruction being so slow and the fact it needs extra data to be done
|
|
|
|
190n
|
2023-07-03 01:34:59
|
in that example i used ppm and wrote to /dev/null so the output conversion should have been ~instant
|
|
2023-07-03 01:37:03
|
so the way i'm trying to wrap my head around this now is that lossless jpeg transcoding uses some subset of jpeg xl operations that also exist in jpeg, but it somehow represents their results more efficiently than jpeg does so you end up with a smaller file. and then it has some extra data that lets you reverse those operations into the form used by jpeg. is that sorta correct?
|
|
|
|
jonnyawsom3
|
|
190n
in that example i used ppm and wrote to /dev/null so the output conversion should have been ~instant
|
|
2023-07-03 01:38:42
|
Hmm, well 4x slower doesn't seem bad for reconstruction then, assuming it can only use a single thread due to transcoding back as a continuous stream
|
|
|
190n
so the way i'm trying to wrap my head around this now is that lossless jpeg transcoding uses some subset of jpeg xl operations that also exist in jpeg, but it somehow represents their results more efficiently than jpeg does so you end up with a smaller file. and then it has some extra data that lets you reverse those operations into the form used by jpeg. is that sorta correct?
|
|
2023-07-03 01:41:28
|
If I recall there's 3 methods of using JXL
A normal JXL file that requires a JXL decoder
A transcoded jpeg that can be read by JXL decoders or turned back into the original jpeg for legacy decoders
A jpeg compatible JXL file that can be read by either assuming filetype isn't an issue (Yet to be seen but I think I saw it in some old slides)
|
|
|
|
190n
|
|
Hmm, well 4x slower doesn't seem bad for reconstruction then, assuming it can only use a single thread due to transcoding back as a continuous stream
|
|
2023-07-03 01:43:09
|
i was surprised by these results because i thought lossless jpeg transcoding was something like `image.jpg.gz` -- i.e. since the pixels were encoded as jpeg _and then_ recompressed as jxl or anything else, to decode to pixels you would have to decode back to jpeg _and then_ decode that jpeg. so decoding to jpeg should be faster than decoding to pixels.
|
|
2023-07-03 01:43:36
|
i also thought this was the case because i'd heard that JPEG XL decoders also need the capability to decode JPEGS
|
|
|
190n
i was surprised by these results because i thought lossless jpeg transcoding was something like `image.jpg.gz` -- i.e. since the pixels were encoded as jpeg _and then_ recompressed as jxl or anything else, to decode to pixels you would have to decode back to jpeg _and then_ decode that jpeg. so decoding to jpeg should be faster than decoding to pixels.
|
|
2023-07-03 01:43:45
|
but it seems like this isn't actually how that works
|
|
|
|
jonnyawsom3
|
2023-07-03 01:44:59
|
Best to wait for morning over here when most of the devs wake up, I'm not entirely sure of it myself and I know my memory isn't the greatest. Wouldn't want to waste your night feeding you wrong info
|
|
|
|
190n
|
2023-07-03 01:45:54
|
fair
|
|
2023-07-03 01:46:02
|
well, thanks for your help anyway
|
|
|
|
Tirr
|
2023-07-03 01:46:45
|
jpeg reconstruction had a speed boost recently https://github.com/libjxl/libjxl/pull/2534
|
|
|
|
jonnyawsom3
|
|
190n
i was surprised by these results because i thought lossless jpeg transcoding was something like `image.jpg.gz` -- i.e. since the pixels were encoded as jpeg _and then_ recompressed as jxl or anything else, to decode to pixels you would have to decode back to jpeg _and then_ decode that jpeg. so decoding to jpeg should be faster than decoding to pixels.
|
|
2023-07-03 01:47:18
|
The one thing I can say for certain is that the jpeg isn't just in a zip file, since there's a flag to not include the reconstruction metadata in the JXL file when transcoding, if that gives any leads
|
|
2023-07-03 01:47:31
|
Also that pull, if you're on an old version
|
|
|
|
190n
|
|
Tirr
jpeg reconstruction had a speed boost recently https://github.com/libjxl/libjxl/pull/2534
|
|
2023-07-03 01:47:38
|
https://github.com/libjxl/libjxl/issues/2572 oh, reference issue is my question exactly
|
|
2023-07-03 01:48:06
|
seems like that pull hasn't landed in any release? so i definitely wouldn't have it
|
|
2023-07-03 01:48:16
|
i have 0.8.2 from arch
|
|
2023-07-03 01:48:18
|
i'll try building from git
|
|
|
|
jonnyawsom3
|
2023-07-03 01:48:50
|
Ah, then yeah. No releases planned until 1.0 currently, can also grab from GitHub actions if that's any faster
|
|
|
|
190n
|
|
Tirr
jpeg reconstruction had a speed boost recently https://github.com/libjxl/libjxl/pull/2534
|
|
2023-07-03 03:13:41
|
oh, reading this more closely it seems related to what i was seeing in <#804324493420920833>, where `JxlDecoderReleaseJPEGBuffer` would report that none of the output buffer had been written to even though it actually had written what looked like jpeg data into the buffer
|
|
2023-07-03 03:13:43
|
interesting
|
|
|
190n
very approx numbers as i haven't tried many iterations or many files. speeds in MP/s. my cpu has 16 logical threads.
```
threads: 1 16
dec to pixels 55 260
dec to JPEG 13 14
```
|
|
2023-07-03 03:44:08
|
ok with latest git build, singlethreaded decode to jpeg is 48MP/s. much better
|
|
|
|
jonnyawsom3
|
2023-07-03 03:46:38
|
Probably scales somewhat exponentially for the size of the image too, so should be a very good speedup indeed
|
|
|
|
_wb_
|
2023-07-03 05:27:35
|
JPEG reconstruction does this:
jxl entropy decode to get quantized coefficients, jpeg entropy encode
To pixels it is:
jxl entropy decode, dequantization and inverse DCT, YCbCr to RGB.
|
|
2023-07-03 05:28:32
|
More work overall to decode to pixels, but it parallelizes much better (both simd and threading)
|
|
|
|
190n
|
2023-07-03 05:35:08
|
i see, thanks
|
|
2023-07-03 05:35:28
|
and thanks for speeding it up right on time for me to start playing around with this stuff, lol
|
|
|
Nova Aurora
|
|
_wb_
More work overall to decode to pixels, but it parallelizes much better (both simd and threading)
|
|
2023-07-03 07:02:02
|
Is that a hard limit or just because of development priorities?
|
|
|
|
_wb_
|
2023-07-03 07:05:24
|
We can't change how jpeg entropy coding works
|
|
2023-07-03 07:07:16
|
I suppose we _could_ try a threaded jpeg encode in stripes of one group high, would that be worth trying <@179701849576833024> ?
|
|
|
|
veluca
|
2023-07-03 07:44:06
|
... maybe?
|
|
|
|
yurume
|
2023-07-04 02:44:16
|
continuing question from https://discord.com/channels/794206087879852103/848189884614705192/1124850901056761886: the easiest way would be to put a zero-duration frame which would be immediately overwritten completely
|
|
|
|
username
|
2023-07-05 09:13:50
|
I was looking at random github repos and I found a random issue page showing lossless JXL performing noticeably worse then lossless WebP: https://github.com/diasurgical/devilutionX/issues/6309
|
|
2023-07-05 09:14:29
|
with effort 9 in cjxl I can only get the file down to around 473KB
|
|
2023-07-05 09:15:02
|
here is the image (hopefully discord doesn't mess with it in a bad way)
|
|
|
|
VcSaJen
|
2023-07-05 09:16:03
|
I agree that PNG screenshot support should be added first
|
|
|
|
username
|
2023-07-05 09:18:15
|
it seems like that's what they are gonna do for that project
|
|
2023-07-05 09:18:54
|
but besides that project it seems like palette detection isn't working with that image in cjxl?
|
|
2023-07-05 09:19:31
|
maybe I shoulda posted this stuff in <#804324493420920833> since format wise JXL should be smaller here
|
|
|
|
VcSaJen
|
2023-07-05 09:19:36
|
How many colors ImageMagick report?
|
|
|
|
username
|
2023-07-05 09:22:04
|
I do not know how to use ImageMagick however that PNG has a palette and is 8-bit so in theory it shouldn't have more then 256 colors from what I understand
|
|
2023-07-05 09:23:31
|
(I know this isn't ImageMagick)
|
|
|
|
VcSaJen
|
2023-07-05 09:24:31
|
JXL lossless average compression is already high enough, but it really need to improve 1% worst compression and 0.1% worst compression.
|
|
|
|
fab
|
2023-07-05 04:55:59
|
Jxl does it's best at d 0.74 e8
|
|
|
|
jonnyawsom3
|
2023-07-05 07:20:59
|
We're talking about lossless
|
|
2023-07-06 12:35:30
|
Was going to try an experiment with some screenshots of Mario, then realised the JXL files also can't get below the original. Might be related to the screenshot above, maybe not. Worth mentioning anyway
<https://mario.wiki.gallery/images/1/14/FireMarioSMB.png>
|
|
2023-07-06 12:39:58
|
Seems like effort 10 can shave 300 bytes consistently off the screenshots, so something has a fairly big impact but I'm not sure what
<https://mario.wiki.gallery/images/d/d7/SMB_Title_Screen.png>
|
|
|
|
monad
|
|
Was going to try an experiment with some screenshots of Mario, then realised the JXL files also can't get below the original. Might be related to the screenshot above, maybe not. Worth mentioning anyway
<https://mario.wiki.gallery/images/1/14/FireMarioSMB.png>
|
|
2023-07-06 07:55:58
|
`-d 0 -e 9 -I 0 -P 0 --patches 0`
|
|
|
Seems like effort 10 can shave 300 bytes consistently off the screenshots, so something has a fairly big impact but I'm not sure what
<https://mario.wiki.gallery/images/d/d7/SMB_Title_Screen.png>
|
|
2023-07-06 07:56:21
|
`-d 0 -e 9 -I 0 -P 0`
|
|
2023-07-06 07:58:05
|
more efficient than doing e10
|
|
2023-07-06 08:28:27
|
add `--brotli_effort 11` to beat e10, and beat WebP for second image
|
|
|
|
_wb_
|
2023-07-06 08:28:59
|
with patch detection that could actually detect all those repeating tiles, probably it could be much better — just need to figure out an algorithm for that that isn't super slow
|
|
|
|
monad
|
2023-07-06 08:31:05
|
It's curious to me that patches are too costly for image 1, while the bricks at the top are patched (except for below the coin)
|
|
2023-07-06 08:39:06
|
I guess because the content is so simple, signaling patches ends up costing more than otherwise
|
|
|
|
_wb_
|
2023-07-06 08:40:02
|
yeah, it's low color count, and just doing lz77 can be cheaper than signaling patches
|
|
2023-07-06 08:42:48
|
if the color count makes pixels fit in 4 bits, PNG (and I suppose WebP too?) can do bitpacking (putting two pixels in a byte) while in JXL we don't have that as a format-level thing — we also don't do byte-based entropy coding in the first place.
|
|
2023-07-06 08:44:11
|
We could experiment with combining multiple pixels into one symbol though, even though that's not a format-level thing in JXL: the modular transform chaining could be exploited to do something quite similar
|
|