|
Tirr
|
2024-05-06 07:44:52
|
if you want every frame to be in the box
|
|
|
Orum
|
2024-05-06 07:45:21
|
I just want every frame to be a fully intra-coded (and seekable) frame
|
|
|
|
Tirr
|
2024-05-06 07:46:03
|
I think that's the only option with cjxl
|
|
|
_wb_
|
2024-05-06 07:51:36
|
Like I said, there is no real tooling yet
|
|
|
|
Orum
|
2024-05-06 07:51:38
|
ugh, well that's not entirely practical when a video could have tens or hundreds of thousands of frames
|
|
|
|
_wb_
|
2024-05-06 07:53:04
|
I don't think libjxl even uses the frame index box to make seeking actually more efficient — multi-frame has never been a priority...
|
|
2024-05-06 07:53:30
|
But in any case it exists and tooling can be improved
|
|
|
|
Orum
|
2024-05-06 07:53:49
|
So what does it currently do for multi-frame then? Just intra-only, but no seekable index?
|
|
|
|
_wb_
|
2024-05-06 07:57:14
|
The encoder can optionally produce the index, but the decoder currently ignores it iirc
|
|
2024-05-06 07:59:22
|
In any case the encoder is always encoding the frames as you give them, it doesn't try to do any automatic inter frame thing (not even just cropping away regions that didn't change)
|
|
|
|
Orum
|
2024-05-06 08:21:51
|
well if the index is ignored by the decoder then it's pointless
|
|
|
|
_wb_
|
2024-05-06 08:46:00
|
Not if it doesn't get ignored by a future decoder
|
|
|
|
Orum
|
2024-05-06 08:47:02
|
well future me can consider using it then <:AngryCry:805396146322145301>
|
|
|
|
_wb_
|
2024-05-06 09:22:39
|
or current you can consider making a pull request to make the decoder not ignore it? 🙂
|
|
|
spider-mario
|
|
Orum
also, H.264 doesn't support HDR like JXL does 😮💨, so it's way more limited
|
|
2024-05-06 10:08:05
|
technically, it should (but not sure the compression is very good)
|
|
2024-05-06 10:08:18
|
it can compress to 10 bits and you can tag it as being PQ or HLG
|
|
2024-05-06 10:09:55
|
```shell
$ ffmpeg -i input.png -c:v libx264 -colorspace bt2020nc -color_primaries bt2020 -color_trc smpte2084 -pix_fmt yuv444p10le -crf 1 -preset veryslow h264.mkv
```
|
|
2024-05-06 10:10:00
|
something like this
|
|
|
Quackdoc
|
|
Orum
also this is with the default `--faster_decoding` (i.e. 0) in jxl
|
|
2024-05-06 11:55:38
|
faster_decoding below 3 are bugged in a lot of cases I find
|
|
2024-05-06 12:06:49
|
also <@548366727663321098> just download the pkgbuild from arch or manjaro `pkgctl repo clone --protocol https ffmpeg` and patch it using this, though remove the nvenc part probably, I needed that because of a bug
|
|
2024-05-06 12:07:05
|
iirc I already sent the jxl patch
|
|
|
|
Orum
|
|
Quackdoc
faster_decoding below 3 are bugged in a lot of cases I find
|
|
2024-05-06 03:39:29
|
well I see little reason to not use 4 there
|
|
|
spider-mario
technically, it should (but not sure the compression is very good)
|
|
2024-05-06 03:40:42
|
not according to the spec (which is why Sony made XAVC which is basically just AVC but with HDR/WG support in-spec)
|
|
|
|
spider-mario
|
2024-05-06 03:41:39
|
what about the spec contraindicates HDR encoding?
|
|
|
|
Quackdoc
|
|
Orum
not according to the spec (which is why Sony made XAVC which is basically just AVC but with HDR/WG support in-spec)
|
|
2024-05-06 03:56:32
|
the specification has been updated to include the cicp stuff
|
|
|
|
Orum
|
2024-05-06 03:57:41
|
ah, well I generally only look at the original spec, as using later specs is liable to run into problems with HW decode, as if H.264 doesn't have enough of those
|
|
|
lonjil
|
2024-05-06 03:58:24
|
wouldn't color space stuff generally by handled elsewhere than the hw decoder anyway?
|
|
|
|
Quackdoc
|
2024-05-06 03:59:05
|
```
Rec. ITU-T H.264 | ISO/IEC 14496-10 version 25 refers to the integrated version 24 text after its amendment to specify
the Progressive High 10 profile; support for additional colour-related indicators, including the hybrid log-gamma transfer
characteristics indication, the alternative transfer characteristics SEI message, the ICTCP colour matrix transformation,
chromaticity-derived constant luminance and non-constant luminance colour matrix coefficients, the colour remapping
information SEI message, and introduces miscellaneous minor corrections and clarifications. In the ITU-T, the changes
for version 25 were approved on 13 April 2017
```
|
|
2024-05-06 03:59:17
|
most hwdecs will support this
|
|
2024-05-06 03:59:25
|
not high 10, but the hdr stuff
|
|
2024-05-06 03:59:36
|
since it's part of parsing
|
|
|
|
Orum
|
2024-05-06 03:59:42
|
you *can* put H.264 into a container that has the metadata for displaying HDR or conform to the updated spec, but it's always a gamble on whether or not HW decode will work properly with it (or even software decode for that matter)
|
|
2024-05-06 04:02:53
|
just like you can technically do with jpeg, but again, getting things right on the decode side is a hassle
|
|
2024-05-06 04:05:43
|
...and not just with HDR, but pixel formats in general. Case in point, try opening a XYB JPEG (or PNG) in nomacs, and you'll immediately see the problem.
|
|
2024-05-06 04:07:29
|
quite honestly I'm shocked that Firefox gets it right, considering how many issues they have with AVIF
|
|
|
|
lonjil
|
2024-05-06 04:09:00
|
firefox's cms only does 8 bit per channel so lol
|
|
|
Orum
...and not just with HDR, but pixel formats in general. Case in point, try opening a XYB JPEG (or PNG) in nomacs, and you'll immediately see the problem.
|
|
2024-05-06 04:09:37
|
yeah but I think video players are more likely to have decent support for this sort of stuff compared to image viewers that just pretend everything is sRGB
|
|
|
|
Orum
|
2024-05-06 04:11:07
|
that's a lot of faith that I think is misplaced; for instance, look at how poorly nvdec deals with lossless H.264 *to this day*
|
|
2024-05-06 04:12:56
|
assuming you have a Nvidia GPU and your player is configured to use it and doesn't *explicitly disable it for H.264*, and you open up a lossless file, you'll get nice corrupted output, even for 8-bit
|
|
|
|
spider-mario
|
|
Orum
you *can* put H.264 into a container that has the metadata for displaying HDR or conform to the updated spec, but it's always a gamble on whether or not HW decode will work properly with it (or even software decode for that matter)
|
|
2024-05-06 04:16:02
|
true, but then so is jxl support
|
|
|
|
Orum
|
2024-05-06 04:16:09
|
here's a frame from lossless 8-bit H.264 on Lovelace in mpv with nvdec
|
|
|
spider-mario
true, but then so is jxl support
|
|
2024-05-06 04:19:58
|
literally in the JXL spec:
> Support of high-quality image compression, including higher resolution, higher bit depth, higher dynamic range and wider color gamut coding.
|
|
2024-05-06 04:20:23
|
if you search the original H.264 spec for "dynamic range" or "HDR" or any similar terms, nothing even comes up
|
|
|
|
lonjil
|
|
Orum
assuming you have a Nvidia GPU and your player is configured to use it and doesn't *explicitly disable it for H.264*, and you open up a lossless file, you'll get nice corrupted output, even for 8-bit
|
|
2024-05-06 04:25:42
|
But that's a difference in the actual. Metadata telling you how to interpret the decoded output shouldn't concern the HW decoder at all.
|
|
|
Orum
literally in the JXL spec:
> Support of high-quality image compression, including higher resolution, higher bit depth, higher dynamic range and wider color gamut coding.
|
|
2024-05-06 04:26:55
|
I think Spider Mario's point is that JXL support is less common than hdr h264 support.
|
|
|
|
Orum
|
|
lonjil
But that's a difference in the actual. Metadata telling you how to interpret the decoded output shouldn't concern the HW decoder at all.
|
|
2024-05-06 04:27:29
|
tone mapping and color handling in general is a concern if SW doesn't sit between the decode and display, and even if it does there's no guarantee that SW does it right
|
|
|
|
lonjil
|
2024-05-06 04:28:46
|
I wouldn't trust anything that didn't have software between decoding and display
|
|
2024-05-06 04:29:29
|
Like h265 wouldn't be any better here
|
|
|
|
Orum
|
2024-05-06 04:29:30
|
I wouldn't trust the SW even if it was there without some way of verifying it's doing the right thing
|
|
2024-05-06 04:30:08
|
and even "the right thing" is up for debate with how many different, valid ways there are of tone mapping, for example
|
|
|
|
lonjil
|
2024-05-06 04:30:14
|
Even JXL wouldn't be better here because you still need the image viewer to do the right thing
|
|
|
Orum
and even "the right thing" is up for debate with how many different, valid ways there are of tone mapping, for example
|
|
2024-05-06 04:30:40
|
But that's true regardless of what codec you're using
|
|
|
|
Orum
|
2024-05-06 04:31:15
|
the difference is that the JXL spec (and many others) make very explicit how DR/gamut information is supposed to be stored and used, while older codecs like H.264 make zero mention of it
|
|
2024-05-06 04:32:19
|
HDR and WG wasn't even a consideration when H.264 came out, so it makes sense that they didn't go out of their way to include it
|
|
2024-05-06 04:36:07
|
And before you even get to decode issues, there are encode issues for HDR in H.264. A proper lossy encoder needs to know the color space information in order to make the correct coding decisions for perceptual optimization, and without even being able to specify that in several H.264 encoders, there's no hope of it being correct. Even when you can specify it, if it's only used to tag the output (and not during the encoding) you're likely to end up with terrible looking output.
|
|
2024-05-06 04:38:23
|
e.g. while you can specify color space info in x264 for wider gamuts and HDR, I'm not sure if the encoder even takes them into account
|
|
|
|
spider-mario
|
|
Orum
literally in the JXL spec:
> Support of high-quality image compression, including higher resolution, higher bit depth, higher dynamic range and wider color gamut coding.
|
|
2024-05-06 05:25:04
|
I mean supporting jxl at all
|
|
|
|
Orum
|
2024-05-06 05:29:59
|
true, but ffmpeg and imagemagick support it, so by extension a ton of software got support for it
|
|
|
|
Quackdoc
|
|
Orum
true, but ffmpeg and imagemagick support it, so by extension a ton of software got support for it
|
|
2024-05-06 06:00:35
|
image-rs doesnt T.T
|
|
|
|
Orum
|
2024-05-06 06:01:46
|
rust problems <:CatSmile:805382488293244929>
|
|
|
|
lonjil
|
2024-05-06 06:03:59
|
Anything that uses ffmpeg but doesn't handle hdr h264 probably doesn't handle hdr JXL correctly either
|
|
|
|
Quackdoc
|
|
Orum
rust problems <:CatSmile:805382488293244929>
|
|
2024-05-06 06:50:54
|
the worst part is, is that it worked fine, it is purely ideological for not including it, now I need to find an entirely new image library for rust, or just use imagemagick
|
|
|
|
Orum
|
2024-05-06 06:51:52
|
A rust developer being ideological? Impossible! <:KekDog:805390049033191445>
|
|
|
190n
|
|
Quackdoc
the worst part is, is that it worked fine, it is purely ideological for not including it, now I need to find an entirely new image library for rust, or just use imagemagick
|
|
2024-05-06 06:55:13
|
source?
|
|
|
|
Quackdoc
|
|
190n
source?
|
|
2024-05-06 07:07:07
|
https://github.com/image-rs/image/issues/1979
|
|
|
|
Orum
|
2024-05-06 07:30:52
|
well the official spec is paywalled but in many ways the library is more important
|
|
|
Meow
|
2024-05-06 08:07:27
|
Surprising that it supports JPEG which spec is paywalled too
|
|
|
|
Orum
|
2024-05-06 08:16:12
|
quick, petition for its removal <:PeepoDiamondSword:805394101340078092>
|
|
|
|
veluca
|
2024-05-06 08:18:32
|
and then they have avif, which has people asking for licensing fees for the container...
|
|
|
|
Quackdoc
|
2024-05-06 08:18:37
|
sadly it means every app needs to implement jxl-oxide on it's own, it's not too hard, but it is annoying
|
|
|
|
veluca
|
2024-05-06 08:19:22
|
unfortunately libjxl is still by far the best jxl encoder
|
|
2024-05-06 08:19:40
|
which means that in some cases you need jpegxl-rs or equivalent
|
|
2024-05-06 08:19:53
|
which already gave me build headaches... https://dev.azure.com/getzola/zola/_build/results?buildId=3265&view=logs&j=d2980ad8-b87d-5294-4faf-0af1145b0486&t=4895aa0f-ffeb-520a-bc7b-cf61e25f8fa6
|
|
|
jonnyawsom3
|
|
Orum
assuming you have a Nvidia GPU and your player is configured to use it and doesn't *explicitly disable it for H.264*, and you open up a lossless file, you'll get nice corrupted output, even for 8-bit
|
|
2024-05-06 08:21:44
|
Uhh... I used lossless h264 a few weeks ago and it worked perfectly with hardware decode, even on discord which surprised me
|
|
|
|
Orum
|
2024-05-06 08:21:58
|
uhhh... what?!
|
|
|
|
Quackdoc
|
|
veluca
which means that in some cases you need jpegxl-rs or equivalent
|
|
2024-05-06 08:22:03
|
jpegxl-rs is widely unusable anyways because the bindings are gplv3 lmao
|
|
|
|
Orum
|
2024-05-06 08:22:08
|
nvdec decoding?
|
|
|
|
veluca
|
|
Quackdoc
jpegxl-rs is widely unusable anyways because the bindings are gplv3 lmao
|
|
2024-05-06 08:22:28
|
yeah that's another issue
|
|
2024-05-06 08:22:39
|
kinda feel like resurrecting libjxl-sys & friends
|
|
|
|
jonnyawsom3
|
|
Orum
nvdec decoding?
|
|
2024-05-06 08:27:11
|
I'll try it again since it was 4am and it could've turned itself off like you mentioned before
|
|
|
|
Orum
|
2024-05-06 08:54:41
|
yeah, it's not every frame either
|
|
|
VcSaJen
|
|
veluca
you are wrong 😉 that's what the frame index box is for
|
|
2024-05-07 03:30:35
|
Does that mean it's possible to write a codec that allows any video players to open JXL animations as normal video files? How long can it get?
|
|
|
yoochan
|
2024-05-07 05:11:16
|
You want to make a Trojan horse? Forcing chrome to embed jxl decoder because it's the trending video format to then make them implement the static image decoder because they already have embedded the code? Smart move 😁
|
|
|
|
Quackdoc
|
2024-05-07 05:37:39
|
now that is biggus brainus
|
|
|
HCrikki
|
2024-05-07 05:56:23
|
better use would be conversion of existing gifs to animated jxls. iinm itd be *lossless* and lower sized, whereas other formats are stuck either bloatinf filesize for lossless or losing quality (video codecs dont tend to convert *lossless* video well between formats and colorspaces and even worse with palettized and dithered input)
itd still be preferable converting the source material rather than the gifs themselves naturally, and leave it a video if it was
|
|
|
|
jonnyawsom3
|
2024-05-07 06:14:47
|
Unfortunately it usually requires the highest effort settings to match or barely beat original GIF files currently, pixel art it thrives with the upsampling but that's a niche
|
|
|
Oleksii Matiash
|
|
HCrikki
better use would be conversion of existing gifs to animated jxls. iinm itd be *lossless* and lower sized, whereas other formats are stuck either bloatinf filesize for lossless or losing quality (video codecs dont tend to convert *lossless* video well between formats and colorspaces and even worse with palettized and dithered input)
itd still be preferable converting the source material rather than the gifs themselves naturally, and leave it a video if it was
|
|
2024-05-07 06:37:21
|
In most cases it would not be lower sized, unfortunately
|
|
|
|
HCrikki
|
2024-05-07 07:23:47
|
did you try? curious as almost all my recent checks showed a reduction, from small ad-style slideshows to large 40mb gifs
|
|
2024-05-07 07:24:49
|
perhaps a result of changes about palette/greyscale inputs post 0.10
|
|
|
|
_wb_
|
2024-05-07 07:47:42
|
it depends on the kind of gif, some gifs are optimized in ways that make it hard for jxl to match (e.g. because we load the gif to pixels and lose the palette order, and end up using a worse order)
|
|
|
|
Oleksii Matiash
|
|
HCrikki
did you try? curious as almost all my recent checks showed a reduction, from small ad-style slideshows to large 40mb gifs
|
|
2024-05-07 08:07:35
|
Sure, I tried to convert all my saved gifs to jxl, but most of gifs were already optimized to max, and jxl produced larger files
|
|
|
HCrikki
perhaps a result of changes about palette/greyscale inputs post 0.10
|
|
2024-05-07 08:08:37
|
I stay on 0.9 because it produces slightly smaller files than 0.10+
|
|
|
|
yoochan
|
|
_wb_
it depends on the kind of gif, some gifs are optimized in ways that make it hard for jxl to match (e.g. because we load the gif to pixels and lose the palette order, and end up using a worse order)
|
|
2024-05-07 08:33:34
|
why does the palette order have an impact on size ?and which order should be better ? low indices for higher pixel count ? or something else ?
|
|
|
|
jonnyawsom3
|
|
Oleksii Matiash
I stay on 0.9 because it produces slightly smaller files than 0.10+
|
|
2024-05-07 08:35:19
|
I just have both, with the 0.9 simply being called "cjxl9" instead
|
|
2024-05-07 08:35:35
|
Also have 6, to mess with delta palette
|
|
|
|
_wb_
|
2024-05-07 08:41:45
|
The palette order influences the residuals that end up getting encoded. When using no predictor, you just want low indices for more common colors. But when using predictors, it's complicated — you want colors that often occur together to have indices that are close to one another, and the absolute value of the index matters less. It's a tricky problem and we don't really have any good heuristics for it right now, so we just do basically a luma sort, which is not bad but not great either.
|
|
|
|
yoochan
|
2024-05-07 08:47:07
|
I understand, it's more: closer pixel need regular/predictable differences between consecutive palette indices. Brute force permutation seems too time consuming
|
|
|
monad
|
|
Oleksii Matiash
Sure, I tried to convert all my saved gifs to jxl, but most of gifs were already optimized to max, and jxl produced larger files
|
|
2024-05-07 09:40:37
|
I don't even have time to optimize single-frame gifs to max.
|
|
|
Demiurge
|
|
lonjil
I think Spider Mario's point is that JXL support is less common than hdr h264 support.
|
|
2024-05-07 11:17:30
|
ironically almost no image viewers support HDR jpegxl
|
|
2024-05-07 11:17:45
|
People gotta use thorium for HDR support
|
|
2024-05-07 11:18:35
|
even though jpegxl is an HDR-first format, only SDR is supported in most image viewers
|
|
|
|
Quackdoc
|
|
Demiurge
even though jpegxl is an HDR-first format, only SDR is supported in most image viewers
|
|
2024-05-07 11:38:57
|
indeed, you could have just said almost no image viewers support HDR lol instead of specifying HDR jpegxl
|
|
|
Traneptora
|
|
Demiurge
People gotta use thorium for HDR support
|
|
2024-05-08 11:24:39
|
or mpv
|
|
|
|
Demiurge
|
2024-05-08 11:26:02
|
Does mpv let you view stills?
|
|
|
|
monad
|
|
|
Demiurge
|
2024-05-08 03:08:21
|
I thought it just instantly closed itself when reaching the last frame
|
|
|
|
Orum
|
2024-05-08 03:45:31
|
you can disable that: `keep-open`
|
|
|
|
Demiurge
|
2024-05-08 05:40:22
|
that should probably be the default honestly
|
|
2024-05-08 05:41:05
|
like every other piece of software ever, that isn't being run from the command line
|
|
|
username
huh it seems like newer versions of Firefox with the unmerged JXL patches now properly tonemap HDR images, I assume this is due to some change in newer versions of libjxl?
I'm testing with [r3dfox](https://eclipse.cx/projects/r3dfox.htm) on this page: https://people.csail.mit.edu/ericchan/hdr/hdr-jxl.php
|
|
2024-05-08 11:28:17
|
I'm using Mercury. Are they supposed to look washed out?
|
|
|
username
|
2024-05-08 11:29:14
|
Mercury does not have the unmerged JXL patches
|
|
|
|
Demiurge
|
2024-05-08 11:29:15
|
Wow, they look much better in Thorium
|
|
2024-05-08 11:32:59
|
Yeah, Mercury still has the completely and utterly broken vanilla support
|
|
2024-05-08 11:33:53
|
And for some reason it's packaged as an appimage instead of a flatpak...
|
|
2024-05-08 11:36:06
|
<:ReeCat:806087208678588437>
|
|
|
Crite Spranberry
|
2024-05-08 11:53:45
|
r3dfox <:t_:1088450292095389706>
|
|
2024-05-08 11:53:50
|
Although no tux
|
|
2024-05-08 11:54:06
|
I could probably bother Mercury dev enough to add it since we fwiends
|
|
|
|
VcSaJen
|
|
Demiurge
like every other piece of software ever, that isn't being run from the command line
|
|
2024-05-09 03:49:33
|
mpv is based on MPlayer, which *is* a command-line application.
|
|
|
|
lonjil
|
2024-05-09 05:19:05
|
mpv is pretty command line application too
|
|
2024-05-09 05:19:14
|
Doesn't even have a real GUI
|
|
|
|
Quackdoc
|
2024-05-09 05:21:02
|
mpv's gui is th best gui
|
|
|
|
Orum
|
2024-05-09 06:12:09
|
I really hate how its seekbar doesn't span the width of the window
|
|
|
TheBigBadBoy - 𝙸𝚛
|
|
Orum
I really hate how its seekbar doesn't span the width of the window
|
|
2024-05-09 07:21:42
|
depends on the `--vo`
`xv` (default for X11) doesn't
`gpu-next` does
|
|
|
|
Orum
|
2024-05-09 07:22:15
|
gpu-next was too buggy for me last time I tested it
|
|
|
|
TheBigBadBoy - 𝙸𝚛
|
2024-05-09 07:22:46
|
`gpu` does too (I meant forthe wider seekbar)
|
|
|
|
spider-mario
|
2024-05-09 07:27:30
|
`gpu` works well for me on Windows
|
|
2024-05-09 07:27:36
|
(nvidia)
|
|
|
|
Demiurge
|
2024-05-09 07:31:24
|
mpv has a "real" gui. It runs great as a command line application too. But when it's not running in a terminal, it probably shouldn't automatically disappear and close at the end of a file.
|
|
|
|
TheBigBadBoy - 𝙸𝚛
|
2024-05-09 07:34:37
|
then I would add `keep-open` to my `mpv.conf`
then making an alias in my .bashrc file with `alias mpv='mpv --no-keep-open'`
|
|
|
|
spider-mario
|
2024-05-09 08:07:31
|
I personally prefer keep-open even when I run it from the command line
|
|
|
|
Traneptora
|
|
Demiurge
I'm using Mercury. Are they supposed to look washed out?
|
|
2024-05-10 12:28:17
|
mercury doesn't color manage JXLs correclty
|
|
2024-05-10 12:29:45
|
this is a known issue
|
|
2024-05-10 12:29:46
|
https://github.com/Alex313031/Mercury/issues/51
|
|
|
TheBigBadBoy - 𝙸𝚛
depends on the `--vo`
`xv` (default for X11) doesn't
`gpu-next` does
|
|
2024-05-10 12:31:15
|
`xv` isn ot the defualt for x11, `--vo=gpu` is the default on all platforms, although it may change to `gpu-next` soon
|
|
|
Orum
gpu-next was too buggy for me last time I tested it
|
|
2024-05-10 12:31:28
|
when was that? it's improved dramatically in the past year or two
|
|
|
|
lonjil
|
2024-05-10 12:41:57
|
Sometimes gpu-next is laggy compared to gpu depending on other things going on on the system
|
|
|
|
Quackdoc
|
|
lonjil
Sometimes gpu-next is laggy compared to gpu depending on other things going on on the system
|
|
2024-05-10 12:44:06
|
changing it to ogl can help
|
|
|
|
username
|
|
Traneptora
mercury doesn't color manage JXLs correclty
|
|
2024-05-10 12:46:32
|
this is because Mercury does not use the unmerged JXL patches, newer versions of libjxl (which newer versions of Firefox have by default) when used with the unmerged patches (specifically the color profile support patch) in Firefox result in much better behavior, simply look at how [r3dfox](https://eclipse.cx/projects/r3dfox.htm) handles HDR JXLs to see.
(apologies in possible mistakes of the presentation of this message I have been awake for almost 30 hours straight)
|
|
|
|
Traneptora
|
2024-05-10 12:48:08
|
ah ok
|
|
|
|
TheBigBadBoy - 𝙸𝚛
|
|
Traneptora
`xv` isn ot the defualt for x11, `--vo=gpu` is the default on all platforms, although it may change to `gpu-next` soon
|
|
2024-05-10 07:03:07
|
oh
then it is the default when I disable my dGPU <:KekDog:805390049033191445>
|
|
|
|
Traneptora
|
2024-05-10 02:27:13
|
well yea, if you disable your gpu then that might happen
|
|
|
|
Orum
|
2024-05-11 02:19:53
|
why does `cjxl -d 0 -e 9 -j 0` produce different output with the same image as input, just in different formats?
```
988065 gif.jxl
988128 jpg.jxl
988128 pgm.jxl
988128 png.jxl
988127 ppm.jxl
```
|
|
|
|
Meow
|
2024-05-11 05:25:39
|
If the GIF and PPM files are different already
|
|
|
|
Orum
|
2024-05-11 05:27:14
|
they all decode to the exact same image
|
|
|
|
JendaLinda
|
2024-05-11 06:20:40
|
PPM converts to RGB color.
PGM converts to grayscale.
GIF converts to RGB+Alpha even if there is no transparency.
PNG can be any of them.
JPEG is not guaranteed to decode to the exact same pixels by different software.
|
|
|
|
Meow
|
2024-05-11 06:24:44
|
There should be no Alpha channel for GIF. It just uses one colour as transparency
|
|
|
|
Orum
|
|
JendaLinda
PPM converts to RGB color.
PGM converts to grayscale.
GIF converts to RGB+Alpha even if there is no transparency.
PNG can be any of them.
JPEG is not guaranteed to decode to the exact same pixels by different software.
|
|
2024-05-11 06:26:40
|
Okay, but none of these are an issue in this case, except for possibly the last one. But even if we ignore the jpg, it doesn't explain why the other ones still give different results
|
|
2024-05-11 06:28:11
|
```
ls | xargs -I {} sh -c "printf '{}\t' && convert {} PPM:- | md5sum -"
gif.jxl 6ae88f1550ee7fdda1b4c88377b24558 -
jpg.jxl 6ae88f1550ee7fdda1b4c88377b24558 -
pgm.jxl 6ae88f1550ee7fdda1b4c88377b24558 -
png.jxl 6ae88f1550ee7fdda1b4c88377b24558 -
ppm.jxl 6ae88f1550ee7fdda1b4c88377b24558 -
src.gif 6ae88f1550ee7fdda1b4c88377b24558 -
src.jpg 6ae88f1550ee7fdda1b4c88377b24558 -
src.pgm 6ae88f1550ee7fdda1b4c88377b24558 -
src.png 6ae88f1550ee7fdda1b4c88377b24558 -
src.ppm 6ae88f1550ee7fdda1b4c88377b24558 -
```
|
|
2024-05-11 06:29:36
|
at the very least imagemagick decodes all of these the same way
|
|
|
|
JendaLinda
|
|
Orum
at the very least imagemagick decodes all of these the same way
|
|
2024-05-11 06:31:47
|
Check the jxl files with jxlinfo. They are encoded in different color spaces.
|
|
|
Meow
There should be no Alpha channel for GIF. It just uses one colour as transparency
|
|
2024-05-11 06:32:42
|
GIF is converted from palette to 32 bpp.
|
|
|
|
Orum
|
2024-05-11 06:32:45
|
true, but why does it do that?
```
JPEG XL image, 1774x1331, (possibly) lossless, 8-bit RGB+Alpha
Color space: RGB, D65, sRGB primaries, sRGB transfer function, rendering intent: Perceptual
JPEG XL image, 1774x1331, (possibly) lossless, 8-bit Grayscale
Color space: Grayscale, D65, sRGB transfer function, rendering intent: Perceptual
JPEG XL image, 1774x1331, (possibly) lossless, 8-bit Grayscale
Color space: Grayscale, D65, sRGB transfer function, rendering intent: Perceptual
JPEG XL image, 1774x1331, (possibly) lossless, 8-bit Grayscale
Color space: Grayscale, D65, sRGB transfer function, rendering intent: Relative
JPEG XL image, 1774x1331, (possibly) lossless, 8-bit RGB
Color space: RGB, D65, sRGB primaries, sRGB transfer function, rendering intent: Perceptual
```
|
|
2024-05-11 06:34:52
|
I guess it doesn't figure out that the image is grayscale in some instances, but with -e 9 that seems a bit odd <:Thonk:805904896879493180>
|
|
|
|
JendaLinda
|
2024-05-11 06:35:05
|
PPM is always RGB and PGM is always grayscale. cjxl is keeping the color space of the original format.
The exception is GIF, which is always converted to 32 bpp, RGB+Alpha
|
|
|
|
Orum
|
2024-05-11 06:35:24
|
why is GIF/RGB + Alpha the smallest then?
|
|
2024-05-11 06:36:08
|
and why is RGB smaller than grayscale as well?
|
|
|
|
JendaLinda
|
2024-05-11 06:38:37
|
I don't know. I would expect the opposite as well. Anyway, this is the explanation why the files differ.
|
|
|
|
Orum
|
2024-05-11 06:38:55
|
is there a way to make cjxl's behavior more consistent (regardless of the input format)?
|
|
|
|
JendaLinda
|
2024-05-11 06:40:21
|
Convert everything to PNG and optimize it before converting to JXL.
|
|
|
|
Orum
|
2024-05-11 06:40:54
|
I should have clarified, *within* cjxl's arguments?
|
|
2024-05-11 06:41:31
|
I guess by manually specifying RGB+Alpha for every image, and the rendering intent to be used?
|
|
|
|
JendaLinda
|
2024-05-11 06:42:57
|
RGB+Alpha doesn't have to be always the smallest. It depends on the particular image.
|
|
2024-05-11 06:43:50
|
Modular encoding used by jxl is very complex.
|
|
|
|
Orum
|
2024-05-11 06:44:04
|
yeah, I just noticed that on another image
|
|
|
|
JendaLinda
|
2024-05-11 06:45:50
|
cjxl handles PNG pretty consistently and keeps the original color mode.
|
|
|
|
Orum
|
2024-05-11 06:47:26
|
PNG is slow though, especially when making large, optimized PNGs
|
|
2024-05-11 06:47:38
|
and has other annoyances with the format
|
|
|
|
JendaLinda
|
2024-05-11 06:49:05
|
The optimization is not necessary as long as the PNG uses the appropriate color mode.
|
|
2024-05-11 06:54:10
|
But it's better for the consistent results. Just a fast run through an optimizer is enough to tidy the PNG file. It can even be using zero compression level.
|
|
|
|
Orum
|
2024-05-11 06:55:05
|
I think I'll just continue using what I already am, which is ppm
|
|
2024-05-11 06:55:17
|
at least that can be used for streaming input
|
|
2024-05-11 06:55:32
|
no alpha support though...
|
|
|
|
JendaLinda
|
2024-05-11 06:56:29
|
PAM can be used for alpha
|
|
2024-05-11 07:00:15
|
Portable Arbitrary Map
|
|
|
|
Orum
|
2024-05-11 07:09:21
|
does that still work with streaming input? 🤔
|
|
|
|
JendaLinda
|
2024-05-11 07:34:15
|
I suppose all netpbm formats should be handled the same way. Give it a try and see.
|
|
|
|
jonnyawsom3
|
2024-05-11 09:18:53
|
Only PPM and PGM support streamed inputs currently if I recall https://github.com/libjxl/libjxl/pull/2948
|
|
|
|
JendaLinda
|
2024-05-12 03:37:47
|
That's weird. I thought they were using the same reader.
|
|
|
|
afed
|
2024-05-13 07:13:07
|
would be better if windows switched to jxl for hdr screenshots instead of resurrecting a barely-used unmaintained format <:KekDog:805390049033191445>
https://github.com/mpv-player/mpv/issues/14055
|
|
|
|
Quackdoc
|
|
afed
would be better if windows switched to jxl for hdr screenshots instead of resurrecting a barely-used unmaintained format <:KekDog:805390049033191445>
https://github.com/mpv-player/mpv/issues/14055
|
|
2024-05-13 07:16:08
|
is there any update about windows supporting jxl anyways?
|
|
|
|
afed
|
2024-05-13 07:18:17
|
still the same, but I haven't checked any recent insider builds
|
|
|
|
username
|
2024-05-13 07:19:06
|
when did the JXL stuff first appear in Windows? because it seems like it was an unknown amount of time **before ** anyone found out about it
|
|
|
|
jonnyawsom3
|
2024-05-13 07:51:15
|
We first found it when an SDK update was released with mentions of JXL, then after digging into preview builds we found registy keys already set up for it
|
|
|
|
username
|
2024-05-13 07:53:05
|
thing is after that was found out I saw the registry entries in non-insider builds of Windows 10 which leads me to believe the JXL stuff has been around longer then we think
|
|
|
|
jonnyawsom3
|
|
username
thing is after that was found out I saw the registry entries in non-insider builds of Windows 10 which leads me to believe the JXL stuff has been around longer then we think
|
|
2024-05-13 08:06:39
|
Where did you find those?
|
|
2024-05-13 08:06:49
|
I don't have the registry entry found on Windows 11
|
|
|
|
username
|
2024-05-13 08:10:02
|
on a friend's Windows 10 computer. this was months ago though so I don't remember specifics
|
|
2024-05-13 08:11:28
|
my memory is a bit messed up so it could have been Windows 11....? the only thing I'm 100% certain of is that it was around the same time the registry entries where found out in here and it was on a non-insider build
|
|
|
|
jonnyawsom3
|
2024-05-13 08:14:37
|
Yeah, it's on non-insider Windows 11 builds, just manually seached my Windows 10 registry and nothing stuck out to me
|
|
|
Jyrki Alakuijala
|
|
username
how complete is jpegli in it's current state?
|
|
2024-05-15 05:44:31
|
now it is reasonably complete and can be integrated into production software 😄 Just many existing software has difficulty with the --xyb variation so use the --xyb with caution...
|
|
|
|
jonnyawsom3
|
2024-05-15 06:06:42
|
Well, there's a few merged PRs that fix encoding/decoding errors but aren't in a release yet, so maybe on the next version it's ready ;P
|
|
|
|
Jyrki Alakuijala
|
2024-05-16 10:45:27
|
possibly better to use jpegli from the head
|
|
2024-05-16 10:45:43
|
we will move it to a different repo for clarity
|
|
|
|
afed
|
|
Jyrki Alakuijala
we will move it to a different repo for clarity
|
|
2024-05-16 10:53:21
|
yeah, also jpegli is still not easy to use and compile out of the box as a separate library, also with or without compatibility with simple compilation flags
like zlib-ng for example
<https://github.com/zlib-ng/zlib-ng>
|
|
|
|
jonnyawsom3
|
2024-05-16 02:34:33
|
On a random note, I only just realised the roles are green rather than the JXL teal being used anywhere
|
|
|
|
lonjil
|
2024-05-16 03:28:53
|
jxl teal would probably have bad contrast against the dark mode background
|
|
|
|
jonnyawsom3
|
|
Meow
There should be no Alpha channel for GIF. It just uses one colour as transparency
|
|
2024-05-16 03:30:06
|
Couldn't be much worse than the low level roles
|
|
|
|
afed
|
|
Jyrki Alakuijala
we will move it to a different repo for clarity
|
|
2024-05-16 03:44:32
|
and it will also help to make this, which is very useful
https://discord.com/channels/794206087879852103/804324493420920833/1233323954685480980
|
|
|
|
lonjil
|
2024-05-21 10:31:25
|
What strategies does JXL use to avoid boundary artifacts between groups?
|
|
|
|
_wb_
|
2024-05-21 11:17:16
|
Mostly the fact that gaborish and epf are done across group boundaries...
|
|
|
|
lonjil
|
2024-05-21 11:22:45
|
ah, yes, epf is what I had forgotten, I knew there was something more than gaborish
|
|
|
LMP88959
|
2024-05-21 04:24:32
|
im curious, i've had not-so-great experiences with trying post processing filters like that
|
|
2024-05-21 04:24:58
|
mostly because it seems to remove detail that was originally part of the image which happens to unfortunately look like something the filter was designed to remove
|
|
2024-05-21 04:26:14
|
how does JXL manage to get around this, if it does
|
|
|
|
yoochan
|
2024-05-21 06:11:35
|
Gaborish inverse is applied before the encoding, as a sharpening pass meant to be (almost) exactly canceled out by the decoding "forward" Gaborish filter while reducing block boundary effects
|
|
2024-05-21 06:12:28
|
Don't know how epf works, but if it is real some kind of bilateral filtering it smooth without blurring
|
|
|
|
LMP88959
|
2024-05-21 06:20:53
|
ah so the Gaborish inverse helps emphasize actual detail so that it can be distinguished from compression artifacts?
|
|
|
|
jonnyawsom3
|
2024-05-21 06:51:27
|
Both are applied during/before encoding, so it uses the data already there rather than trying to just make it look 'nice'
|
|
|
|
LMP88959
|
2024-05-21 07:02:24
|
wouldnt a filter like that increase entropy?
|
|
2024-05-21 07:02:43
|
sharpening filters in general seem to increase entropy
|
|
2024-05-21 07:03:09
|
what is different about the Gaborish (sorry im not well versed in this technology)
|
|
|
|
yoochan
|
2024-05-21 07:09:53
|
If I understood well, the idea was to emulate overlapping blocks encoding without really overlapping them... inverse gaborish / forward gaborish should be an identity transformation, I don't know much about entropy in this case
|
|
|
|
LMP88959
|
2024-05-21 07:10:32
|
🤔 ah so is it only applied to block boundaries?
|
|
|
|
lonjil
|
2024-05-21 07:14:33
|
no, it's across the entire image
|
|
2024-05-21 07:14:50
|
but as noted, the filter is losslessly invertible
|
|
|
|
LMP88959
|
2024-05-21 07:15:10
|
okay thank you. i'll need to go read up on it
|
|
|
|
lonjil
|
|
lonjil
but as noted, the filter is losslessly invertible
|
|
2024-05-21 07:16:09
|
that's not entirely true, I think, since there will be some rounding errors from not using Real numbers, but float32 should be precise enough for that to not matter much.
|
|
2024-05-21 07:16:56
|
and ofc, if you're doing lossy encoding, you have another step between inverse gaborish, and gaborish, so you cannot get the same stuff back out :)
|
|
2024-05-21 07:18:31
|
<@723252970657022053> here is what it does on decoding:
> J.3 Gabor-like transform
>
> In this subclause, C denotes x, y, or b according to the channel currently being processed. The decoder applies a convolution to each channel of the entire image with the following symmetric 3×3 kernel: the unnormalized weight for the center is 1, its four neighbours (top, bottom, left, right) are restoration_filter.gab_C_weight1 and the four corners (top-left, top-right, bottom-left, bottom-right) are restoration_filter.gab_C_weight2. These weights are rescaled uniformly before convolution, such that the nine kernel weights sum to 1.
>
> When the convolution references input pixels with coordinates cx, cy outside the bounds of the original image, the decoder instead accesses the pixel at coordinates Mirror(cx, cy) (5.2).
|
|
|
|
LMP88959
|
2024-05-21 07:19:30
|
so it's just a 3x3 convolution?
|
|
|
|
_wb_
|
2024-05-21 07:19:44
|
Gaborish does sharpening pre encode to compensate for the smoothing post decode. It is a relatively low amplitude smoothing (at least with the default weights, which is what libjxl uses), decode side with only a 3x3 kernel.
|
|
2024-05-21 07:20:37
|
Yes, the decoder side of Gaborish is just a 3x3 convolution, more or less just an approximate slight Gaussian blur I guess
|
|
|
|
LMP88959
|
2024-05-21 07:20:57
|
🤔
|
|
2024-05-21 07:21:06
|
so it _would_ increase entropy on the encoding side yes?
|
|
|
|
lonjil
|
2024-05-21 07:21:09
|
presumably related to <https://en.wikipedia.org/wiki/Gabor_filter> in some way
|
|
|
|
_wb_
|
2024-05-21 07:22:05
|
It does increase entropy on the encode side, yes — some edge information from neighboring blocks gets pulled in, so to speak.
|
|
|
|
LMP88959
|
2024-05-21 07:22:27
|
alright, but im guessing the benefits of using it outweigh that increase in entropy?
|
|
|
|
_wb_
|
2024-05-21 07:23:48
|
Entropy gets quantized away anyway, you just do it some more when using Gaborish. And yes, the benefits do outweigh the cost.
|
|
|
|
LMP88959
|
2024-05-21 07:24:09
|
Ohh good point
|
|
2024-05-21 07:24:16
|
Ok. thank you for the explanation
|
|
|
|
_wb_
|
2024-05-21 07:24:48
|
Gaborish is basically an alternative way to do lapped transforms but in a computationally cheaper way
|
|
|
|
yoochan
|
2024-05-21 07:25:57
|
lapped ! I was looking for the exact word
|
|
|
|
LMP88959
|
2024-05-21 07:26:02
|
That makes sense, im assuming something like the deblocking filter found in many video codecs would be insufficient in the case of a still image coder?
|
|
2024-05-21 07:26:38
|
well, the deblocker doesnt preserve any source information
|
|
2024-05-21 07:26:44
|
it just makes the result look more pleasing
|
|
|
|
lonjil
|
2024-05-21 07:28:52
|
epf seems a good deal more complex. what kind of edge preserving filter is it based on?
|
|
|
|
yoochan
|
2024-05-21 07:29:35
|
bilateral if I remember correctly
|
|
|
|
_wb_
|
2024-05-21 07:30:02
|
EPF (edge preserving filter) is similar to a bilateral filter: it preserves detail but can smooth out some DCT noise. It has a strength that is signalled at 1:8 resolution, so an encoder has quite fine grained control over it. This helps to avoid the problem that e.g. avif has: there the deblocking filter strength is signalled at 1:64 resolution so you tend to see macroblocks where the edge is between a lot of smoothing and less smoothing. Also video codecs typically use cheap separable filters easy to implement in hardware, while EPF is more complex but also more subtle.
|
|
|
|
lonjil
|
|
heilige_antonius
|
2024-05-21 09:43:26
|
any tips on cjxl parameters on converting photo library to jxl? currently using cjxl 7, 9 or 10 input.jpg out.jxl
|
|
|
|
monad
|
|
any tips on cjxl parameters on converting photo library to jxl? currently using cjxl 7, 9 or 10 input.jpg out.jxl
|
|
2024-05-21 11:11:37
|
lossy or lossless? are they jpeg?
|
|
|
|
heilige_antonius
|
|
monad
lossy or lossless? are they jpeg?
|
|
2024-05-22 01:24:21
|
jpg
lossless
i thought you would know cuz i asked at the end of my sentence what effort to use
|
|
|
|
jonnyawsom3
|
2024-05-22 01:26:45
|
Generally going above 7 on jpeg transcoding only shaves a few hundred bytes off to a kilobyte or two, while making it spend exponentially more time and memory
|
|
|
|
monad
|
|
jpg
lossless
i thought you would know cuz i asked at the end of my sentence what effort to use
|
|
2024-05-22 04:54:34
|
Then it is straightforward to just use the default. Higher efforts probably lose you money.
|
|
2024-05-22 04:56:44
|
|
|
2024-05-22 05:00:44
|
`--brotli_effort 6` performed best on this sample, but the effect is insignificant
|
|
|
|
Orum
|
2024-05-22 05:17:58
|
I always forget that lossless jpeg exists
|
|
|
|
heilige_antonius
|
|
monad
Then it is straightforward to just use the default. Higher efforts probably lose you money.
|
|
2024-05-22 08:09:37
|
so just cjxl in.jpg out.jxl
|
|
|
|
monad
|
2024-05-22 09:39:40
|
yes, bearing in mind `--num_threads 0` if you're transcoding multiple images in parallel.
```?! Mpx/s real (mean)
| Pareto front for bpp and CPU time
| |Pareto front for bpp and real time
B bpp (mean) Mpx/s CPU (mean)|| best of
132381553 2.36628557 39.725 39.723 C· cjxl_0.10.2_e7num_threads0
132381553 2.36628557 31.252 57.68 ·R cjxl_0.10.2_e7```
|
|
|
|
Demiurge
|
|
_wb_
EPF (edge preserving filter) is similar to a bilateral filter: it preserves detail but can smooth out some DCT noise. It has a strength that is signalled at 1:8 resolution, so an encoder has quite fine grained control over it. This helps to avoid the problem that e.g. avif has: there the deblocking filter strength is signalled at 1:64 resolution so you tend to see macroblocks where the edge is between a lot of smoothing and less smoothing. Also video codecs typically use cheap separable filters easy to implement in hardware, while EPF is more complex but also more subtle.
|
|
2024-05-23 12:43:44
|
Is it complex enough to give third party re-implementers a hard time?
|
|
|
|
Jyrki Alakuijala
|
|
yoochan
Gaborish inverse is applied before the encoding, as a sharpening pass meant to be (almost) exactly canceled out by the decoding "forward" Gaborish filter while reducing block boundary effects
|
|
2024-05-23 01:03:34
|
That is the idea. It is also similar to dolby b/dolby c -- one can consider block boundary artefacts as high frequency noise, and emphasizing the high frequencies in the signal at recording time and de-emphasizing at playback time reduces all high frequency noise, too
|
|
2024-05-23 01:05:37
|
it would also work for usual JPEG rendering
|
|
2024-05-23 01:06:22
|
when I was playing with this idea originally, we developed knusperli soon after
|
|
2024-05-23 01:07:20
|
in knusperli I did the sharpening (inverse gaborish) by just changing the quantization matrix before decoding, and then using the 3x3 convolution on the pixels
|
|
2024-05-23 01:08:16
|
it creates some more artefacts at block boundaries than a more disciplined approach, but all those artefacts are towards smoothing, and in usual photographs the blocking artefacts are clearly reduced
|
|
2024-05-23 01:09:20
|
one can also think that it relates to the overlapping transforms -- but without actually making the description overcomplete (overcomplete descriptions are ineffective both for entropy and for decoding speed)
|
|
|
|
_wb_
|
|
Demiurge
Is it complex enough to give third party re-implementers a hard time?
|
|
2024-05-23 01:48:38
|
It's not _that_ complex in terms of implementation, I mostly meant EPF is computationally a bit more expensive and likely a bit harder to implement in hardware than the typical filters used in video codecs.
|
|
|
|
Demiurge
|
2024-05-24 11:36:35
|
<@387462082418704387> personally I use the file extension .jxll for lossless and .jjxl for jpeg. Also... what sort of scripting language is that?
```
ls *.jxl | % {
djxl $_ temp.png
cjxl -m temp.png "$($_.Basename)x.jxl"
ri temp.png
}
```
|
|
2024-05-24 11:37:16
|
Is that powershell? I'm a bourne/korn shell user so idk
|
|
|
dogelition
|
|
Demiurge
Is that powershell? I'm a bourne/korn shell user so idk
|
|
2024-05-24 11:50:33
|
chatgpt says it is indeed powershell
(it's very useful for questions like this that are nearly impossible to google, but easy to answer if you've seen it before)
|
|
|
|
Demiurge
|
2024-05-24 12:04:09
|
Never heard of ri as an alias for rm or del
|
|
|
|
dogelition
|
2024-05-24 12:08:35
|
me neither, but it stands for `Remove-Item`
|
|
|
|
Demiurge
|
2024-05-24 12:10:10
|
Ah yeah that sounds very powershell
|
|
2024-05-24 12:10:44
|
Far as I'm concerned Korn is the perfect shell
|
|
|
|
TheBigBadBoy - 𝙸𝚛
|
2024-05-24 12:53:27
|
do you prefer it over BASH ?
I mean, Idk the differences <:KekDog:805390049033191445>
|
|
|
|
yoochan
|
2024-05-24 12:54:25
|
big fan of zsh personnally
|
|
|
w
|
2024-05-24 12:54:30
|
i like fish
|
|
|
|
yoochan
|
2024-05-24 12:54:41
|
do you use it daily ?
|
|
|
|
w
|
2024-05-24 12:55:00
|
yes
|
|
2024-05-24 12:55:13
|
use it at work, autocomplete features very helpful
|
|
|
|
yoochan
|
2024-05-24 12:55:41
|
and the revamped syntax looks neat
|
|
2024-05-24 12:56:07
|
properly configured (like in manjaro) zsk autocompletion is also turbocharged
|
|
|
eddie.zato
|
|
Demiurge
<@387462082418704387> personally I use the file extension .jxll for lossless and .jjxl for jpeg. Also... what sort of scripting language is that?
```
ls *.jxl | % {
djxl $_ temp.png
cjxl -m temp.png "$($_.Basename)x.jxl"
ri temp.png
}
```
|
|
2024-05-24 07:13:31
|
Yep, it's pwsh. As I mention earlier, I use the exif comment to indicate what type of encoding is used. Different extensions aren't a very convenient method in my opinion.
|
|
2024-05-24 07:16:22
|
Also `jxlinfo` is good enough.
https://github.com/libjxl/libjxl/issues/432#issuecomment-2122017318
|
|
|
|
Demiurge
|
|
TheBigBadBoy - 𝙸𝚛
do you prefer it over BASH ?
I mean, Idk the differences <:KekDog:805390049033191445>
|
|
2024-05-25 03:23:36
|
Bash is actually a Korn shell clone, but with much worse performance. It has like 2 or 3 original features and the rest were copied exactly from Korn. The syntax is compatible.
|
|
2024-05-25 03:25:12
|
GNU tends to have slower and more bloated versions of everything, compared to what it's trying to copy
|
|
2024-05-25 03:26:12
|
Basically it's pretty hard to tell the difference between ksh and bash.
|
|
2024-05-25 03:28:13
|
I don't really understand what the deal is with zsh personally.
|
|
|
|
TheBigBadBoy - 𝙸𝚛
|
2024-05-25 06:48:57
|
I should try it, I've been using BASH daily for 2+ years
for scripts it has really nice features, but as an interactive terminal I think it's… too simple
|
|
|
|
yoochan
|
|
Demiurge
I don't really understand what the deal is with zsh personally.
|
|
2024-05-25 09:20:08
|
appart from the default tab behavior (which is nice, with auto completion, auto correction and one-tab-press-suggestion) its syntax regarding path handling is so clean!
To get the resolved absolute directory which contains the file I just sourced : `root_dir=${0:A:h}` try to do this without ugly bloats in bash.
Also, try to clean the $PATH (removing duplicates while conserving order) with bash, in zsh `typeset -U PATH` done !
|
|
|
|
Demiurge
|
|
TheBigBadBoy - 𝙸𝚛
I should try it, I've been using BASH daily for 2+ years
for scripts it has really nice features, but as an interactive terminal I think it's… too simple
|
|
2024-05-25 10:12:25
|
Well like I said ksh and bash are very similar so if you think bash is too simple you'll think ksh is too.
|
|
|
|
lonjil
|
2024-05-25 10:20:28
|
bash I'm pretty sure is mostly a Bourne shell clone, with a few features from Korn and C shell
|
|
|
|
Jyrki Alakuijala
|
2024-05-25 11:06:06
|
Any analysis or other feelings on recent (last two months) quality improvements?
|
|
|
|
yoochan
|
2024-05-25 11:09:35
|
Not yet but i'll have a look. Could you write some key commits to be compared against?
|
|
|
|
Jyrki Alakuijala
|
|
_wb_
Gaborish does sharpening pre encode to compensate for the smoothing post decode. It is a relatively low amplitude smoothing (at least with the default weights, which is what libjxl uses), decode side with only a 3x3 kernel.
|
|
2024-05-25 11:09:55
|
It is not Gaussian as it is not axis separable. It is something I iterated with: what looked best to my eyes. It is very much 'ad hoc' without a lot of theory.
|
|
2024-05-25 11:12:11
|
The naming is inspired from a log Gabor experiment that Zoltan did around 2018, log Gabor looked very very beautiful but wasn't competitive in entropy. Degraded images looked "analog" like old photos.
|
|
2024-05-25 11:12:59
|
Iirc, I came up with the gaborish idea around 2016 or 17
|
|
2024-05-25 11:13:39
|
Before the log Gabor experiment, not sure if the name existed before or not
|
|
2024-05-25 11:14:02
|
Of course dct+blur is far from Gabor functions
|
|
|
|
_wb_
|
2024-05-25 11:52:31
|
The default convolution kernel of (dec-side) Gaborish does have the same general shape as a 3x3 Gaussian, no? The actual weights are different but it's still a kind of blur, just not exactly a Gaussian one. Closer to Gaussian than to, say, a box filter or something.
|
|
|
|
TheBigBadBoy - 𝙸𝚛
|
|
Demiurge
Well like I said ksh and bash are very similar so if you think bash is too simple you'll think ksh is too.
|
|
2024-05-25 12:34:46
|
oh, I thought "Korn shell" = ksh <:KekDog:805390049033191445>
|
|
|
|
lonjil
|
|
TheBigBadBoy - 𝙸𝚛
oh, I thought "Korn shell" = ksh <:KekDog:805390049033191445>
|
|
2024-05-25 12:36:36
|
it is
|
|
|
|
TheBigBadBoy - 𝙸𝚛
|
2024-05-25 12:37:55
|
https://cdn.discordapp.com/emojis/654081052108652544.png?quality=lossless&size=48
|
|
2024-05-25 12:38:26
|
ok I just understood what he meant lol
|
|
|
|
w
|
2024-05-25 12:50:53
|
you should try fish
|
|
|
|
eddie.zato
|
|
Jyrki Alakuijala
Any analysis or other feelings on recent (last two months) quality improvements?
|
|
2024-05-25 01:19:50
|
I tried to compare v0.10.2 and the latest main + pr3563. At 100 generations the second one showed a little less degradation. At 900, the same thing. So, I didn't make a video. <:Thonk:805904896879493180>
|
|
|
|
Demiurge
|
2024-05-25 01:59:48
|
Is there any good photographs with lots of details and texture in dark and shaded regions? I notice in the past jpegxl struggles with that. That and mangling color
|
|
|
|
Oleksii Matiash
|
|
Demiurge
Is there any good photographs with lots of details and texture in dark and shaded regions? I notice in the past jpegxl struggles with that. That and mangling color
|
|
2024-05-25 02:45:21
|
Not good, but details and texture are there, I believe. If it can be used I can share the raw
|
|
|
|
w
|
2024-05-25 02:48:31
|
just take a picture of the floor
|
|
|
|
Demiurge
|
2024-05-25 03:09:37
|
Preferably an outdoor scene with a mix of brightly lit areas and dark shaded areas with details and texture in both
|
|
2024-05-25 03:10:52
|
Like for example a marble statue in direct sunlight with lots of texture in the shaded regions
|
|
2024-05-25 03:12:49
|
The type of deep dark shading and contrast you get when you have shadow casting in direct sunlight
|
|
2024-05-25 03:14:07
|
in my experience libjxl lossy has always had a problem with preserving texture in such dark shaded regions
|
|
2024-05-25 03:14:33
|
Excessive ugly blurring
|
|
2024-05-25 03:22:08
|
I suggested this earlier but, the human eye is less sensitive to blue noise compared to other artifacts like blur. If libjxl could be tuned to produce artifacts similar to blue noise, it would be a big improvement in human testing (and likely a big decrease in objective metrics that are bad at understanding human perception)
|
|
2024-05-25 03:27:48
|
Like for example, lossy pngquant does a great job of preserving detail and fidelity using dithering and clever and thoughtful color quantization. Dithering patterns are similar to blue noise and they naturally blend into most images in a way that's hard to tell if they were added or always there.
|
|
2024-05-25 03:29:04
|
Blurring on the other hand, always stands out as obvious and cliched signs of "bad compression."
|
|
2024-05-25 03:29:24
|
Especially when it's applied unevenly
|
|
|
A homosapien
|
|
Jyrki Alakuijala
Any analysis or other feelings on recent (last two months) quality improvements?
|
|
2024-05-26 10:15:37
|
Here are my thoughts: https://github.com/libjxl/libjxl/issues/3530#issuecomment-2132164263
|
|
|
|
Demiurge
|
2024-05-26 10:51:10
|
The TF2 image is great. Always trust your eyes, not your brain. And definitely not metrics. Looking at metrics instead of going in blind can bias your perception and trick your brain
|
|
2024-05-26 10:51:37
|
Blind testing is the gold standard
|
|
2024-05-26 10:54:31
|
Blind = you just have sample A and sample B without knowing which one is which until after the test
|
|
|
|
A homosapien
|
2024-05-26 11:14:24
|
Yeah only using metrics was a rookie mistake 😅
|
|
2024-05-26 07:06:51
|
Nevertheless, I first found out about the regression by testing the TF2 images and comparing them visually.
|
|
2024-05-26 07:08:24
|
I just relied too heavily on metrics to show my point.
|
|
|
|
Demiurge
|
2024-05-26 11:20:38
|
Yeah, the tf2 image is a great test image. The difference is really striking
|
|
2024-05-26 11:23:02
|
I think I mentioned a long time ago that 0.10 regressed a lot in terms of quality. Particularly when looking here: https://afontenot.github.io/image-formats-comparison
|
|
2024-05-26 11:24:11
|
That comparison makes jpegxl look really really bad, mostly because of regressions
|
|
2024-05-26 11:24:59
|
especially with mangling color
|
|
|
|
A homosapien
|
2024-05-27 02:01:38
|
Yeah, I don't know if it was the heuristics or gaborish, but there was something wrong
|
|
2024-05-27 02:01:58
|
Thankfully it seems to have been mostly fixed
|
|
|
|
Demiurge
|
2024-05-27 06:45:25
|
Fixed? I just did a test right now with the latest git. Colors still look extremely dull and washed out.
|
|
2024-05-27 06:45:44
|
|
|
2024-05-27 06:46:06
|
It's much worse than most other formats at the same 1bpp bitrate
|
|
2024-05-27 06:47:06
|
jpegxl used to excel at this compared to other formats and now it's the worst
|
|
2024-05-27 06:47:46
|
It's kinda crazy how it's even possible for it to regress this badly
|
|
2024-05-27 06:51:57
|
It would be nice to see what it looks like encoded with v0.8 for comparison. I don't ever remember JXL being this much worse than other codecs though
|
|
|
|
yoochan
|
2024-05-27 07:11:18
|
could you post the original, I would like to test your claims 😄 what quality was it to reach 1bpp ?
|
|
|
|
Demiurge
|
2024-05-27 08:10:08
|
That PNG up there is the original. I used d=2.5 to reach 1bpp with the latest dev version
|
|
2024-05-27 08:10:37
|
https://github.com/xooyoozoo/yolo-octo-bugfixes/blob/gh-pages/comparisonfiles/Original/Abandoned_Packard_Automobile_Factory_Detroit_200.png
|
|
2024-05-27 08:15:47
|
Idk if it's just my special colorblind eyes but personally I was pretty shocked when I saw how bad 0.10 was compared to older comparisons
|
|
|
|
yoochan
|
2024-05-27 08:21:39
|
interesting ! I'll do a comparison on this specific image ! what type of color blindness ?
|
|
|
|
A homosapien
|
2024-05-27 08:40:50
|
The slightly washed out colors (the leaves specifically) were always present in all versions I tested (master, 0.10, 0.8, and 0.6). However, 0.10 had issues with chroma so it's not surprising that the colors got even more washed out, but now it's back to normal jxl levels I guess.
https://github.com/libjxl/libjxl/pull/3520
|
|
|
Demiurge
Fixed? I just did a test right now with the latest git. Colors still look extremely dull and washed out.
|
|
2024-05-27 08:46:36
|
I was specifically mentioning the issues with excess chroma noise and color banding, which were indeed fixed. The colors being slightly washed out is just kind of a jxl quirk on this specific image I guess. I didn't encounter this kind of problem on any other images I have tested on.
|
|
|
|
Demiurge
|
|
yoochan
interesting ! I'll do a comparison on this specific image ! what type of color blindness ?
|
|
2024-05-27 10:38:56
|
Deutanomaly
|
|
2024-05-27 10:39:08
|
Slight
|
|
|
A homosapien
I was specifically mentioning the issues with excess chroma noise and color banding, which were indeed fixed. The colors being slightly washed out is just kind of a jxl quirk on this specific image I guess. I didn't encounter this kind of problem on any other images I have tested on.
|
|
2024-05-27 10:40:39
|
On the image comparison page I noticed it on several images but it's most strikingly obvious on this one
|
|
2024-05-27 10:41:01
|
Never noticed it before on previous JXL comparisons
|
|
2024-05-27 10:42:02
|
No other codec destroys the colors so badly, either
|
|
2024-05-27 10:59:31
|
Honestly the biggest strengths of jxl are its lossless mode. It would be much easier and more impactful to optimize lossless or near-lossless encoding, where jxl easily shines. At least getting it on par with webp would be enough.
|
|
2024-05-27 11:00:30
|
But in my experience it's still not at the pareto front unfortunately, despite the optimistic article...
|
|
2024-05-27 11:03:01
|
Also, I would argue that lossless encoding ought to be the default, since it makes more sense from a user-expectations point of view.
|
|
2024-05-27 11:03:26
|
Not only for gif and jpeg but for all input
|
|
|
|
yoochan
|
2024-05-27 11:03:46
|
I'm not colorblind but I'm absolutely unable to spot a difference in the blue of the sky 🧐
|
|
2024-05-27 11:05:13
|
But I plotted some graphs...
|
|
|
|
Demiurge
|
2024-05-27 11:05:15
|
Intentionally degrading an image ought to be an opt-in feature, especially since lossless mode often produces smaller files too.
|
|
|
yoochan
I'm not colorblind but I'm absolutely unable to spot a difference in the blue of the sky 🧐
|
|
2024-05-27 11:06:03
|
You won't see a difference looking there. Look at the colorful foliage.
|
|
|
|
yoochan
|
2024-05-27 11:07:44
|
yellow leaves or green leaves ?
|
|
|
|
Demiurge
|
2024-05-27 11:07:45
|
I still think the default effort setting for lossless mode should be faster too. Closer to e=3 or 4
|
|
|
yoochan
yellow leaves or green leaves ?
|
|
2024-05-27 11:07:59
|
Yellow and red
|
|
2024-05-27 11:08:15
|
I am bad at seeing green apparently
|
|
|
|
yoochan
|
2024-05-27 11:08:23
|
ok, I can't look now, but I'll check it
|
|
|
|
Demiurge
|
2024-05-27 11:08:58
|
I have a harmful mutation in my green cones
|
|
2024-05-27 11:09:13
|
So I see slightly less green than normal.
|
|
|
|
A homosapien
|
2024-05-27 11:15:32
|
Btw, does anybody know what lossy e10 does compared to e9? The documentation is still outdated...
|
|
2024-05-27 11:16:06
|
The only information I could find is that streaming mode is disabled on e10.
|
|
|
|
monad
|
|
A homosapien
Btw, does anybody know what lossy e10 does compared to e9? The documentation is still outdated...
|
|
2024-05-28 12:04:58
|
One difference is e9 tries gradient and weighted predictors, e10 tries all except prev channel predictors for MA trees.
|
|
|
|
Demiurge
|
2024-05-28 04:51:11
|
I took the original file from wikimedia, downscaled it in linear light mode and saved it as 8-bit RGB.
|
|
2024-05-28 04:51:44
|
effort=3 and effort=9 are the same size btw. And e=3 encodes AND decodes much, much faster. I really think 3 or 4 ought to be the default for lossless mode. And lossless mode ought to be the default for all files.
|
|
2024-05-28 04:52:36
|
People will be very impressed with the speed if the default speed was much faster.
|
|
2024-05-28 04:53:15
|
Anyways here's the same file after being compressed at e=7 d=2.5
|
|
2024-05-28 06:28:50
|
By comparison, PIK doesn't seem to have the same problem here in this comparison https://wyohknott.github.io/image-formats-comparison/#abandonned-factory&png=m&pik=s
|
|
2024-05-28 06:29:39
|
Even though the jpegxl source tree is derived from pik
|
|
|
|
A homosapien
|
|
monad
One difference is e9 tries gradient and weighted predictors, e10 tries all except prev channel predictors for MA trees.
|
|
2024-05-28 07:09:33
|
I wanted to know more about the lossy mode specically, I already know that about Modular. VarDCT e9 it just does more Butteraugli iterations. Is it the same with e10?
|
|
|
Demiurge
By comparison, PIK doesn't seem to have the same problem here in this comparison https://wyohknott.github.io/image-formats-comparison/#abandonned-factory&png=m&pik=s
|
|
2024-05-28 07:49:32
|
~~I disagree, PIK also has a slight color desaturation at lower bbp.~~
|
|
2024-05-28 08:28:30
|
The more testing I do, the more I think this is an deliberate decision by the encoder. I see desaturation at distances as low as 1. I understand that altering colors for the sake of compression is important, but I think its overtuned imo. Granted, this only happens to very vibrant colors.
|
|
2024-05-28 08:47:59
|
|
|
|
|
Demiurge
|
2024-05-28 08:49:51
|
Yes, it's a problem with the psycho tuning of the encoder. And the desaturation is really hard to notice in PIK. It obviously became a lot worse in recent versions of jpegxl.
|
|
2024-05-28 08:52:40
|
It wasn't so bad when the infamous Bankowski "Chrome Codec Team" AVIF comparison was done. Here are some images from that comparison:
|
|
2024-05-28 08:52:55
|
https://storage.googleapis.com/avif-comparison/images/subset1/sample_images/2011-03-05_03-13_Madeira_159_Funchal__Mercado_dos_Lavradores.png-s-6_0.93bpp.avif.png
|
|
2024-05-28 08:52:57
|
https://storage.googleapis.com/avif-comparison/images/subset1/sample_images/2011-03-05_03-13_Madeira_159_Funchal__Mercado_dos_Lavradores.png-s-7_0.93bpp.jxl.png
|
|
2024-05-28 08:53:21
|
https://storage.googleapis.com/avif-comparison/images/Kodak/sample_images/kodim14.png-s-5_0.91bpp.avif.png
https://storage.googleapis.com/avif-comparison/images/Kodak/sample_images/kodim14.png-s-8_0.94bpp.jxl.png
|
|
|
|
A homosapien
|
|
Demiurge
It wasn't so bad when the infamous Bankowski "Chrome Codec Team" AVIF comparison was done. Here are some images from that comparison:
|
|
2024-05-28 09:02:49
|
Interesting, I wonder when this regression happened. I can only test as far back as 0.6. Has there been an issue made about this regression yet?
|
|
|
|
Jyrki Alakuijala
|
2024-05-28 09:08:41
|
I'll take a look ♥️
|
|
2024-05-28 09:09:11
|
Thank you for being frank and with opinions, this is how we can improve (or recover)
|
|
2024-05-28 09:09:42
|
It would be amazing to know when this happened
|
|
2024-05-28 09:10:08
|
That would naturally help devising a fix 😅
|
|
|
|
lonjil
|
2024-05-28 09:10:55
|
Guess it's bisection time
|
|
|
|
Jyrki Alakuijala
|
2024-05-28 09:11:38
|
In pik we only have 8x8 dct and all focus was at good performance at 1-1.5 bpp
|
|
2024-05-28 09:11:48
|
It was simple and worked
|
|
2024-05-28 09:12:32
|
The jpeg committee asked competitive performance down to 0.06 bpp, and we had no chance of delivering it without huge complications
|
|
2024-05-28 09:13:03
|
Even 0.25 bpp was a huge struggle for pik
|
|
2024-05-28 09:13:28
|
Because of it variable dct sizes were added
|
|
2024-05-28 09:13:59
|
That removed some very nice optimizations that were possible in pik
|
|
|
|
Demiurge
|
|
Jyrki Alakuijala
The jpeg committee asked competitive performance down to 0.06 bpp, and we had no chance of delivering it without huge complications
|
|
2024-05-28 09:14:23
|
0.06 bbp is utter nonsense though
|
|
|
|
Jyrki Alakuijala
|
2024-05-28 09:14:23
|
The more advanced frequency lifting for example
|
|
2024-05-28 09:14:32
|
It is utter nonsense
|
|
|
|
Demiurge
|
2024-05-28 09:14:32
|
That's like a grey splotch
|
|
2024-05-28 09:14:45
|
Or more like a grey blur
|
|
|
|
Jyrki Alakuijala
|
2024-05-28 09:15:08
|
But it was in the requirements specification deviced by ISO
|
|
|
|
Demiurge
|
2024-05-28 09:15:29
|
Death by committee
|
|
|
|
Jyrki Alakuijala
|
2024-05-28 09:15:36
|
It was not our negotiation
|
|
|
|
lonjil
|
2024-05-28 09:15:42
|
<@1028567873007927297> do you know a version of libjxl that had good color in that image?
|
|
|
|
Jyrki Alakuijala
|
2024-05-28 09:15:55
|
JPEG AI suffers from same kind of thinking
|
|
2024-05-28 09:16:22
|
Their chair limited comparison to less than 0.75 bpp
|
|
|
|
Demiurge
|
|
lonjil
<@1028567873007927297> do you know a version of libjxl that had good color in that image?
|
|
2024-05-28 09:16:28
|
I can try to do some testing... It's a really good test image for this problem
|
|
|
|
Jyrki Alakuijala
|
2024-05-28 09:16:39
|
"industry wants quality to go down"
|
|
|
|
username
|
|
Jyrki Alakuijala
In pik we only have 8x8 dct and all focus was at good performance at 1-1.5 bpp
|
|
2024-05-28 09:17:24
|
was this for early pik or for the encoder? because the GitHub page for PIK seems to imply it supports DCT sizes of 4x4 to 32x32
|
|
|
|
Jyrki Alakuijala
|
2024-05-28 09:18:01
|
Yes, before we started in jpeg competition
|
|
2024-05-28 09:18:43
|
I think pik peaked in quality in 2018 April or May
|
|
2024-05-28 09:19:46
|
Fitting jpeg xl requirements made it worse at what it was very good at (1.6 bpp psychovisually lossless coding)
|
|
|
|
lonjil
|
2024-05-28 09:22:36
|
I love bisecting big projects that take time to build
|
|
2024-05-28 09:26:27
|
oh nice old versions of libjxl don't compile on my computer because they use uint32_t but forgot to include the stdint header...
|
|
|
|
Demiurge
|
2024-05-28 09:27:24
|
Damn, that's a bummer to hear... Is the damage reversible at least? As in, the bitstream format hasn't changed so much to forbid it?
|
|
|
Jyrki Alakuijala
Fitting jpeg xl requirements made it worse at what it was very good at (1.6 bpp psychovisually lossless coding)
|
|
2024-05-28 09:28:04
|
I meant in response to this
|
|
2024-05-28 09:30:59
|
A lossy web codec only needs to be good at 0.5bpp to 2bpp... Maybe with some very clever tricks that you may or may not be able to rely on, you might be able to go as low as 0.3bpp and still have an acceptable image.
|
|
2024-05-28 09:31:43
|
Like separating an image into layers that are compressed with different algorithms that suit the different components of the image.
|
|
|
|
Jyrki Alakuijala
|
2024-05-28 09:32:26
|
What happens if you try libjxl-tiny
|
|
|
|
Demiurge
|
2024-05-28 09:32:30
|
But I doubt anyone is going to write a clever layer separation algorithm like that in the near future
|
|
|
|
lonjil
|
2024-05-28 09:32:38
|
<@1028567873007927297> in your experience, what bpp range should I be looking at to test for the problem with the factory image? At 1bpp, the bright colors seem to be pretty desaturated by v0.5 at least.
|
|
|
|
_wb_
|
2024-05-28 09:33:23
|
jxl can still do everything pik could do, bitstream-wise. It's just the encoder heuristics that have been made much more complex so they could handle a much broader quality range.
|
|
|
|
Demiurge
|
|
lonjil
<@1028567873007927297> in your experience, what bpp range should I be looking at to test for the problem with the factory image? At 1bpp, the bright colors seem to be pretty desaturated by v0.5 at least.
|
|
2024-05-28 09:33:37
|
Well... In the comparison page, the problem was very pronounced in the Medium size and below, but in the Large size, it was much harder for me to notice.
|
|
|
_wb_
jxl can still do everything pik could do, bitstream-wise. It's just the encoder heuristics that have been made much more complex so they could handle a much broader quality range.
|
|
2024-05-28 09:34:31
|
That's too bad... Theoretically, the encoder could just switch to a completely different algorithm after a certain distance setting threshold.
|
|
2024-05-28 09:35:03
|
Multiple different encoders in one tool, depending on what distance range the user chooses
|
|
2024-05-28 09:35:30
|
libjxl already has multiple different encoders in one tool. lossless, squeeze, vardct...
|
|
|
|
lonjil
|
2024-05-28 09:36:47
|
ok, at the same bpp, v0.5, though it does shift the colors, shifts them MUCH less than the image on the comparison website
|
|
|
|
Demiurge
|
2024-05-28 09:36:53
|
It's a complete waste of time trying to optimize for 0.5 bpp and 2bpp at the same time with the same encoder algorithm
|
|
2024-05-28 09:37:16
|
And it's a complete waste of time trying to optimize for anything below 0.5bpp without a very radical new method.
|
|
2024-05-28 09:38:34
|
btw just for curiosity's sake I also encoded these images to compare with Google's comparison with the latest dev version :)
|
|
|
|
lonjil
|
2024-05-28 09:38:48
|
with v0.5 as my "looks good enough" baseline, I will start bisecting to see if there is a point where the factory image got worse.
|
|
2024-05-28 09:39:23
|
(ofc, if it was a slow process of decline, bisecting won't find anything useful)
|
|
|
|
Demiurge
|
2024-05-28 09:41:16
|
Ok, right away, I can immediately see that these new images look way blurrier than the ones from Google's test
|
|
2024-05-28 09:41:33
|
Quality took a huge dive very recently
|
|
|
|
lonjil
|
2024-05-28 09:41:35
|
Maybe I should set up a script that compiles every single commit in the git history and spits out the image at a range of bpps 😄
|
|
|
|
Demiurge
|
|
lonjil
Maybe I should set up a script that compiles every single commit in the git history and spits out the image at a range of bpps 😄
|
|
2024-05-28 09:42:04
|
Aren't there build artifacts that can be used to test?
|
|
|
|
lonjil
|
2024-05-28 09:42:20
|
I don't think they're kept very long
|
|
|
|
Demiurge
|
2024-05-28 09:44:19
|
Google was using https://github.com/libjxl/libjxl/commit/137f53ef1a6f39e5f733edb6cc457625abb3b3c9
|
|
2024-05-28 09:44:48
|
I can tell you that the current git version produces much blurrier looking files.
|
|
2024-05-28 09:45:33
|
compare:
https://storage.googleapis.com/avif-comparison/images/subset1/sample_images/2011-03-05_03-13_Madeira_159_Funchal__Mercado_dos_Lavradores.png-s-7_0.93bpp.jxl.png
https://cdn.discordapp.com/attachments/794206170445119489/1244947922001330238/mercado-0.92bbp.png
|
|
2024-05-28 09:50:49
|
https://github.com/eclipseo/eclipseo.github.io/blob/2f93d184577d273cac729e778d73fdcc8a93d0a8/image-comparison-web/comparisonfiles/subset1/medium/JXL_20210715/2011-03-05_03-13_Madeira_159_Funchal%2C_Mercado_dos_Lavradores.jxl
|
|
2024-05-28 09:51:11
|
Here's another codec test. Using a version of libjxl from 2021
|
|
2024-05-28 09:51:21
|
It looks much better than today's latest version of libjxl
|
|
2024-05-28 09:51:54
|
Today's is extremely blurry by comparison
|
|
2024-05-28 09:52:22
|
It might have been regressing for a long time or, if we're lucky, maybe it happened suddenly very recently,
|
|
2024-05-28 09:54:06
|
https://raw.githubusercontent.com/eclipseo/eclipseo.github.io/2f93d184577d273cac729e778d73fdcc8a93d0a8/image-comparison-web/comparisonfiles/subset1/medium/JXL_20210715/2011-03-05_03-13_Madeira_159_Funchal%2C_Mercado_dos_Lavradores.png
|
|
2024-05-28 09:56:36
|
Wait a sec, that last one is not the right bitrate. Let me check...
|
|
2024-05-28 10:00:43
|
I can tell you though, libjxl definitely is not mangling colors worse than other codecs in that comparison here: https://github.com/eclipseo/eclipseo.github.io/
|
|
2024-05-28 10:01:36
|
Unfortunately I can't find the rest of the files in Google's comparison, they only put up a few examples
|
|
2024-05-28 10:25:40
|
Unfortunately. these all basically look the same to me. Except the lossless one obviously.
|
|
2024-05-28 10:26:24
|
I hoped this would help but it doesn't look like it will help. The colors look dull as far back as 0.7
|
|
|
CrushedAsian255
|
|
Demiurge
Unfortunately. these all basically look the same to me. Except the lossless one obviously.
|
|
2024-05-28 10:42:01
|
wait what is `jxll` compared to `jxl`?
|
|
|
|
Demiurge
|
2024-05-28 10:46:39
|
JXLossLess :)
|
|
2024-05-28 10:46:51
|
Wait I am getting somewhere
|
|
2024-05-28 10:46:55
|
I have finally made progress
|
|
2024-05-28 10:47:03
|
|
|
2024-05-28 10:47:06
|
Behold
|
|
2024-05-28 10:47:35
|
0.7 was when the colors started to suck
|
|
|
CrushedAsian255
wait what is `jxll` compared to `jxl`?
|
|
2024-05-28 10:48:35
|
the plain .jxl is the latest version
|
|
2024-05-28 10:48:53
|
not 0.10
|
|
2024-05-28 10:48:57
|
git
|
|
2024-05-28 10:49:44
|
Anyways hopefully that's some help. Somewhere between 061 and 070 the colors got washed out :)
|
|
|
|
CrushedAsian255
|
|
Demiurge
0.7 was when the colors started to suck
|
|
2024-05-28 10:51:43
|
oh dear, should i unconvert my jxl's
|
|
|
|
yoochan
|
2024-05-28 10:52:25
|
you did jpeg to jxl ? you are not impacted I think
|
|
2024-05-28 10:52:41
|
we discuss lossy encoding of raw images
|
|
|
|
Demiurge
|
2024-05-28 10:52:54
|
If you did lossy then you deserve what you get ;(
|
|
|
|
CrushedAsian255
|
2024-05-28 10:53:01
|
what about lossless
|
|
2024-05-28 10:53:08
|
i converted a whole lot of PNGs to lossless JXL
|
|
|
|
Demiurge
|
2024-05-28 10:53:29
|
Lossless should always be fine barring any bugs
|
|
|
|
CrushedAsian255
|
|
Demiurge
If you did lossy then you deserve what you get ;(
|
|
2024-05-28 10:53:40
|
fair point, lossy **is** lossy
|
|
2024-05-28 10:58:19
|
i have a total of like 10 out of over 1000 lossy JXLs, where as all the others are either lossless PNG -> JXL or JPEG recodes
|
|
|
|
Demiurge
|
2024-05-28 11:01:54
|
I know I often mention this lately, but, masking artifacts with high-frequency noise is an old and true method to improve fidelity and in codecs, both audio and visual. Signals that are large and distinct, like blurry smudges, or a well-defined object totally changing color, are much easier signals for the human eye to notice and get bothered by. Just as long as it's not the classic dreaded "JPEG mosquito artifacts"
|
|
|
|
CrushedAsian255
|
|
Demiurge
I know I often mention this lately, but, masking artifacts with high-frequency noise is an old and true method to improve fidelity and in codecs, both audio and visual. Signals that are large and distinct, like blurry smudges, or a well-defined object totally changing color, are much easier signals for the human eye to notice and get bothered by. Just as long as it's not the classic dreaded "JPEG mosquito artifacts"
|
|
2024-05-28 11:03:00
|
are "jpeg mosquito artifacts" the dots caused by over-compensating the high frequency AC components?
|
|
|
|
Demiurge
|
2024-05-28 11:03:10
|
Yes, that's exactly what it is.
|
|
2024-05-28 11:08:26
|
But mosquito and ringing artifacts could potentially be reduced someday, if someone eventually writes an encoder that can detect and subtract non-DCT-able signals in an image.
|
|
2024-05-28 11:11:16
|
If someone writes an image processing kernel that can detect and isolate image features like well defined solid shapes and lines and smooth gradients that are easy to compress but hard for DCT, then that would propel jpegxl far ahead of every other codec on the planet.
|
|
2024-05-28 11:12:32
|
What the press would call a "quantum leap" in image coding
|
|
|
|
Jyrki Alakuijala
|
2024-05-28 11:13:27
|
Pashifox, could you figure out the PR that created the degradation?
|
|
2024-05-28 11:13:54
|
If you have a process for this already
|
|
2024-05-28 11:14:25
|
It is puzzling for me since I love colors and have reviewed every quality affecting change 😅
|
|
2024-05-28 11:14:44
|
I promise to fix it once it is known
|
|
|
|
yoochan
|
2024-05-28 11:16:56
|
I could test it with released version (and I started to do so), but I had difficulties to compile old version too
|
|
2024-05-28 11:17:19
|
(various errors appears for older versions)
|
|
2024-05-28 11:19:39
|
to make the process a bit more automatic, how could I compute the "saturation" ? from the RGB values ?
|
|
|
|
Demiurge
|
2024-05-28 11:22:30
|
Well you could convert the pixels to HSV representation maybe...
|
|
|
Jyrki Alakuijala
If you have a process for this already
|
|
2024-05-28 11:23:11
|
My process was to just download the static linux builds from the tags/releases page on github :)
|
|
|
yoochan
(various errors appears for older versions)
|
|
2024-05-28 11:24:08
|
What kind of errors...?
|
|
|
|
yoochan
|
|
Demiurge
My process was to just download the static linux builds from the tags/releases page on github :)
|
|
2024-05-28 11:24:13
|
I'll do something similar 😄
|
|
2024-05-28 11:24:19
|
compilation errors
|
|
|
|
Demiurge
|
2024-05-28 11:29:29
|
Hmm, so I was just thinking about this quantum leap idea... There are plenty of established kernels that do edge-preserving blur... Maybe as a naive first attempt, you could take an image, apply an extreme edge-preserving blur to it, save it as a modular layer, then subtract it from the original image to get a "texture" layer to be compressed with DCT?
|
|
2024-05-28 11:31:40
|
Assuming you make the modular layer really small and as low-entropy as possible, you could do really great things that way
|
|
2024-05-28 11:41:28
|
Taking the burden of edges off DCT so it can focus on what it's good at and not what it's bad at.
|
|
|
|
spider-mario
|
|
Demiurge
Well you could convert the pixels to HSV representation maybe...
|
|
2024-05-28 11:42:53
|
for what it’s worth, HSV is considered kind of awful
https://en.wikipedia.org/wiki/HSL_and_HSV#Disadvantages
|
|
|
|
Demiurge
|
2024-05-28 11:49:06
|
It's the simplest way to get "saturation" I think...?
|
|
|
|
_wb_
|
2024-05-28 11:52:40
|
something like sqrt(a^2 + b^2) in Lab space or something equivalent with scaled X and (B-Y) in XYB would be a better approximation for saturation imo
|
|
|
|
Jyrki Alakuijala
|
|
Demiurge
My process was to just download the static linux builds from the tags/releases page on github :)
|
|
2024-05-28 11:55:17
|
I'll take this on my own plate then... 🏋️ thank you for the help so far 🌞🌞🌞
|
|
|
|
_wb_
|
2024-05-28 11:55:51
|
or the c of OkLab's oklch, that would work too
|
|
|
|
Demiurge
|
2024-05-28 11:56:02
|
thank you codec hero :)
|
|
2024-05-28 11:57:07
|
xyz vs lab, wonder what the practical difference is...
|
|
2024-05-28 11:57:39
|
I think xyz is 3 primary colors, and lab is 4 (opponent theory)
|
|
2024-05-28 11:57:58
|
with R-G plane and Y-B plane
|
|
2024-05-28 12:00:34
|
the 4 primary color opponent theory model makes a lot of sense to me based on how I've observed my own eyes to behave
|
|
|
|
spider-mario
|
2024-05-28 12:30:51
|
in LCh, saturation is C/L: https://en.wikipedia.org/wiki/CIELUV#Cylindrical_representation_(CIELCh)
|
|
2024-05-28 12:31:17
|
(where C = sqrt(u\*² + v\*²))
|
|
|
|
_wb_
|
2024-05-28 03:27:23
|
Right, though that gives a high saturation value to something like hex color #010000, which is somewhat counter-intuitive to me
|
|
2024-05-28 03:28:27
|
but I guess that's what saturation is
|
|
2024-05-28 03:30:50
|
if you want something that represents "amount of colorfulness", using chrominance C directly without dividing by luminance might make more sense (even if that has the opposite problem of a bright color having a larger C value than a dark color)
|
|
|
|
Orum
|
2024-05-28 04:11:50
|
does `--streaming_input` work with a literal stream (e.g. stdin)?
|
|
2024-05-28 04:13:12
|
looks like no....
|
|
2024-05-28 04:14:05
|
cjxl does work when reading from stdin without it though 🤔
|
|