|
jonnyawsom3
|
2025-05-23 04:48:22
|
The 1 in XYB scales to 9 after the ICC conversion to sRGB, in another example it was 12
|
|
2025-05-23 04:50:34
|
And here is the PNG I used to test. 1-bit pallete, so I could just use tweakpng to edit the B value directly rather than re-encode
|
|
2025-05-23 04:54:00
|
So either the desaturation can be fixed by increasing allocation to B, or the XYB transform could be used to spread the error to other channels instead
|
|
2025-05-23 05:19:21
|
<@794205442175402004> perhaps B could be biased to round away from zero? Then colors would become more saturated instead of less, possibly even increasing appeal by having a sharpening effect.
|
|
|
_wb_
|
2025-05-23 05:25:36
|
Worth trying but less zeroes is also going to increase bpp
|
|
|
|
jonnyawsom3
|
2025-05-23 05:27:32
|
Keeping the current harsh quantization, but to values other than zero, may even out the density. So far all fixes have just been increasing quality of certain aspects, but this would be redistributing the error to larger high saturation areas, instead of low saturation noise... Hopefully
|
|
|
Demiurge
|
2025-05-23 06:49:10
|
Mosquito noise is a symptom of ringing
|
|
|
Just ran the tests, it is indeed the B channel causing desaturation. This is from changing the B value in a custom XYB PNG by 1
|
|
2025-05-23 06:49:49
|
The B channel also controls how "yellow" something looks since blue and yellow are opposed.
|
|
2025-05-23 06:50:19
|
So it makes a lot of sense that the poor quantization of the B channel is causing problems
|
|
2025-05-23 06:52:27
|
Our eyes are very sensitive to yellow but I don't think the XYB quantization is smart enough to quantize positive blue values more coarsely than negative yellow values.
|
|
2025-05-23 06:55:14
|
Furthermore, you can use a very coarse quantization and still get away with it as long as the error averages out close to the correct values, like with dithering or error-diffusion. So coarse quantization is not really a valid reason for de-saturation, which is caused because the error averages to a less-saturated value.
|
|
2025-05-23 06:56:27
|
It's as if it's using simple truncation, rounding toward zero
|
|
2025-05-23 06:56:42
|
Rather than any intelligent error distribution scheme
|
|
|
|
jonnyawsom3
|
2025-05-23 07:02:56
|
The error here is a single value. There is no averaging because it's a binary difference, saturated or not. Having alternating values just causes the chroma noise that you've been complaining about, as values are alternating between 255, 245, 43 and 255, 245, 52 in the best case, and multiples of that in the worst
|
|
|
Jyrki Alakuijala
|
|
<@794205442175402004> perhaps B could be biased to round away from zero? Then colors would become more saturated instead of less, possibly even increasing appeal by having a sharpening effect.
|
|
2025-05-23 07:19:50
|
more zeros are the main way to achieve lossy compression, having some less zeros is very expensive -- perhaps there is another way
|
|
|
Just ran the tests, it is indeed the B channel causing desaturation. This is from changing the B value in a custom XYB PNG by 1
|
|
2025-05-23 07:20:58
|
I don't see a difference
|
|
|
Demiurge
Our eyes are very sensitive to yellow but I don't think the XYB quantization is smart enough to quantize positive blue values more coarsely than negative yellow values.
|
|
2025-05-23 07:22:05
|
it needs to do the opposite: blue needs to be precise when without red and green, that is when also the M and L receptors see the blue
|
|
|
|
jonnyawsom3
|
|
Jyrki Alakuijala
I don't see a difference
|
|
2025-05-23 07:23:46
|
This is with B increased by 2, should be more visible
|
|
2025-05-23 07:30:01
|
Increasing the B channel of XYB by 1, causes RGB's B channel to increase by 9. Increasing B in XYB by 2, results in B in RGB increasing by 16, ect.
The smallest change in B for certain vibrant colours, causes significant desaturation
|
|
|
|
Demiurge
|
|
Jyrki Alakuijala
I don't see a difference
|
|
2025-05-23 07:31:32
|
I do. It's easier to notice when flickering between them.
|
|
|
Jyrki Alakuijala
more zeros are the main way to achieve lossy compression, having some less zeros is very expensive -- perhaps there is another way
|
|
2025-05-23 07:33:39
|
The only other way is some sort of error-diffusion method where the error centers on the correct value rather than having a bias that lowers fidelity.
|
|
|
|
jonnyawsom3
|
2025-05-23 07:34:16
|
That's still not zeroing though, and you just said that :P
|
|
|
|
Demiurge
|
2025-05-23 07:35:04
|
It's better than having an over-saturation bias.
|
|
2025-05-23 07:35:28
|
Ideally the error should not have a bias because our eyes are sensitive to that bias and it changes how the image looks
|
|
2025-05-23 07:36:26
|
If the goal is fidelity, then the error needs to average out to something that resembles the original.
|
|
|
|
jonnyawsom3
|
2025-05-23 07:36:37
|
Jyrki just said that non-zeroing should be avoided if possible, so neither of our ideas are ideal
|
|
|
|
Jyrki Alakuijala
|
|
juliobbv
focus on this particular region
|
|
2025-05-23 07:38:09
|
the luma masking thinks the high frequency luma info will mask small r-g diffs here, but two problems: high frequency luma is not preserved through the compression and r-g diffs are at a lower spatial frequency band which is no longer masked by the high frequency luma
|
|
|
|
Demiurge
|
2025-05-23 07:38:18
|
They are not equal. He is just explaining that the entropy coding is much more efficient the more zeroes there are.
|
|
|
|
Jyrki Alakuijala
|
|
Jyrki just said that non-zeroing should be avoided if possible, so neither of our ideas are ideal
|
|
2025-05-23 07:38:47
|
all rules about compression are still just rules of thumb, and trying things out is the right way π
|
|
2025-05-23 07:39:33
|
I wrote something about my thoughts in https://github.com/libjxl/libjxl/pull/4267
|
|
2025-05-23 07:39:42
|
as additional comments
|
|
|
|
Demiurge
|
2025-05-23 07:41:39
|
At the end of the day the goal is accuracy and fidelity... Being able to faithfully capture the original image while quantizing/rounding numbers as small as possible.
|
|
|
|
Jyrki Alakuijala
|
2025-05-23 07:42:11
|
JPEG XL's encoding is several complex systems that interact: color modeling, integral transforms, quantization of coefficients, adaptive deadzone, adaptive quantization, selection of integral transforms, adjusting epf parameters, modeling visual masking, noise, ...
|
|
2025-05-23 07:42:36
|
because of this, some systems cover for mistakes in other systems, as things that were adopted over time
|
|
|
|
Demiurge
|
2025-05-23 07:42:37
|
The better and more faithful the quantization methods are the more you can crush it while still being able to recognize what it is
|
|
|
|
Jyrki Alakuijala
|
2025-05-23 07:43:03
|
and making consistent progress by logical thinking and then applying the results of the thinking has gotten a little difficult
|
|
2025-05-23 07:44:10
|
modeling visual masking better (luma + r-g + photon noise) with varying spatial frequencies of masking is likely the biggest remaining opportunity, but it can only be used at higher encoding efforts
|
|
|
Demiurge
The better and more faithful the quantization methods are the more you can crush it while still being able to recognize what it is
|
|
2025-05-23 07:44:46
|
that's the way to put it shortly
|
|
|
|
Demiurge
|
|
Jyrki Alakuijala
modeling visual masking better (luma + r-g + photon noise) with varying spatial frequencies of masking is likely the biggest remaining opportunity, but it can only be used at higher encoding efforts
|
|
2025-05-23 07:45:27
|
Visual masking is a big opportunity, like you said. I don't think anyone expects it to be fast and efficient at first while it's still in incubation phase essentially.
|
|
2025-05-23 07:45:38
|
But if something works really well it can always be optimized later.
|
|
2025-05-23 07:45:50
|
People can find faster ways of doing it eventually
|
|
|
|
Jyrki Alakuijala
|
2025-05-23 07:45:51
|
it will need memory to contain the data
|
|
2025-05-23 07:46:10
|
having two frequency bands and separation for luma/r-g will 4x the size of the masking model
|
|
2025-05-23 07:46:21
|
there is no cure against memory bandwidth use
|
|
|
|
Demiurge
|
2025-05-23 07:46:37
|
LAME used to be considered an extremely slow and experimental MP3 encoder with an advanced psychoacoustic masking model
|
|
2025-05-23 07:46:52
|
Now it's considered basically the gold standard MP3 encoder
|
|
|
|
Jyrki Alakuijala
|
2025-05-23 07:46:56
|
nothing advanced in any MP3 encoder π
|
|
|
|
Demiurge
|
2025-05-23 07:47:22
|
I actually like the sound of LAME better than Vorbis!
|
|
2025-05-23 07:47:40
|
Even though Vorbis is a much more advanced codec
|
|
|
|
Jyrki Alakuijala
|
2025-05-23 07:48:01
|
I get emotional about sound quality very quickly, I have been tweaking a psychoacoustic model for 1.5 years now
|
|
|
|
Demiurge
|
|
Jyrki Alakuijala
I get emotional about sound quality very quickly, I have been tweaking a psychoacoustic model for 1.5 years now
|
|
2025-05-23 07:48:26
|
You must REALLY hate listening to anything on Youtube then lol
|
|
|
|
jonnyawsom3
|
2025-05-23 07:48:35
|
The desaturation either hadn't been noticed or hasn't been fixed since the first specification was published. It's a new problem to think of fresh solutions for, and when it's done, may open more opportunities for the other tools to take advantage of. I think it may be causing some of the chroma noise you've been fixing too, due to off-by 1 errors in the DCT displaying as noise, but I could be wrong. It may also fix the desaturation noticed in DZgas' images, which was the reason for the change in AC strategy after v0.8. Lots of possibilites with this discovery, but much more testing is needed to find out.
|
|
|
|
Jyrki Alakuijala
|
2025-05-23 07:48:36
|
exactly!!!
|
|
|
|
Demiurge
|
2025-05-23 07:48:43
|
Youtube encoder just sounds like indistinct noise.
|
|
|
|
Jyrki Alakuijala
|
2025-05-23 07:48:45
|
also we have 'ringli' which can compress 2.5x more than opus
|
|
|
|
Demiurge
|
2025-05-23 07:48:56
|
ringli?
|
|
|
|
Jyrki Alakuijala
|
2025-05-23 07:49:00
|
I don't like opus at 128 kbps
|
|
2025-05-23 07:49:08
|
ringli is a prototype audio compressor
|
|
|
|
Demiurge
|
2025-05-23 07:49:25
|
I love harpsichord so I really dislike what opus does to it
|
|
|
|
Jyrki Alakuijala
|
2025-05-23 07:49:26
|
we have tuned it with zimtohrli and listening experiments
|
|
2025-05-23 07:49:42
|
yes, ringli preserves it 100 % π
|
|
|
|
Demiurge
|
|
Jyrki Alakuijala
ringli is a prototype audio compressor
|
|
2025-05-23 07:49:47
|
it's not public yet?
|
|
2025-05-23 07:49:57
|
You friends with xiphmont? I know he loves this stuff.
|
|
|
|
Jyrki Alakuijala
|
2025-05-23 07:50:02
|
it's open sourced but not standardized nor frozen
|
|
|
|
Demiurge
|
2025-05-23 07:50:16
|
oh, cool
|
|
|
|
Jyrki Alakuijala
|
2025-05-23 07:50:21
|
it aims at cheapest psychoacoustically lossless
|
|
2025-05-23 07:50:31
|
I figured out a way to avoid MDCT and use normal DCT instead
|
|
2025-05-23 07:50:39
|
it reduces latency by 10 ms
|
|
2025-05-23 07:50:50
|
if block size the same
|
|
|
|
Demiurge
|
|
Jyrki Alakuijala
it aims at cheapest psychoacoustically lossless
|
|
2025-05-23 07:50:57
|
That sounds like the same goal of musepack
|
|
|
|
Jyrki Alakuijala
|
2025-05-23 07:51:02
|
and we can do smaller blocks, down to 64 samples (usually people use 1024 samples)
|
|
2025-05-23 07:51:47
|
also I have managed to fully understand the needs for perfect ambisonics (arising from the physics), so I could incorporate an amazingly efficient ambisonics systems into it
|
|
|
|
Demiurge
|
2025-05-23 07:52:12
|
So potentially even lower latency than opus, but it probably uses a larger block size to better preserve higher frequency harmonics like in harpsichord music right?
|
|
|
|
Jyrki Alakuijala
|
2025-05-23 07:52:29
|
half the latency at opus block size
|
|
2025-05-23 07:52:40
|
but I recommend using shorter blocks, 64 samples
|
|
|
|
jonnyawsom3
|
2025-05-23 07:52:43
|
May I suggest <#805176455658733570> π
|
|
|
|
Jyrki Alakuijala
|
2025-05-23 07:52:46
|
or sample based lossy
|
|
2025-05-23 07:52:49
|
alright π
|
|
|
|
Demiurge
|
|
Jyrki Alakuijala
also I have managed to fully understand the needs for perfect ambisonics (arising from the physics), so I could incorporate an amazingly efficient ambisonics systems into it
|
|
2025-05-23 07:52:53
|
xiphmont was getting really obsessed with ambisonics last I checked...
|
|
2025-05-23 07:53:00
|
You ever speak with him?
|
|
|
|
Jyrki Alakuijala
|
2025-05-23 07:53:03
|
send them my way
|
|
|
|
Demiurge
|
2025-05-23 07:53:09
|
Monty Montgomery
|
|
2025-05-23 07:53:18
|
The famous Xiph guy and Vorbis creator
|
|
|
|
Jyrki Alakuijala
|
2025-05-23 07:53:57
|
famous people are usually not great collaborators, they can be better at showing a direction for others
|
|
|
|
Demiurge
|
2025-05-23 07:54:14
|
I think he hangs out on IRC last I checked years ago.
|
|
2025-05-23 07:54:19
|
Many years ago.
|
|
|
|
Jyrki Alakuijala
|
2025-05-23 07:54:20
|
but I usually have my own aesthetics on what comes to algorithms and it can be intuitive and difficult to explain
|
|
2025-05-23 07:55:02
|
I'm starting the audio contributions with zimtohrli, a new audio metric -- then next steps will be audio compression
|
|
|
|
Demiurge
|
2025-05-23 07:55:15
|
You should probably make some cool demo websites like he did for opus/theora/daala/av1
|
|
2025-05-23 07:55:40
|
So people can see your work and get wowed
|
|
|
|
Jyrki Alakuijala
|
2025-05-23 07:55:51
|
demo sites are interesting for people when the errors are big, psychoacoustically lossless and near-lossless sites are boring
|
|
|
|
Demiurge
|
2025-05-23 07:56:29
|
Yes, lol, that's why you show how bad the competition is by comparison and include numbers like byte savings.
|
|
2025-05-23 07:56:47
|
:)
|
|
|
|
Jyrki Alakuijala
|
2025-05-23 07:57:10
|
I don't have time to focus on that right now, I'll still need to create more substance for it
|
|
|
|
Demiurge
|
2025-05-23 07:57:20
|
Mont did a lot of demos where he shows how 1 small tweak or change or addition of a new fancy thing makes a big difference in output quality.
|
|
|
|
Jyrki Alakuijala
|
2025-05-23 07:57:40
|
I merged https://github.com/libjxl/libjxl/pull/4267 -- if someone wants to test on clovisfest
|
|
|
|
Demiurge
|
2025-05-23 07:58:23
|
https://people.xiph.org/~xiphmont/demo/index.html
|
|
|
|
jonnyawsom3
|
|
The B channel can also influence Yellow, Green, Purple and Orange with fairly narrow ranges. The harsh quantization makes it fall out of those small ranges and bleed other colors/reduce saturation. As far as I've been able to understand
|
|
2025-05-23 08:04:58
|
Doing some light testing, it seems like it's limited to yellow. Tried to replicate Green and Purple desaturation, but either my values were wrong or it had no impact. May allow for specialisation to increase B precision when X is near 0 and Y near 0.8
|
|
|
The desaturation either hadn't been noticed or hasn't been fixed since the first specification was published. It's a new problem to think of fresh solutions for, and when it's done, may open more opportunities for the other tools to take advantage of. I think it may be causing some of the chroma noise you've been fixing too, due to off-by 1 errors in the DCT displaying as noise, but I could be wrong. It may also fix the desaturation noticed in DZgas' images, which was the reason for the change in AC strategy after v0.8. Lots of possibilites with this discovery, but much more testing is needed to find out.
|
|
2025-05-23 08:07:34
|
It would be very interesting to only increase the quality of B, and see how it impacts the image if all else stayed the same
|
|
|
|
Jyrki Alakuijala
|
2025-05-23 08:08:14
|
the simplest is to put the blue multiplier all the way to 7 in enc_frame.cc
|
|
2025-05-23 08:09:23
|
there is a value how much B is quantized that is modulated by 2 ** (N/4), where N is a 3 bit value in the bit stream
|
|
2025-05-23 08:10:37
|
line 666 !! https://github.com/libjxl/libjxl/blob/main/lib/jxl/enc_frame.cc#L666
|
|
|
|
jonnyawsom3
|
2025-05-23 08:11:32
|
Perfect
|
|
|
|
Jyrki Alakuijala
|
2025-05-23 08:11:35
|
just put it as 7
|
|
2025-05-23 08:11:49
|
the same for b channel a bit lower
|
|
2025-05-23 08:11:53
|
I'm thinking of upping the x channel precision by 2
|
|
2025-05-23 08:12:30
|
that will resolve the remaining r-g problems for pixel peepers, at a cost of 7.77 % compression density loss
|
|
2025-05-23 08:12:42
|
and saturation issues
|
|
|
|
Demiurge
|
2025-05-23 08:26:26
|
Ideally, you would want to keep the precision coarse, and improve the way it looks without increasing precision...
|
|
|
d3liri0us
|
2025-05-23 09:20:41
|
Hey folks,
I wanted to create a containerized jxl that includes a JPEG XL codestream box (`jxlc`). My current approach is to create a GIF file, and convert that to JXL using `cjxl` but that creates partial codestreams (`jxlp`) only. I tried online conversion tools but they don't create containerized files.
Is there a way to properly address individual frames so that I can get information like `jxlc`, `jxli` etc.? I have individual frames saved as pngs but `cjxl` doesn't allow more than one image file input.
|
|
|
Traneptora
|
|
d3liri0us
Hey folks,
I wanted to create a containerized jxl that includes a JPEG XL codestream box (`jxlc`). My current approach is to create a GIF file, and convert that to JXL using `cjxl` but that creates partial codestreams (`jxlp`) only. I tried online conversion tools but they don't create containerized files.
Is there a way to properly address individual frames so that I can get information like `jxlc`, `jxli` etc.? I have individual frames saved as pngs but `cjxl` doesn't allow more than one image file input.
|
|
2025-05-23 09:38:08
|
jxlc is the whole codestream in a single box, which is probably not what you want if you're trying to index animation
|
|
|
|
d3liri0us
|
2025-05-23 10:08:45
|
Yeah, I went through the format overview. My aim was to find dimensions of the jxl file (individual frames if possible) and starting offset for every frame from the file data. It looks like they are encoded in the codestream as well.
|
|
|
|
Demiurge
|
2025-05-23 10:34:32
|
There is a command line option to create containerized jxl
|
|
2025-05-23 10:34:50
|
Default is to create raw jxl unless there is a needful reason
|
|
2025-05-23 10:39:50
|
I think the flag is `cjxl --container 1`
|
|
2025-05-23 10:45:06
|
I wonder if kornelski's improved median cut algorithm can be used at all to help improve color quantization in jxl?
|
|
2025-05-23 10:48:11
|
He's pretty good at coarsely quantizing colors while maintaining the original look really well. I wonder if any of that can be applied to jxl...
|
|
|
|
Traneptora
|
|
d3liri0us
Yeah, I went through the format overview. My aim was to find dimensions of the jxl file (individual frames if possible) and starting offset for every frame from the file data. It looks like they are encoded in the codestream as well.
|
|
2025-05-23 10:58:00
|
The dimensions are *only* in the codestream, and there's no guarantee that there will be jxli boxes that tell you where the next frames start. You'd have to parse it.
You can use FFmpeg to do this by the way, because it has a JPEG XL parser.
|
|
2025-05-23 10:59:48
|
although the parser currently separates out codestreams, not frames. hm.
|
|
2025-05-23 10:59:56
|
into packets
|
|
2025-05-23 11:00:38
|
Unfortunately, in order to fully parse JPEG XL, you need to implement an entropy decoder
|
|
2025-05-23 11:00:39
|
this is hard
|
|
2025-05-23 11:00:47
|
you can use `jxlinfo` and parse its output, if that makes it easier
|
|
2025-05-23 11:01:08
|
or just link to the library
|
|
2025-05-23 11:01:10
|
seems easier
|
|
|
d3liri0us
Yeah, I went through the format overview. My aim was to find dimensions of the jxl file (individual frames if possible) and starting offset for every frame from the file data. It looks like they are encoded in the codestream as well.
|
|
2025-05-23 11:01:31
|
My biggest question though is why you are using animated JPEG XL at all
|
|
2025-05-23 11:01:51
|
JPEG XL is not a video format. Animation is mostly there for feature parity with GIF and AVIF
|
|
2025-05-23 11:02:05
|
it's usually preferable to use a sequence of still JPEG XL images
|
|
|
|
d3liri0us
|
|
Demiurge
I think the flag is `cjxl --container 1`
|
|
2025-05-23 11:16:05
|
Yeah, this generates partial codestreams (`jxlp`) in my case.
|
|
|
Traneptora
JPEG XL is not a video format. Animation is mostly there for feature parity with GIF and AVIF
|
|
2025-05-23 11:25:43
|
The reason why I started looking into this was because of GIFs. The file structure allows identifying offsets and dimensions of individual frames which made me curious to look into this file format as well.
I was looking forward to make a file forensics CTF challenge based on JPEG XL. The idea was to corrupt a few bytes so that people would look into the file format documentation and fix those bytes in order to view the file properly. Since this is encoded, it is difficult to implement that idea over here.
|
|
|
|
Traneptora
|
|
d3liri0us
The reason why I started looking into this was because of GIFs. The file structure allows identifying offsets and dimensions of individual frames which made me curious to look into this file format as well.
I was looking forward to make a file forensics CTF challenge based on JPEG XL. The idea was to corrupt a few bytes so that people would look into the file format documentation and fix those bytes in order to view the file properly. Since this is encoded, it is difficult to implement that idea over here.
|
|
2025-05-23 11:27:35
|
The problem with this is the codestream structure is not a free standard. It's open but you have to pay the ISO for the PDF unless you're viewing a draft
|
|
2025-05-23 11:28:09
|
It sounds like you're better off using a containerless JXL for your purpose though
|
|
2025-05-23 11:28:17
|
the codestream itself without a container is permitted
|
|
2025-05-23 11:28:40
|
however, in some cases it's not possible to find the frame offsets without an entropy decoder
|
|
2025-05-23 11:29:07
|
this is because frames occur after the ICC Profile, which is an entropy-coded stream without a compressed-length header
|
|
2025-05-23 11:29:23
|
so there's no easy Start-of-Frame scan like in JPEG1
|
|
2025-05-23 11:29:58
|
likewise, the table of contents can also be entropy coded
|
|
2025-05-23 11:30:22
|
more specifically, every frame has a Table of Contents containing the length of the frame data sections in the order they appear
|
|
2025-05-23 11:30:39
|
but the TOC can be permuted, which allows the frame data sections to appear out of order
|
|
2025-05-23 11:30:46
|
the permutation itself is entropy-coded.
|
|
2025-05-23 11:31:00
|
and it occurs before the TOC lengths
|
|
2025-05-23 11:31:30
|
and since the entropy stream has no compressed-length header, in order to determine the length of a Frame bundle, you may need to decode a permuted TOC, which may require you to implement an entropy decoder
|
|
2025-05-23 11:31:31
|
now
|
|
2025-05-23 11:31:32
|
all this said
|
|
2025-05-23 11:31:56
|
you can construct the files on which the CTF has to take place, so you can ensure it has no ICC profile and that it has no permuted TOCs
|
|
2025-05-23 11:32:32
|
but in general JPEG XL codestreams are a sequence of bits, not bytes, and many of the fields are variable-length
|
|
2025-05-23 11:33:07
|
so if you corrupt a byte or two, you might change the length of a field which can misalign the rest of the file and make it nonsense
|
|
2025-05-23 11:33:25
|
there are a few times throughout the codestream where a ZeroPadToByte is invoked, where zero bits are written until the bitstream is an integer number of bytes
|
|
2025-05-23 11:33:49
|
if you plan on corrupting part of the image for a CTF, I'd recommend doing so shortly before one of those
|
|
|
|
d3liri0us
|
|
Traneptora
but in general JPEG XL codestreams are a sequence of bits, not bytes, and many of the fields are variable-length
|
|
2025-05-23 11:40:37
|
Ah .. knowing this helps a lot
|
|
2025-05-23 11:42:22
|
Implementing an entropy decoder would be going beyond reach, but I appreciate all the information.
|
|
|
Traneptora
there are a few times throughout the codestream where a ZeroPadToByte is invoked, where zero bits are written until the bitstream is an integer number of bytes
|
|
2025-05-23 11:43:49
|
If that's the case, it seems to be a good place to start. Thanks for taking your time and sharing all of this! I truly appreciate it. π
|
|
|
|
Traneptora
|
|
d3liri0us
Ah .. knowing this helps a lot
|
|
2025-05-23 11:56:11
|
Hint: <#1021189485960114198> has some drafts
|
|
2025-05-23 11:56:36
|
but they're intentionally not public because they're drafts
|
|
2025-05-23 12:06:09
|
If it wasn't CTF the draft could be given to students or something, but considering it's CTF you can't just give them the document
|
|
|
|
d3liri0us
|
|
Traneptora
If it wasn't CTF the draft could be given to students or something, but considering it's CTF you can't just give them the document
|
|
2025-05-23 12:41:56
|
The aim would be to build around something that can be referred to. If not, it often gets marked as "guessy" or "unsolvable". It's okay to provide some level of context as long as it leads the player to try out something new.
|
|
|
CrushedAsian255
|
|
Traneptora
If it wasn't CTF the draft could be given to students or something, but considering it's CTF you can't just give them the document
|
|
2025-05-23 01:03:47
|
CTF = capture the flag?
|
|
|
|
_wb_
|
2025-05-23 04:30:38
|
ISO "only" has a copyright on the spec. Not everything is copyrightable though. Tables with factual information like bitstream syntax are not really copyrightable (besides the specific layout maybe). The pseudocode fragments in the spec are based on libjxl which is open source. So basically: you cannot distribute the spec or fragments of it just like that, but you can certainly reformulate the prose in your own words and reproduce code from libjxl and any tables with factual information like ImageHeader or FrameHeader fields.
|
|
|
|
jonnyawsom3
|
|
Jyrki Alakuijala
just put it as 7
|
|
2025-05-23 04:49:20
|
As a test, we tried increasing only B and changing nothing else. It did indeed help with the desaturation, and remove most of the chroma ringing. More testing needed though.
We also tried changing some AQ multipliers back to v0.8 values. The file became both smaller and higher quality for a non-photographic image, but we had all been awake a very long time so paused the testing there
|
|
|
|
JKUser4592
|
2025-05-23 10:59:56
|
What are some Android apps that can convert animated JXLs to other animated formats like APNG and GIF?
|
|
|
HCrikki
|
2025-05-23 11:24:20
|
whats the use case, if you dont mind? going back to the source animation/video and generating an output in a different format should be less tricky and end up of higher quality if you go that way
|
|
|
Orum
|
2025-05-23 11:24:20
|
ffmpeg?
|
|
|
|
JKUser4592
|
|
HCrikki
whats the use case, if you dont mind? going back to the source animation/video and generating an output in a different format should be less tricky and end up of higher quality if you go that way
|
|
2025-05-23 11:40:34
|
I can't play the jxl file normally on my phone
|
|
|
|
HCrikki
|
2025-05-23 11:43:05
|
how did you generate or receive that animated jxl?
|
|
2025-05-23 11:43:55
|
theres websites that take animated jxl as input and can generate gif/apng but it can have privacy implications unless its processed entirely locally
|
|
|
|
JKUser4592
|
|
HCrikki
how did you generate or receive that animated jxl?
|
|
2025-05-24 02:31:08
|
I took APNG files and used libjxl via jxl batch converter to convert them to JXL
|
|
|
Mine18
|
|
JKUser4592
What are some Android apps that can convert animated JXLs to other animated formats like APNG and GIF?
|
|
2025-05-24 07:15:30
|
you could use image toolbox, convert the jxl animation to a series of images and then convert those series of images to whatever gif, apng, or webp
|
|
|
|
Jyrki Alakuijala
|
|
Demiurge
He's pretty good at coarsely quantizing colors while maintaining the original look really well. I wonder if any of that can be applied to jxl...
|
|
2025-05-24 08:44:47
|
There is a better algorithm for that. I designed it in 2007 and Zoltan implemented it. It is called greedy palettization.
|
|
|
|
Demiurge
|
2025-05-24 01:43:32
|
libjxl uses it?
|
|
|
|
Jyrki Alakuijala
|
|
Demiurge
libjxl uses it?
|
|
2025-05-24 04:54:22
|
No π
|
|
2025-05-24 04:55:33
|
Greedy palettization is or was used for google map tiles
|
|
2025-05-24 04:57:12
|
It is a millisecond time algorithm, in jpeg xl we could be relaxed about the speed
|
|
2025-05-24 04:59:03
|
I dont remember what we do in jpeg xl for palettization, except in delta palettization. Perhaps a few high population count colors. Delta palette is the interesting thing in jpeg xl palettization. Also, channel densifying is called palettization.
|
|
|
|
Demiurge
|
2025-05-24 05:03:14
|
Is that only for modular images?
|
|
|
|
_wb_
|
2025-05-24 05:28:32
|
Yes. Well in principle it could also be applied to the DC of VarDCT images...
|
|
|
|
boogerlad.
|
2025-05-24 11:31:35
|
Can jxl lossless jpeg 2000 transcode from dcp movies? https://en.m.wikipedia.org/wiki/Digital_Cinema_Package
|
|
|
|
HCrikki
|
2025-05-25 12:35:55
|
from my understanding, no
jp2's wavelet routines are used for neither jpeg or jpeg-xl so you can only do a traditional conversion (lossless is not guaranteed to have smaller filesize and more likely to actually be several times bigger than original the frame as is expected from going from lossy inputs to lossless output)
|
|
|
|
boogerlad.
|
2025-05-25 01:10:12
|
Gotcha. Thanks!
|
|
|
|
jonnyawsom3
|
2025-05-25 07:32:59
|
|
|
|
As a test, we tried increasing only B and changing nothing else. It did indeed help with the desaturation, and remove most of the chroma ringing. More testing needed though.
We also tried changing some AQ multipliers back to v0.8 values. The file became both smaller and higher quality for a non-photographic image, but we had all been awake a very long time so paused the testing there
|
|
2025-05-25 07:34:25
|
In regards to boosting the B quality, use arrows to flicker test. It does reduce the blue blotches compared to main, but for saturated yellow the error is still too high to avoid desaturation
|
|
|
juliobbv
|
|
In regards to boosting the B quality, use arrows to flicker test. It does reduce the blue blotches compared to main, but for saturated yellow the error is still too high to avoid desaturation
|
|
2025-05-25 09:19:53
|
TBH, the most obvious difference for me (by far) is luma, not chroma
|
|
2025-05-25 09:20:33
|
so at this quality level, I'm not sure if boosting B would be the best trade-off here
|
|
2025-05-25 09:21:34
|
unless the boosting can be done for free or very cheap of course
|
|
|
juliobbv
TBH, the most obvious difference for me (by far) is luma, not chroma
|
|
2025-05-25 09:22:11
|
to be more precise: lines (esp. from the background) look significantly smoother on the encoded version
|
|
|
|
jonnyawsom3
|
|
juliobbv
to be more precise: lines (esp. from the background) look significantly smoother on the encoded version
|
|
2025-05-25 09:53:47
|
That's just because I zoomed in 500% to make the yellow take up more of the screen. Here's the original and a distance 1 JXL encode.
At 100% Luma is negligible, while the main body gets a sickly blue hue, with yellow ringing around most edges and especially the veins on the left wing
Yes it's a dragon, the color just so happens to be perfect for reproducing the issue :P
|
|
2025-05-25 10:00:14
|
The desaturation seems to happen even at distance 0.2, though you wouldn't know unless you're looking for it, and have a particularly rich yellow. Could easily mess with production workflows though
|
|
2025-05-25 10:04:37
|
....God damn you color management
|
|
2025-05-25 10:06:56
|
Modular mode seemed to be doing far worse, but it's just Irfanview not handling modular XYB properly. The above images with VarDCT are valid though
|
|
2025-05-25 10:12:20
|
If you struggle to see it, get a color picker out and check the B value on the thigh. It should be low or near zero, but encoding shoots it up by a few dozen extra
|
|
|
Quackdoc
|
2025-05-25 10:27:10
|
I didnt read the context but hating on color management is based, remeber, friends don't let friends learn about color
|
|
|
|
Demiurge
|
|
_wb_
Yes. Well in principle it could also be applied to the DC of VarDCT images...
|
|
2025-05-25 12:30:45
|
That's right...
|
|
|
|
jonnyawsom3
|
|
Demiurge
That's right...
|
|
2025-05-25 01:11:12
|
Could it? The DC would surely have more than 256 colors, which seems to be the limit of greedy palette in it's current state
|
|
|
|
Demiurge
|
2025-05-25 01:12:11
|
Depends on how it looks! I assume almost anything is better than how it looks like now
|
|
2025-05-25 01:12:31
|
Remember delta palette is a thing too
|
|
2025-05-25 01:12:36
|
For filling in the gaps
|
|
|
|
juliobbv
|
|
That's just because I zoomed in 500% to make the yellow take up more of the screen. Here's the original and a distance 1 JXL encode.
At 100% Luma is negligible, while the main body gets a sickly blue hue, with yellow ringing around most edges and especially the veins on the left wing
Yes it's a dragon, the color just so happens to be perfect for reproducing the issue :P
|
|
2025-05-25 05:24:03
|
aaah, I see what you mean now
|
|
|
|
jonnyawsom3
|
|
Demiurge
Depends on how it looks! I assume almost anything is better than how it looks like now
|
|
2025-05-25 09:23:15
|
You do realise the DC has a major impact on image quality? Lowering it to 255 colors for a 256*256 area could cause major blocking. Delta palette is hardly explored, and encoding was even broken until my PR a few weeks ago, so it would drastically increase the amount of effort required
|
|
2025-05-25 09:27:48
|
You're functionally reducing the resolution from 1:8 to 1:128 instead in terms of colors. Again, assuming greedy palette is limited to 256 colors
|
|
|
|
Demiurge
|
|
You do realise the DC has a major impact on image quality? Lowering it to 255 colors for a 256*256 area could cause major blocking. Delta palette is hardly explored, and encoding was even broken until my PR a few weeks ago, so it would drastically increase the amount of effort required
|
|
2025-05-25 09:48:35
|
Of course. And if the DC colors look good without the desaturation issue then the final image wonβt have that issue either
|
|
|
|
juliobbv
|
|
That's just because I zoomed in 500% to make the yellow take up more of the screen. Here's the original and a distance 1 JXL encode.
At 100% Luma is negligible, while the main body gets a sickly blue hue, with yellow ringing around most edges and especially the veins on the left wing
Yes it's a dragon, the color just so happens to be perfect for reproducing the issue :P
|
|
2025-05-25 09:49:34
|
for my own education, does JXL have a way to control DC quant independently of AC quant?
|
|
|
|
Demiurge
|
2025-05-25 09:50:33
|
Improving the quality/bitrate of the DC image by whatever means necessary means good things for JXL
|
|
2025-05-25 09:52:02
|
If you can reduce the bitrate of the DC image or increase the quality at the same bitrate then that makes the rest of the job way easier
|
|
|
|
jonnyawsom3
|
|
juliobbv
for my own education, does JXL have a way to control DC quant independently of AC quant?
|
|
2025-05-25 10:02:22
|
Short awnser is: I have no idea
Long awnser: There's a few dozen quantization multiplier variables, along with the quant tables and a per-pixel adjustment variable Jyrki added.
We're not sure what knob is attached to what dial, but I'm sure there is somewhere
<@532010383041363969> would know
|
|
2025-05-25 10:07:29
|
Though while looking for DC quant adjustment, I did spot that B is encoded as B-Y. For saturated yellow, that would put B at -1 (B -0.2 - Y 0.8). Probably nothing, but thought I'd mention it
|
|
|
|
Demiurge
|
2025-05-25 11:12:21
|
You want the modular dc image to be very high fidelity and close to lossless, since any artifacts will be literally magnified and amplified.
|
|
2025-05-25 11:13:37
|
Actually can't the DC image be itself another recursive DCT image?
|
|
2025-05-25 11:13:47
|
I heard jxl can do that
|
|
2025-05-25 11:15:26
|
Well either way regardless of how many layers of recursion there has to be a modular frame somewhere I think
|
|
2025-05-25 11:17:38
|
The top-level DC image. So the near-lossless performance of modular is really important. Fidelity is even more important than small size for the DC image since the AC coefficients still take up the majority of the data.
|
|
2025-05-25 11:18:46
|
And the desaturation problem would have its root in the modular DC image.
|
|
|
|
jonnyawsom3
|
2025-05-25 11:19:00
|
Default is
Main VarDCT --> 1:8 Modular
Progressive is
Main VarDCT --> 1:8 VarDCT --> 1:64 Modular
Progressive_dc 2
Main VarDCT --> 1:8 VarDCT --> 1:64 VarDCT --> 1:512 Modular
|
|
|
|
Demiurge
|
2025-05-25 11:19:48
|
So bottom line is, the fidelity of modular is really, really important.
|
|
2025-05-25 11:20:08
|
Since the fidelity of DCT depends on it
|
|
2025-05-25 11:22:24
|
For large images, wouldn't progressive DC be more efficient bitrate wise?
|
|
2025-05-25 11:24:25
|
unless modular is really efficient at large photographic images.
|
|
2025-05-25 11:24:49
|
But theoretically, that's supposed to be DCT's specialty
|
|
|
|
jonnyawsom3
|
|
Demiurge
And the desaturation problem would have its root in the modular DC image.
|
|
2025-05-26 12:47:17
|
Did some testing separating the DC from the AC and comparing `-d 1` to `-d 0.1`. The B issue *is* present in the DC, but more localised to the spots/blotches. The AC seems to be causing the more widespread desaturation, likely due to the hard falloff in the quant table for B.
Original, Distance 1 DC, Distance 0.1 DC
|
|
2025-05-26 12:49:53
|
Original, Distance 1 DC, Distance 1 full
|
|
2025-05-26 12:50:46
|
Also, here's the Distance 1 and Distance 0.1 ACs
|
|
2025-05-26 12:53:26
|
So it seems like the DC is doing well enough, but the AC is causing more blue to be present, desaturating yellows
|
|
|
|
Demiurge
|
2025-05-26 12:54:47
|
But the AC wouldn't be able to change the overall color/saturation of the whole image at a distance like that... The desaturation is still noticeable even when viewing the image zoomed out at 1/8th size
|
|
|
|
jonnyawsom3
|
2025-05-26 12:57:02
|
It's not the whole image though, specifically yellows are the hardest, because the B value in XYB only has to be off by 1 or 2 to cause RGB to go up by 20-30, so it's not surprising the AC could be getting that error
|
|
|
|
Demiurge
|
2025-05-26 12:59:19
|
If you can notice the desaturation from far away even in large solid fields of color as well, then you can conclusively say the problem happens in the modular DC image
|
|
2025-05-26 01:00:00
|
So the fidelity of modular mode needs to be improved
|
|
2025-05-26 01:00:38
|
The modular DC image needs to be lossless or close to lossless
|
|
|
|
jonnyawsom3
|
2025-05-26 01:02:03
|
Did you even look at the images? Both of the DCs are saturated properly, when the AC is added it's desaturated
|
|
|
|
Demiurge
|
2025-05-26 01:05:12
|
I can't do a flicker test since I'm on my phone. It's hard for me to notice the desaturation.
|
|
|
|
jonnyawsom3
|
|
Demiurge
I can't do a flicker test since I'm on my phone. It's hard for me to notice the desaturation.
|
|
2025-05-26 01:05:38
|
You can drag the small previews at the bottom to do a flicker test
|
|
|
|
Demiurge
|
2025-05-26 01:05:48
|
But didn't you post a solid color square too earlier
|
|
2025-05-26 01:05:58
|
And show the desaturation problem
|
|
2025-05-26 01:06:08
|
How is AC supposed to cause that
|
|
|
|
jonnyawsom3
|
2025-05-26 01:06:35
|
The solid square wasn't even a JXL, it was a demonstration of a single value change in B desaturating yellow
|
|
|
|
Demiurge
|
2025-05-26 01:08:36
|
Oh
|
|
2025-05-26 01:09:12
|
I'll have to test this when I'm on the PC again
|
|
|
|
jonnyawsom3
|
2025-05-26 01:27:41
|
Disable patches and dots, then you can see the desaturation really clearly on here, presumably because it's mostly AC
|
|
|
|
Jyrki Alakuijala
|
|
Disable patches and dots, then you can see the desaturation really clearly on here, presumably because it's mostly AC
|
|
2025-05-26 05:53:21
|
the IsPixelized heuristics should trigger maximally for that image and increase the x and b accuracy
I will study this today or tomorrow
|
|
|
|
jonnyawsom3
|
|
Jyrki Alakuijala
the IsPixelized heuristics should trigger maximally for that image and increase the x and b accuracy
I will study this today or tomorrow
|
|
2025-05-26 06:10:20
|
Comparing to older builds before those heuristics, I think it is triggering, but the accuracy is still too low.
When images are so pixelated/sharp, modular would be better used anyway, no? (Of course this image is best lossless, but more generally lossy should work)
|
|
2025-05-26 06:15:28
|
Modular has better sharpness, but further desaturates Blue, Yellow, Red and Green (Intensity in that order) due to the higher error in B.
This is Original, `-d 1` and `-d 0.3 -m 1` (at under half the filesize of `-d 1`)
|
|
|
|
Jyrki Alakuijala
|
|
Modular has better sharpness, but further desaturates Blue, Yellow, Red and Green (Intensity in that order) due to the higher error in B.
This is Original, `-d 1` and `-d 0.3 -m 1` (at under half the filesize of `-d 1`)
|
|
2025-05-26 09:21:21
|
this is interesting
|
|
2025-05-26 10:59:50
|
I think I need more help with understanding the desaturation
|
|
|
|
jonnyawsom3
|
|
Jyrki Alakuijala
I don't see a difference
|
|
2025-05-26 11:22:34
|
What I find interesting, is that you don't seem to be as sensitive to it as the rest of us. Makes me wonder if it's an issue with the example image, the hardware, or our eyes are simply different. Regardless, it could make it a lot harder for you to test
|
|
|
|
Demiurge
|
|
Jyrki Alakuijala
the IsPixelized heuristics should trigger maximally for that image and increase the x and b accuracy
I will study this today or tomorrow
|
|
2025-05-26 11:44:15
|
I didn't know libjxl used heuristics to classify the image.
|
|
2025-05-26 11:44:24
|
That's cool
|
|
|
|
jonnyawsom3
|
2025-05-26 11:53:30
|
The easiest way to test for the desaturation, without relying on flicker tests or certain zoom levels, is simply checking the B value in the final (s)RGB decode. As I've said before, increasing the B in XYB by 1, increases B in RGB by around 10 or more. So the error in the AC (and DC) is being increased by an order of magnitude for yellow
|
|
|
|
CrushedAsian255
|
|
The easiest way to test for the desaturation, without relying on flicker tests or certain zoom levels, is simply checking the B value in the final (s)RGB decode. As I've said before, increasing the B in XYB by 1, increases B in RGB by around 10 or more. So the error in the AC (and DC) is being increased by an order of magnitude for yellow
|
|
2025-05-26 12:49:33
|
Does XYB have βunitsβ like that? Isnβt it all floating point?
|
|
|
|
jonnyawsom3
|
|
CrushedAsian255
Does XYB have βunitsβ like that? Isnβt it all floating point?
|
|
2025-05-26 12:51:04
|
Scaling it to 0-255 for 8 bit input/output, those are the results
|
|
|
|
juliobbv
|
|
The easiest way to test for the desaturation, without relying on flicker tests or certain zoom levels, is simply checking the B value in the final (s)RGB decode. As I've said before, increasing the B in XYB by 1, increases B in RGB by around 10 or more. So the error in the AC (and DC) is being increased by an order of magnitude for yellow
|
|
2025-05-26 08:28:34
|
are you increasing B pre, or post-quantization? having such a large jump result in RGB sounds like a lot (but I'm not a color expert)
|
|
|
|
jonnyawsom3
|
|
juliobbv
are you increasing B pre, or post-quantization? having such a large jump result in RGB sounds like a lot (but I'm not a color expert)
|
|
2025-05-26 09:16:58
|
Pre, I suppose. It was purely a test of the XYB transform without encoding, since trying to get raw XYB values out of the JXL is considerably harder due to defaulting to sRGB https://discord.com/channels/794206087879852103/794206170445119489/1375335077071814736
|
|
2025-05-26 09:18:37
|
I made a paletted PNG with the XYB ICC from jpegli, so RGB directly corresponds to XYB, and can be changed by editing the palette entry
|
|
2025-05-26 09:22:45
|
When comparing the AC and the DC of different qualities under difference masks, most of the error is in the blue channel, so while I don't have the exact XYB values to prove it, the results do align with my findings https://discord.com/channels/794206087879852103/794206170445119489/1376361013175259237
|
|
|
|
juliobbv
|
|
Pre, I suppose. It was purely a test of the XYB transform without encoding, since trying to get raw XYB values out of the JXL is considerably harder due to defaulting to sRGB https://discord.com/channels/794206087879852103/794206170445119489/1375335077071814736
|
|
2025-05-26 09:30:32
|
oh yeah, that's pre for sure
|
|
2025-05-26 09:33:36
|
it seems like the B channel isn't granular enough to capture minimal units of change
|
|
2025-05-26 09:33:53
|
what happens if you force JXL to encode the image in YCbCr?
|
|
2025-05-26 09:34:13
|
does the desaturation improve?
|
|
|
|
jonnyawsom3
|
|
juliobbv
what happens if you force JXL to encode the image in YCbCr?
|
|
2025-05-26 09:37:05
|
AFAIK, that's simply not a valid option. YCbCr is only available for JPEG Transcoding, encoding to it in JPEG XL isn't possible.
Jpegli on the other hand, *can* encode to both, and YCbCr doesn't have the desaturation (from what I recall)
|
|
2025-05-26 09:39:56
|
I think it's because for saturated areas, it's large sections of the same, low B value. The hard quant table falloff for LF then hits it, causing too much rounding... Perhaps. I have no way to test it other than comparing AC and DC like before, or digging through the code and manually changing unknown values
|
|
|
|
CrushedAsian255
|
|
AFAIK, that's simply not a valid option. YCbCr is only available for JPEG Transcoding, encoding to it in JPEG XL isn't possible.
Jpegli on the other hand, *can* encode to both, and YCbCr doesn't have the desaturation (from what I recall)
|
|
2025-05-27 01:59:14
|
is that a limitation of cjxl or a limitation of the jpeg xl format itself?
|
|
|
|
jonnyawsom3
|
|
CrushedAsian255
is that a limitation of cjxl or a limitation of the jpeg xl format itself?
|
|
2025-05-27 02:01:19
|
Libjxl, though spec may only allow you to use features equilavent to JPEG transcoding (8x8 max, ect)
|
|
2025-05-27 02:50:08
|
Read the spec, looks like YCbCr *is* fine to use instead of XYB, it's just not implemented in any encoder currently AFAIK
|
|
|
|
Quackdoc
|
2025-05-27 02:56:22
|
~~need xyb422 and xyb420~~
|
|
2025-05-27 02:57:03
|
speaking of, is this accurate? https://gist.github.com/mattdesl/c0ad8d54b3491c7fd39e222e698b2a30
|
|
2025-05-27 02:58:44
|
there was also this https://gist.github.com/facelessuser/c769cecafc8071de6f73da7dcd45f7ba
|
|
|
|
jonnyawsom3
|
|
Quackdoc
~~need xyb422 and xyb420~~
|
|
2025-05-27 03:33:28
|
jpegli π
|
|
2025-05-27 03:33:40
|
Oh right, I was meant to split my PR about fixing the subsampling...
|
|
|
|
Quackdoc
|
|
|
Jyrki Alakuijala
|
|
The easiest way to test for the desaturation, without relying on flicker tests or certain zoom levels, is simply checking the B value in the final (s)RGB decode. As I've said before, increasing the B in XYB by 1, increases B in RGB by around 10 or more. So the error in the AC (and DC) is being increased by an order of magnitude for yellow
|
|
2025-05-27 04:20:17
|
Does it mean that desaturation is difficult to see?
|
|
|
What I find interesting, is that you don't seem to be as sensitive to it as the rest of us. Makes me wonder if it's an issue with the example image, the hardware, or our eyes are simply different. Regardless, it could make it a lot harder for you to test
|
|
2025-05-27 04:23:06
|
Are you available for a VC to teach me, or make a beginners how-to-detect-desaturation doc for me?
|
|
|
|
jonnyawsom3
|
|
Jyrki Alakuijala
Are you available for a VC to teach me, or make a beginners how-to-detect-desaturation doc for me?
|
|
2025-05-27 04:38:22
|
I'm available, though we could also discuss the desaturation in the server voice channel. Then others can give input too
|
|
2025-05-27 05:07:25
|
Doing some more light testing, I'm noticing it on any image with Yellow/Orange, but it's hard to notice unless you know what the color is *meant* to look like. It could be argued that means it's good enough, but Distance 1 is meant to be visually lossless, and this is the only area that I can see degradation at 100%
|
|
2025-05-27 05:31:19
|
Hmm, maybe I should move the talk to another time. It'd be better to test desaturation when my eyes aren't tired haha. Been with Americans lately, so sleep is upside down
|
|
|
|
Jyrki Alakuijala
|
2025-05-27 10:24:28
|
Yes, lets book a time for it
|
|
|
|
CrushedAsian255
|
2025-05-27 10:40:23
|
if possible can someone record it? it sounds like a helpful resource
|
|
|
|
jonnyawsom3
|
2025-05-27 10:58:04
|
Most of my work has been with <@207980494892040194> and <@245794734788837387> giving input, so arranging a time to meet in the server VC and discuss things would be nice. I'm sure someone could record if <@532010383041363969> doesn't mind, though it'll mostly be back and forth discussion of compression artifacts and mitigations for them. Not sure how long it will go on for either, since there could be quite a lot to discuss depending on our ideas.
|
|
2025-05-27 11:26:40
|
*Yet another* test, and I think Jon was right in his first assessment. The AC of B needs more bits. I can see the AC is visibly more red/yellow in the higher quality JXL. The DC is *very* slightly desaturated, but most seems to be in the AC
|
|
|
|
Jyrki Alakuijala
|
|
CrushedAsian255
if possible can someone record it? it sounds like a helpful resource
|
|
2025-05-27 01:30:34
|
it feels like you expect gurus discussing photons and probability distributions, whereas in reality it will be like two villagers discussing if it will rain tomorrow based on how many frogs they have seen πΈ πΈ πΈ πΈ πΈ πΈ πΈ
|
|
|
|
CrushedAsian255
|
|
Jyrki Alakuijala
it feels like you expect gurus discussing photons and probability distributions, whereas in reality it will be like two villagers discussing if it will rain tomorrow based on how many frogs they have seen πΈ πΈ πΈ πΈ πΈ πΈ πΈ
|
|
2025-05-27 01:32:16
|
Iβm also not great at differentiating and visually detecting artifacts in compression
|
|
2025-05-27 01:32:22
|
(the main reason why I stick with lossless)
|
|
|
|
jonnyawsom3
|
|
Jyrki Alakuijala
it feels like you expect gurus discussing photons and probability distributions, whereas in reality it will be like two villagers discussing if it will rain tomorrow based on how many frogs they have seen πΈ πΈ πΈ πΈ πΈ πΈ πΈ
|
|
2025-05-27 01:37:10
|
Ah ha! That was the issue, we've been using fox based compression instead of frog based compression
|
|
|
|
juliobbv
|
|
Jyrki Alakuijala
it feels like you expect gurus discussing photons and probability distributions, whereas in reality it will be like two villagers discussing if it will rain tomorrow based on how many frogs they have seen πΈ πΈ πΈ πΈ πΈ πΈ πΈ
|
|
2025-05-27 09:29:23
|
Don't undersell yourself. It's more two villagers discussing if it will rain based on the intensity of the petrichor smell.
|
|
|
|
Jyrki Alakuijala
|
2025-05-28 02:12:05
|
let's summon the etymology man: Petrichor (/ΛpΙtrΙͺkΙΛr/ PET-rih-kor)[1] is the earthy scent produced when rain falls on dry soil. The word was coined by Isabel Joy Bear and Richard Grenfell Thomas[2] from Ancient Greek ΟΞΟΟΞ± (pΓ©tra) 'rock' or ΟΞΟΟΞΏΟ (pΓ©tros) 'stone' and αΌ°ΟΟΟ (ikhαΉr), the ethereal fluid that is the blood of the gods in Greek mythology.
|
|
2025-05-28 06:05:09
|
I found a nice logical improvement to blue color
|
|
2025-05-28 06:06:41
|
Instead of stacking the blue color correction to the high frequency luma correction, I just take the maximum of them.
|
|
2025-05-28 06:07:19
|
R-g correction might become sensible with the same logic
|
|
2025-05-28 06:08:18
|
It gives 1 % improvement on max error and .15 on ssimulacra
|
|
2025-05-28 06:09:31
|
At first look images looked better, but need to study it more...
|
|
2025-05-28 06:11:18
|
layman language explanation: Exposed blue color demands a certain precision β if that precision is already achieved through HF luma precision corrections, no need to pump it more
|
|
|
|
jonnyawsom3
|
2025-06-01 05:18:39
|
<@&807636211489177661> we've got another scam
|
|
|
|
_wb_
|
2025-06-01 05:20:06
|
<:BanHammer:805396864639565834>
|
|
|
AccessViolation_
|
2025-06-01 05:49:03
|
happy pride month
|
|
|
|
juliobbv
|
|
|
Jyrki Alakuijala
|
2025-06-03 05:44:26
|
https://github.com/libjxl/libjxl/pull/4276 slightly better colors and sharpness in JXL
|
|
2025-06-03 06:02:12
|
I consider the improvement substantial in 1.5 to 3.0 distances, and this new philosophy of maxing different component needs instead of multiplying them likely opens up new ways of improving the adaptive quantization
|
|
2025-06-03 06:02:36
|
I'm anticipating finding another similar improvement next week
|
|
2025-06-03 09:07:27
|
Merged π
|
|
2025-06-03 11:23:47
|
Please give feedback
|
|
2025-06-03 12:19:54
|
next up: I'll try to hack up a red-green optimization system in the enc_adaptive_quantization.cc -- I have had it there twice in the past and ended up removing it because of the relatively low gains, but in the past it was a multiplicative system, now I'll try it as a max with blue and hf, which I find more correct philosophically/logically
|
|
|
farter
|
2025-06-03 01:51:17
|
playing on squoosh with some random test case, but found interesting artifact on the jxl side, the mysterious scarlet mist incident at the lower corner of blue and green ones
|
|
2025-06-03 01:55:01
|
source image
|
|
|
|
Jyrki Alakuijala
|
2025-06-03 01:55:23
|
I think I have improved this, and squoosh usually is a lot behind -- I wouldn't be surprised if they were running something like 0.9 (edit: turns out it is much much older than I guessed)
|
|
|
Kupitman
|
|
farter
playing on squoosh with some random test case, but found interesting artifact on the jxl side, the mysterious scarlet mist incident at the lower corner of blue and green ones
|
|
2025-06-03 01:55:48
|
HOOOW
|
|
2025-06-03 01:56:05
|
Squoosh updated??
|
|
|
|
farter
|
2025-06-03 01:56:41
|
got it, i'll try latest
|
|
|
|
jonnyawsom3
|
|
Jyrki Alakuijala
I think I have improved this, and squoosh usually is a lot behind -- I wouldn't be surprised if they were running something like 0.9 (edit: turns out it is much much older than I guessed)
|
|
2025-06-03 02:06:00
|
Far *far* older than that. It's using this commit from over 3 years ago https://github.com/libjxl/libjxl/commit/9f544641ec83f6abd9da598bdd08178ee8a003e0
|
|
|
farter
source image
|
|
2025-06-03 02:08:16
|
Also, that could probably be represented as JXL art with enough time
|
|
|
|
farter
|
2025-06-03 03:35:36
|
that'll be cool. though didn't read the code yet, can we rotate patches(are they alreadythere?) by 60Β°, and are they in rgba/xyba?
|
|
|
|
_wb_
|
2025-06-03 03:48:50
|
no, patches cannot be rotated, not even by 90 degrees
|
|
2025-06-03 03:50:02
|
but still there is plenty of structure here that could probably be exploited by MA trees and/or patches
|
|
|
monad
|
|
Jyrki Alakuijala
Please give feedback
|
|
2025-06-03 11:31:35
|
I compared latest at d1 and 1.5 against May 12 version at minimal byte advantage. I saw an obvious improvement on a Minecraft screenshot. On a few other 3D game screenshots the difference at d1 was usually too subtle to judge. At d1.5 I saw a slight overall improvement with careful inspection.
|
|
|
|
CrushedAsian255
|
|
_wb_
no, patches cannot be rotated, not even by 90 degrees
|
|
2025-06-04 01:03:10
|
was this due to it being too expensive to do
|
|
2025-06-04 01:03:29
|
(and makes it too much like a AV1 I-frame lol)
|
|
|
|
Jyrki Alakuijala
|
|
monad
I compared latest at d1 and 1.5 against May 12 version at minimal byte advantage. I saw an obvious improvement on a Minecraft screenshot. On a few other 3D game screenshots the difference at d1 was usually too subtle to judge. At d1.5 I saw a slight overall improvement with careful inspection.
|
|
2025-06-04 05:00:17
|
I try to walk the narrow path of making meaningful changes but not spoiling where JPEG XL is already good. I feel I managed to do that pretty well this time with general minimal impact, but addressing the weaknesses (chromacity bleaching and blurring)
|
|
|
CrushedAsian255
was this due to it being too expensive to do
|
|
2025-06-04 09:19:06
|
I tried to add patches with affine-like mapping -- I had a junior engineer exploring it for 3 months and nothing useful came out so we dropped that and went with a more simple approach
|
|
2025-06-04 09:20:11
|
I think in the end we dismissed quite a few potentially good approaches just because we were not able to make them work even with three tries
|
|
2025-06-04 09:20:23
|
luckily we were able to make many new approaches work, too π
|
|
2025-06-04 09:20:44
|
also a codec is balancing the complexity of decoding vs. performance in different situations
|
|
2025-06-04 09:21:21
|
I was valuing a lot the distance 0.5-2 space and if a technique would give gains at distance 5 only, it wouldn't make it
|
|
2025-06-04 09:21:38
|
(or just for some peculiar images that are not the usual photographs)
|
|
|
|
Demiurge
|
2025-06-04 11:24:03
|
Could someone post some before/after pictures? I haven't had a chance to be at my PC for a while but if someone posts some before/after comparisons I can critique the changes.
|
|
|
|
jonnyawsom3
|
2025-06-04 08:56:58
|
I'd actually say it's less sharp on my image, though the chroma is *very* slightly better with less blue artifacts, but still desaturated
Original, Previous, New at 500%
|
|
2025-06-04 09:01:17
|
Definitely an improvement, especially considering it's almost 10% smaller too at distance 1, but the saturation may require either custom quant tables or custom XYB transfer if B can't be given higher quality AC otherwise
|
|
|
|
monad
|
2025-06-04 09:50:51
|
Is there a practical impetus for zooming so much and comparing such differently sized outputs?
|
|
|
|
Demiurge
|
|
I'd actually say it's less sharp on my image, though the chroma is *very* slightly better with less blue artifacts, but still desaturated
Original, Previous, New at 500%
|
|
2025-06-04 09:50:54
|
1 is original, 2 is superior, 3 is inferior.
|
|
2025-06-04 09:52:14
|
The green background has much less definition.
|
|
2025-06-04 09:52:23
|
Especially near the interior of the elbow joint
|
|
|
|
jonnyawsom3
|
|
monad
Is there a practical impetus for zooming so much and comparing such differently sized outputs?
|
|
2025-06-04 09:52:36
|
Avoiding decisions based on display and viewing conditions instead of actual encoding quality
What to expect when using the same settings like a normal user, instead of constantly changing the distance to adjust for the new bpp
|
|
|
|
CrushedAsian255
|
2025-06-04 09:55:26
|
To be honest I literally can't tell a difference between all 3 π¦
|
|
|
username
|
2025-06-04 09:55:56
|
|
|
2025-06-04 09:55:56
|
test this image (in relation to the desaturation issues)
|
|
2025-06-04 09:56:54
|
(source vs default cjxl settings)
|
|
|
|
jonnyawsom3
|
2025-06-04 10:05:21
|
For Monad's sanity
Original, 0.8, 0.11 and main with (roughly) matched bpp
|
|
|
|
monad
|
|
Avoiding decisions based on display and viewing conditions instead of actual encoding quality
What to expect when using the same settings like a normal user, instead of constantly changing the distance to adjust for the new bpp
|
|
2025-06-04 10:06:05
|
I just wonder the relevance of distortions otherwise imperceptible at the target viewing distance. I see local improvements and local regressions, so I might suspect if the distortions are too much on latest you could increase the byte allowance to mitigate them. Same sized outputs should better inform about encoder efficiency.
|
|
|
|
jonnyawsom3
|
2025-06-04 10:08:01
|
It seems to be 2 steps forward, 1 step back. 0.11 has sharper lines on the right than 0.8, but introduced the blue chroma noise, and main removes the noise but blurs the lines worse than 0.8
|
|
|
|
monad
|
2025-06-04 10:11:54
|
I compared 0.8 too against latest at d1.5. I saw it is sometimes much better, sometimes much worse.
|
|
|
|
jonnyawsom3
|
2025-06-04 10:13:42
|
I noticed that since 0.8, the encoder seems to 'detect' sharp lines and text, devoting most of the bits to preserving them
Extreme distance 10 example but shows it well
|
|
|
|
monad
|
2025-06-04 10:14:45
|
That's pretty cool.
|
|
|
|
jonnyawsom3
|
2025-06-04 10:14:50
|
License plate, lights and the first two words on the yellow strip are all quite sharp, while the rest is obliterated
|
|
2025-06-04 10:16:31
|
From <https://github.com/libjxl/libjxl/pull/4147>
|
|
2025-06-04 10:17:37
|
The intricate pattern at the top was preserved, but the plants turned into plastic
|
|
|
For Monad's sanity
Original, 0.8, 0.11 and main with (roughly) matched bpp
|
|
2025-06-04 10:29:37
|
Here are the full images. 0.8 is still much shaper than main, especially in dark areas
|
|
2025-06-04 10:30:36
|
|
|
|
|
Demiurge
|
|
username
(source vs default cjxl settings)
|
|
2025-06-04 11:04:54
|
Damn. Even on my iPhone, flipping between them, side by side, without even a flicker test, the desaturation is extreme and unacceptable.
|
|
2025-06-04 11:05:31
|
It's like the jxl compression completely changes the colors and butchers the image
|
|
2025-06-04 11:07:22
|
It looks less warm orange and yellow and more blue
|
|
2025-06-04 11:08:34
|
Is that with latest commit or 0.11?
|
|
|
|
jonnyawsom3
|
2025-06-04 11:09:01
|
Almost as if the B channel is being increased, like I've been saying for the past month <:SupremelyDispleased:1368821202969432177>
|
|
|
|
username
|
|
Demiurge
Is that with latest commit or 0.11?
|
|
2025-06-04 11:09:43
|
latest commit (https://github.com/libjxl/libjxl/commit/dc8438add651ef5b2ef4cf9b44a495f7a6d6727d)
|
|
|
|
jonnyawsom3
|
|
Demiurge
Is that with latest commit or 0.11?
|
|
2025-06-04 11:10:00
|
It's present since v0.6
|
|
|
|
Demiurge
|
2025-06-04 11:10:17
|
I would say that it's not any closer to being solved or improved.
|
|
|
Here are the full images. 0.8 is still much shaper than main, especially in dark areas
|
|
2025-06-04 11:18:07
|
idk why but the original is a completely different brightness/gamma curve compared to the rest, at least in firefox.
|
|
|
|
jonnyawsom3
|
|
Demiurge
idk why but the original is a completely different brightness/gamma curve compared to the rest, at least in firefox.
|
|
2025-06-04 11:24:41
|
djxl added a gAMA chunk along with the sRGB chunk. The gamma should be ignored but Firefox is dumb
|
|
|
|
Demiurge
|
2025-06-04 11:27:44
|
For what it's worth I don't like how 0.8 looks in that comparison.
|
|
2025-06-04 11:29:45
|
https://raw.githubusercontent.com/afontenot/image-formats-comparison/refs/heads/master/comparisonfiles/subset1/original/Clovisfest.png
|
|
2025-06-04 11:30:07
|
Could someone try using this image please for comparison sake πΉ
|
|
|
|
jonnyawsom3
|
|
Demiurge
For what it's worth I don't like how 0.8 looks in that comparison.
|
|
2025-06-04 11:33:41
|
What about it?
|
|
|
|
monad
|
|
Demiurge
Could someone try using this image please for comparison sake πΉ
|
|
2025-06-04 11:46:38
|
May 12 at 74504 B d2.081 vs June 3 at 74489 B d2
|
|
|
|
Demiurge
|
2025-06-05 12:01:05
|
Wow, nice, a definite improvement!
|
|
2025-06-05 12:01:18
|
π
|
|
2025-06-05 12:01:29
|
I like it
|
|
2025-06-05 12:04:52
|
The desaturation problem is still there. I can understand that not everyone can notice the desaturation because it's subtle and probably sensitive to viewing environment. But the ringing is improved for sure.
|
|
2025-06-05 12:05:20
|
Thanks monad!
|
|
|
What about it?
|
|
2025-06-05 12:11:21
|
Hmm. Many parts of the image look slightly more softened up in the 0.8 version compared to the other two. Overall I think the `main.png` looks best and most faithfully preserves the information in the original.
|
|
2025-06-05 12:13:10
|
Hmm. Overall, the reduction in ringing is a significant achievement, since the chroma ringing is one of the "big 3" major quality issues I've identified in libjxl.
|
|
|
A homosapien
|
2025-06-05 12:14:28
|
My TF2 benchmark image still shows that main still falls behind 0.8. There might still be a gap to be closed, but I have to do more benchmarking on my test set.
|
|
|
|
Demiurge
|
2025-06-05 12:14:33
|
The other two major issues are the de-saturation issue and the blurry shadows issue, but it's hard to pin down and give good examples of that last one.
|
|
|
|
CrushedAsian255
|
2025-06-05 12:14:43
|
what is stopping libjxl from just yoinking the tuning from avif?
|
|
|
|
Demiurge
|
2025-06-05 12:15:05
|
If anyone has a good example image that demonstrates blurry shadows in dark image regions, please share with the class πΉ
|
|
|
|
jonnyawsom3
|
|
Demiurge
Hmm. Many parts of the image look slightly more softened up in the 0.8 version compared to the other two. Overall I think the `main.png` looks best and most faithfully preserves the information in the original.
|
|
2025-06-05 12:16:05
|
That's exactly the opposite conclusion I came to... You sure it's not the Gamma or monitor again?
|
|
|
|
Demiurge
|
|
CrushedAsian255
what is stopping libjxl from just yoinking the tuning from avif?
|
|
2025-06-05 12:17:08
|
Unfortunately it's not that easy. The best analogy I can think of is trying to implant a shellfish organ into a human body.
|
|
|
|
monad
|
2025-06-05 12:17:13
|
Original, May 12 at 339709 B d2.1831, June 3 at 339693 B d2. Another example where color shifting is still apparent, but the image reads much less blurry overall.
|
|
|
|
Demiurge
|
|
That's exactly the opposite conclusion I came to... You sure it's not the Gamma or monitor again?
|
|
2025-06-05 12:17:28
|
It could be...
|
|
|
Here are the full images. 0.8 is still much shaper than main, especially in dark areas
|
|
2025-06-05 12:18:19
|
To be fair, the difference here is extremely subtle and probably very dependent on viewing environment.
|
|
|
|
jonnyawsom3
|
|
CrushedAsian255
what is stopping libjxl from just yoinking the tuning from avif?
|
|
2025-06-05 12:19:01
|
AFAIK they're now exploring JXL tuning too, but might take a while due to all the coding tools and Jyrki's custom encoding methods
|
|
|
|
Demiurge
|
|
monad
Original, May 12 at 339709 B d2.1831, June 3 at 339693 B d2. Another example where color shifting is still apparent, but the image reads much less blurry overall.
|
|
2025-06-05 12:20:01
|
Yes, a massive improvement...
|
|
2025-06-05 12:20:34
|
The desaturation issue is unchanged but it's still a massive improvement
|
|
|
|
jonnyawsom3
|
|
Demiurge
To be fair, the difference here is extremely subtle and probably very dependent on viewing environment.
|
|
2025-06-05 12:20:36
|
I can see it at 25% zoom, so I wouldn't call that subtle
|
|
|
|
Demiurge
|
|
I can see it at 25% zoom, so I wouldn't call that subtle
|
|
2025-06-05 12:21:06
|
Really? For me, all 4 dragons look very hard to tell apart π²
|
|
2025-06-05 12:21:32
|
Compared to the Minecraft image, where the difference is screamingly loud like night and day
|
|
2025-06-05 12:22:35
|
I have to zoom in to notice any differences on the dragon image.
|
|
2025-06-05 02:37:10
|
And I consider myself a dragon expert! π
|
|
|
|
Jyrki Alakuijala
|
|
I noticed that since 0.8, the encoder seems to 'detect' sharp lines and text, devoting most of the bits to preserving them
Extreme distance 10 example but shows it well
|
|
2025-06-05 09:07:29
|
I had a lot of focus on that in 0.8, all those crazy distance even to d128 -- because AVIF is very very good at preserving some small black-n-white details while blurring the heck out of the general image, to be a bit more like AVIF was -- nowadays I don't optimize for that, I try to optimize more for d0.5 to d3, where such compromises and special heuristics are less necessary
|
|
|
|
Orum
|
2025-06-05 09:16:59
|
yeah I think that makes sense; let AVIF do what AVIF is good at, and let JXL do what it's good at
|
|
|
|
Jyrki Alakuijala
|
|
Demiurge
I would say that it's not any closer to being solved or improved.
|
|
2025-06-05 09:24:04
|
I appreciate that people are voicing their honest opinions here! Thank you.
|
|
|
Orum
yeah I think that makes sense; let AVIF do what AVIF is good at, and let JXL do what it's good at
|
|
2025-06-05 09:25:13
|
yes, we will never win the d128 war if such a war comes up :-D, likely not even d7, the strengths of JPEG XL are somewhere around d2
|
|
2025-06-05 09:26:00
|
AVIF has the local palettes and can wedge split the DC -- these are useless at higher quality, but great at low quality
|
|
2025-06-05 09:28:37
|
iirc, local palette is 8 colors, which works ok up to a certain level of quality -- but when the ninth color exists, it must be clustered into one of the eight
|
|
2025-06-05 09:29:23
|
this kind of features only work to a specific quality and are more or less useless at higher quality
|
|
2025-06-05 09:30:03
|
the same for the wedges -- they approximate the edges and a slightly faulty approximation only adds to entropy when it needs to be gotten right at higher quality
|
|
|
|
_wb_
|
2025-06-05 09:55:51
|
There's enough bitstream expressivity in jxl to do something like local palettes using patches. Currently we only use patches to deduplicate repeating stuff, but it's perfectly possible to use them also for preserving some details that are expensive with dct using modular techniques. The main challenge is to make an encoder that detects cases where this is useful, i.e. actually saves bits and improves quality.
In AVIF it's a bit easier to just exhaustively try stuff because the bitstream has limited expressivity: palette blocks are just another block type and their cost can be estimated immediately because entropy coding is simple. In jxl patches do not have to be aligned with the block grid, they are not limited to a small number of colors, they are blended so you can do other things than kReplace, and their cost cannot easily be estimated due to way more advanced entropy coding β these are all things that make it much harder to make an encoder that exploits the bitstream potential.
(the same is true for splines btw)
|
|
|
|
CrushedAsian255
|
|
_wb_
There's enough bitstream expressivity in jxl to do something like local palettes using patches. Currently we only use patches to deduplicate repeating stuff, but it's perfectly possible to use them also for preserving some details that are expensive with dct using modular techniques. The main challenge is to make an encoder that detects cases where this is useful, i.e. actually saves bits and improves quality.
In AVIF it's a bit easier to just exhaustively try stuff because the bitstream has limited expressivity: palette blocks are just another block type and their cost can be estimated immediately because entropy coding is simple. In jxl patches do not have to be aligned with the block grid, they are not limited to a small number of colors, they are blended so you can do other things than kReplace, and their cost cannot easily be estimated due to way more advanced entropy coding β these are all things that make it much harder to make an encoder that exploits the bitstream potential.
(the same is true for splines btw)
|
|
2025-06-05 10:12:44
|
so you believe JPEG XL could be competitive at really high distances if a specialised encoder was built to take advantage of all the features of JPEG XL?
|
|
2025-06-05 10:13:01
|
also remember delta palette can do fun things
|
|
|
|
A homosapien
|
2025-06-05 10:22:38
|
Lossy modular is quite capable, however a major downside is the decrease in decode speeds.
|
|
|
|
jonnyawsom3
|
|
A homosapien
Lossy modular is quite capable, however a major downside is the decrease in decode speeds.
|
|
2025-06-05 11:07:46
|
I haven't checked, but based on our work for lossless progressive and faster decoding, could it be because libjxl is so slow at Squeeze?
|
|
|
|
_wb_
|
2025-06-05 11:10:20
|
Squeeze is a bit tricky to SIMD and multithread. I'm not sure how much room for decode speed improvement there is.
|
|
|
|
CrushedAsian255
|
2025-06-05 11:11:05
|
it doesn't seem too complex to SIMD, isn't it taking two small images and turning it into 1 image twice the size?
|
|
|
|
_wb_
|
2025-06-05 11:11:45
|
(besides the specialization to do everything on `int16` instead of `int32` when possible, which should suffice for lossy modular)
|
|
|
|
jonnyawsom3
|
|
_wb_
Squeeze is a bit tricky to SIMD and multithread. I'm not sure how much room for decode speed improvement there is.
|
|
2025-06-05 11:12:11
|
Oxide manages roughly 2x faster for progressive lossless
|
|
|
|
_wb_
|
|
CrushedAsian255
it doesn't seem too complex to SIMD, isn't it taking two small images and turning it into 1 image twice the size?
|
|
2025-06-05 11:12:49
|
the data dependencies of the tendency term are somewhat annoying
|
|
|
|
CrushedAsian255
|
|
_wb_
(besides the specialization to do everything on `int16` instead of `int32` when possible, which should suffice for lossy modular)
|
|
2025-06-05 11:12:50
|
Does reducing the bit width save significant performance on 64 bit CP? Or is it the decrease in memory reads
|
|
|
|
_wb_
|
2025-06-05 11:14:26
|
reducing the bit width mostly allows doubling the lanes in SIMD and reducing the memory bus load
|
|
|
|
jonnyawsom3
|
|
Oxide manages roughly 2x faster for progressive lossless
|
|
2025-06-05 11:17:32
|
https://discord.com/channels/794206087879852103/1065165415598272582/1359975123834376192
|
|
|
|
_wb_
|
2025-06-05 11:19:22
|
could be worth figuring out how jxl-oxide manages to be that much faster and see if libjxl can be sped up too
|
|
|
Tirr
|
2025-06-05 11:28:06
|
jxl-oxide manages to unsqueeze in-place with small scratch buffer, maybe that plays some role
|
|
|
|
CrushedAsian255
|
2025-06-05 11:33:45
|
Is Squeeze an approximate algorithm or bit-exact over integers?
|
|
|
|
Tirr
|
2025-06-05 11:36:59
|
...or not in-place, it has been a while after I rewrote unsqueeze
|
|
|
|
jonnyawsom3
|
|
Jyrki Alakuijala
I had a lot of focus on that in 0.8, all those crazy distance even to d128 -- because AVIF is very very good at preserving some small black-n-white details while blurring the heck out of the general image, to be a bit more like AVIF was -- nowadays I don't optimize for that, I try to optimize more for d0.5 to d3, where such compromises and special heuristics are less necessary
|
|
2025-06-05 11:39:36
|
That was after 0.8, but on that note, I wanted to ask you a serious question for consideration.
Are you sure the [pixel based AC strategy](https://github.com/libjxl/libjxl/pull/2836) is the correct way forward?
> measure the quality of an integral transform in the pixel space rather than dct coefficient base
It's been 2 years and it still doesn't match the quality of 0.8 on most images me and <@207980494892040194> test. Surely we're loosing the advantage of the DCT separating HF from LF in the decisions, allowing for better sharpness.
If we maintained the old AC strategy, but had put the same effort into improving chroma ringing as you have now, I belive we'd be in a better position.
The difficult images the AC strategy were meant to fix, would be better as modular anyway.
As you said for AVIF, focus on the strengths of each tool, instead of turning one into the other.
|
|
|
|
A homosapien
|
2025-06-05 12:01:20
|
Also, it's over 20-30% slower to encode which is really significant!!!
|
|
|
|
Jyrki Alakuijala
|
|
That was after 0.8, but on that note, I wanted to ask you a serious question for consideration.
Are you sure the [pixel based AC strategy](https://github.com/libjxl/libjxl/pull/2836) is the correct way forward?
> measure the quality of an integral transform in the pixel space rather than dct coefficient base
It's been 2 years and it still doesn't match the quality of 0.8 on most images me and <@207980494892040194> test. Surely we're loosing the advantage of the DCT separating HF from LF in the decisions, allowing for better sharpness.
If we maintained the old AC strategy, but had put the same effort into improving chroma ringing as you have now, I belive we'd be in a better position.
The difficult images the AC strategy were meant to fix, would be better as modular anyway.
As you said for AVIF, focus on the strengths of each tool, instead of turning one into the other.
|
|
2025-06-05 07:08:19
|
I'm sure pixel-based is the right way -- there is no way to do fair comparisons of one integral transform to the next in the integral transform space, they all look roughly the same
|
|
2025-06-05 07:08:50
|
there are many images that didn't have any chance of working at all before pixel based evals, including all DZGas images
|
|
2025-06-05 07:09:37
|
I just need to fix whatever there is to be fixed to get the quality the same (and better) than without back-and-forth dcts
|
|
2025-06-05 07:17:48
|
I'm trying to add X extremity modulation -- to add some precision in most red and green backgrounds, and to replace HF modulation by the 1x1 masking aggregations. I got fantastic results for my eyes but bad numbers (like 0.8 % worse), but decided to keep optimizing. The numbers improved to be 0.78 % worse, but then the resulting images looked bad π --- more challenge for next week
|
|
|
|
Demiurge
|
|
Jyrki Alakuijala
I'm trying to add X extremity modulation -- to add some precision in most red and green backgrounds, and to replace HF modulation by the 1x1 masking aggregations. I got fantastic results for my eyes but bad numbers (like 0.8 % worse), but decided to keep optimizing. The numbers improved to be 0.78 % worse, but then the resulting images looked bad π --- more challenge for next week
|
|
2025-06-05 09:10:03
|
What numbers?
|
|
2025-06-05 09:10:48
|
Don't get too distracted putting too much weight in lousy metrics when your eyes tell a different story...
|
|
2025-06-05 09:11:36
|
It's okay to massively decrease metric scores if there's a massive increase in visual fidelity and details...
|
|
2025-06-05 09:13:35
|
In fact it's often necessary to take a hit to meaningless "objective" scores in order to preserve more detail and fidelity sometimes
|
|
|
|
A homosapien
|
|
Jyrki Alakuijala
there are many images that didn't have any chance of working at all before pixel based evals, including all DZGas images
|
|
2025-06-06 12:28:00
|
I noticed a lot of DZgas's images have a lot of pixel thin lines, where DCT compression never really does well. Wouldn't a better patch detection algorithm or an automatic switch to lossy modular be better for those kind of images? What about a naive spline implementation? I feel like other codec tools could have been used rather than completely overhauling VarDCT. I'm still left wondering if the "potential improvements" are worth the speed penalty...
Also, if pixel-based and dct-based stratagies have their own strengths and weaknesses, why not do both at higher efforts? I feel like efforts 8+ don't benefit as much with the new pixel-based algorithm compared to the dct-based one. Maybe more analysis/preprocessing steps could be used, rather than doing more of the same butteraugli iterations, which have clearly have diminishing returns and is not worth the slow down. The extra computational time could be used for other metrics and methods instead. Higher efforts could be a testing ground for more daring and strange techniques.
|
|
|
|
jonnyawsom3
|
2025-06-06 01:07:42
|
Using https://github.com/gianni-rosato/photodetect2 ([C version](<https://gist.github.com/juliobbv-p/eabe5b048f956db5329951eaa5724d53>)) to decide between Modular and VarDCT has been on my mind for a while. <@703028154431832094> mentioned it can also classify images into different categories, possibly allowing decisions between VarDCT, Lossy Modular and Lossless based on image content.
|
|
|
Jyrki Alakuijala
there are many images that didn't have any chance of working at all before pixel based evals, including all DZGas images
|
|
2025-06-06 01:15:22
|
I think my message above would be a far more robust way of handling images like DZgas' examples. Using the pixel based strengths of modular, without sacrificing the frequency separating strengths of VarDCT. As Homosapien said, a lot of the images DZgas complains about have pixel thin lines or single pixel colors, usually unnoticeable in regular images for DCT, causing VarDCT to loose sharpness in more standard images. By switching to modular when such pixel content is detect, you avoid all the issues of preserving extremely high frequency content using DCT
|
|
|
gb82
|
|
Using https://github.com/gianni-rosato/photodetect2 ([C version](<https://gist.github.com/juliobbv-p/eabe5b048f956db5329951eaa5724d53>)) to decide between Modular and VarDCT has been on my mind for a while. <@703028154431832094> mentioned it can also classify images into different categories, possibly allowing decisions between VarDCT, Lossy Modular and Lossless based on image content.
|
|
2025-06-06 01:19:34
|
The different categories are likely more relevant for AV1, for IntraBC candidates and stuff
|
|
2025-06-06 01:19:43
|
I think intraBC is close to patches
|
|
|
|
CrushedAsian255
|
|
gb82
I think intraBC is close to patches
|
|
2025-06-06 01:21:34
|
intra block copy?
|
|
|
|
Jyrki Alakuijala
|
|
Demiurge
Don't get too distracted putting too much weight in lousy metrics when your eyes tell a different story...
|
|
2025-06-06 02:15:53
|
All psnr, ssimulacra and butteraugli were a little worse but looked a little better
|
|
|
I think my message above would be a far more robust way of handling images like DZgas' examples. Using the pixel based strengths of modular, without sacrificing the frequency separating strengths of VarDCT. As Homosapien said, a lot of the images DZgas complains about have pixel thin lines or single pixel colors, usually unnoticeable in regular images for DCT, causing VarDCT to loose sharpness in more standard images. By switching to modular when such pixel content is detect, you avoid all the issues of preserving extremely high frequency content using DCT
|
|
2025-06-06 02:23:59
|
There will always be fused images: part graphics, part photograph, photos of modern products β and particularly so when an original photo has been subsampled β can be quite close to graphics, also a usual photo can contain text etc. Photos of cars and modern kitcens can have such characteristics, too. Modular/VarDCT switch is an abrupt thing that would cause head scratching. Some people would observe that in their series of very similar images some compress slower/worse/with very different artefacts.
|
|
|
|
jonnyawsom3
|
2025-06-06 02:32:39
|
Different artifacts is the point though, and the slow compression is something that's hardly been touched for lossy modular. Jon's old 'More Patches' PR would also solve the mixed content issue, allowing image regions to be encoded using the best method
|
|
|
|
Demiurge
|
|
Jyrki Alakuijala
All psnr, ssimulacra and butteraugli were a little worse but looked a little better
|
|
2025-06-06 03:48:05
|
always ignore metrics, always go with your eyes...
|
|
2025-06-06 03:48:33
|
Don't even let it bother you when lying awake at night
|
|
|
|
Kupitman
|
2025-06-06 11:26:04
|
I wanna more lossless optimizations.
|
|
|
|
jonnyawsom3
|
|
Demiurge
always ignore metrics, always go with your eyes...
|
|
2025-06-06 11:31:06
|
But get other opinions too :P
|
|
|
|
CrushedAsian255
|
2025-06-06 11:47:49
|
Anyone know any image CDNs that support jpeg xl conversion? Iβm building a simple web app (not production just playing around) but want JXL support for things like rescaled images
|
|
|
|
Mine18
|
|
CrushedAsian255
Anyone know any image CDNs that support jpeg xl conversion? Iβm building a simple web app (not production just playing around) but want JXL support for things like rescaled images
|
|
2025-06-06 11:49:10
|
doesn't cloudinary do that
|
|
|
|
CrushedAsian255
|
|
Mine18
doesn't cloudinary do that
|
|
2025-06-06 11:50:24
|
Does it have a free version?
|
|
|
|
Mine18
|
2025-06-06 11:50:41
|
no clue, that's All I know
|
|
|
|
HCrikki
|
2025-06-06 12:36:58
|
seems it does but its not a traditional cdn or really consumer focused (feels entreprisey and accordingly priced)
|
|
2025-06-06 12:37:28
|
i recall fastly covers jxl but it may be a paid extra. there was bunny too iinm
|
|
|
|
i.kra
|
2025-06-06 04:46:48
|
Is there a way to decode back to the input color space when using an ICC?
|
|
|
|
_wb_
|
2025-06-06 06:09:00
|
Yes, djxl should do that by default
|
|
|
|
Demiurge
|
2025-06-06 06:24:56
|
djpegli doesn't convert xyb back to rgb
|
|
|
|
Jyrki Alakuijala
|
|
Demiurge
Don't even let it bother you when lying awake at night
|
|
2025-06-07 08:41:19
|
How did you know? π
|
|
|
|
Demiurge
|
2025-06-07 10:29:58
|
I am the great Foxless Compressor. I compress all mortal knowledge.
|
|
|
|
AccessViolation_
|
2025-06-07 07:22:54
|
as opposed to the nefarious lesser Foxful Compressor
|
|
|
spider-mario
|
2025-06-07 07:24:36
|
arenβt they Foxful Expander?
|
|
|
|
AccessViolation_
|
2025-06-07 07:26:29
|
ah I may have my fox-related compression deities mixed up
|
|
|
dogelition
|
2025-06-07 07:26:40
|
every compressor is an expander with the right input
|
|
|
|
AccessViolation_
|
2025-06-07 07:27:19
|
look up fox expansion for more information
|
|
2025-06-07 07:28:15
|
just don't do it at work
|
|
|
|
_wb_
|
|
dogelition
every compressor is an expander with the right input
|
|
2025-06-07 09:19:12
|
This is correct, but you can avoid having to expand by more than one bit by just having an escape bit to do no-op raw storage.
|
|
|
|
CrushedAsian255
|
|
_wb_
This is correct, but you can avoid having to expand by more than one bit by just having an escape bit to do no-op raw storage.
|
|
2025-06-08 02:47:18
|
Although usually it would be a byte as most file systems and networks donβt support bit level file sizes
|
|
|
|
monad
|
2025-06-08 05:05:05
|
Byte-level storage implies bit-level encodings waste the unused part of the byte.
|
|
|
|
spider-mario
|
|
AccessViolation_
as opposed to the nefarious lesser Foxful Compressor
|
|
2025-06-08 01:14:46
|
|
|
2025-06-08 01:19:24
|
(Dr Eggman, Sonic Adventure)
|
|
|
|
Demiurge
|
2025-06-08 02:42:25
|
I foxlessly compress everything, perfectly preserving all the original information without adding or removing any foxes from the data stream
|
|
2025-06-08 02:44:59
|
Using state of the art FSE (Fox Status Entropy) coding
|
|
2025-06-08 02:47:13
|
It's totally reversible and always produces fox-exact images
|
|
2025-06-08 02:47:33
|
Visually foxless
|
|
2025-06-08 02:47:42
|
And foxel perfect
|
|
2025-06-08 02:48:28
|
Patent and trademark pending
|
|
|
TheBigBadBoy - πΈπ
|
2025-06-08 02:51:11
|
fox ftw
|
|
|
|
Demiurge
|
2025-06-08 02:51:55
|
US patent 69-666-8008135 A method to reversibly encode and preserve foxes within a data stream
|
|
|
diskorduser
|
2025-06-08 03:34:34
|
Image.fpegxl when?
|
|
|
|
AccessViolation_
|
|
spider-mario
|
|
2025-06-08 04:56:35
|
man, what a voice
|
|
2025-06-08 04:56:59
|
as an aspiring voice actor I'm jealous
|
|
2025-06-08 04:57:37
|
my voice still hasn't fully recovered from trying to do a Cave Johnson impersonation
|
|
|
|
Demiurge
|
2025-06-09 06:30:22
|
That's just JK Simmons speaking normally
|
|
2025-06-09 06:31:05
|
I prefer the G-man voice personally
|
|
2025-06-09 06:32:30
|
I took the liberty of relieving you of your weapons - most of them were, government property? As for the suit, I think you've earned it.
|
|
2025-06-09 06:34:37
|
Wisely done, doctor! I will see you up ahead.
|
|
2025-06-09 06:36:26
|
The only person who Iβve seen that can truly pull it off well is JapaneseBushBaby. Just look up "Headcrab Jambalaya" to see what I mean.
https://youtu.be/zTMjucCj590
|
|
|
|
Mine18
|
|
AccessViolation_
man, what a voice
|
|
2025-06-09 11:31:48
|
Deem Bristow, Eggman's VA before Mike Pollock
didn't do much other than Eggman
|
|
|
|
Jyrki Alakuijala
|
2025-06-10 08:00:37
|
https://arxiv.org/abs/2506.05987 did anyone read it
|
|
|
|
A homosapien
|
2025-06-10 08:29:16
|
I read the draft, I skimmed the released version and saw a few changes
|
|
2025-06-10 08:29:45
|
I reread it when I have the time
|
|
|
novomesk
|
|
Jyrki Alakuijala
https://arxiv.org/abs/2506.05987 did anyone read it
|
|
2025-06-10 09:13:34
|
It is valuable document.
|
|
|
|
CrushedAsian255
|
2025-06-10 11:07:10
|
jpeg xl β¨π
|
|
|
|
Jyrki Alakuijala
|
|
novomesk
It is valuable document.
|
|
2025-06-10 08:31:31
|
We tried to include a view behind the curtains. Most of the development happened before development was made open.
The single thing I'm most proud of is how we were able to combine two platforms in a collaborative manner (pik+huif). The usual ISO process is to take one and then integrate features. But it is a steeper process than what we used.
|
|
|
|
AccessViolation_
|
2025-06-10 08:39:37
|
I really appreciate that it's a fairly approachable document. you don't need to be an exert in image compression to understand it. the opposite is the case for many other papers
|
|
2025-06-10 09:43:59
|
part of me wants to go through the paper and digest a lot of it down to expand the coverage of the wikipedia article, but typically wikipedia doesn't like it when technical topics go too in-depth iirc
|
|
|
|
_wb_
|
|
AccessViolation_
I really appreciate that it's a fairly approachable document. you don't need to be an exert in image compression to understand it. the opposite is the case for many other papers
|
|
2025-06-11 05:42:30
|
Thanks, this was one of my main goals. Too many papers have a tendency to obfuscate, since especially in the academic peer review process, scary math and incomprehensible jargon will increase your chances of acceptance while readable prose that tries to build intuition can hurt your chances of acceptance (too many reviewers consider it not 'scientific' enough).
That's also why I am not trying to get it published in an academic journal or conference. Well and also because it is a lot above the page limit of any of those π
|
|
|
|
AccessViolation_
|
2025-06-11 05:31:05
|
that's a great way to go about it
|
|
2025-06-11 05:36:16
|
I personally do find it fun to use unnecessarily profound and niche language occasionally but I have a lot of respect for experts that can show restraint and don't make their publications unnecessarily hard to understand
|
|
2025-06-11 05:41:39
|
it's kind of the same with programming, I like writing clever code and using iterator chains because it's fun to see how compact and seemingly simple you can make a block of code, but then when you look at it at the end, what it does is not clear *at all* and it would've been better to write code that's a bit larger but way more understandable
|
|
|
|
jonnyawsom3
|
2025-06-11 05:53:59
|
"Show your working" was never my strongsuit in school
|
|
|
|
spider-mario
|
|
AccessViolation_
it's kind of the same with programming, I like writing clever code and using iterator chains because it's fun to see how compact and seemingly simple you can make a block of code, but then when you look at it at the end, what it does is not clear *at all* and it would've been better to write code that's a bit larger but way more understandable
|
|
2025-06-11 08:22:16
|
for the former, you might enjoy Raku (formerly βPerl 6β) or J (APL-like but ASCII)
|
|
|
|
AccessViolation_
|
2025-06-11 08:36:43
|
I've never used any of these π
|
|
2025-06-11 08:40:15
|
I think the closest I got to going in on functional all the way was trying haskell, but the syntax was so strange and hard to get used to that I gave up on that experiment
|
|
|
|
spider-mario
|
2025-06-11 08:52:08
|
(maybe not J then)
|
|
2025-06-11 08:52:11
|
https://www.jsoftware.com/papers/tot.htm
|
|
2025-06-11 08:52:29
|
this is a classic article about APL (and by extension, APL-like languages like J)
|
|
|
Nuk
|
|
Jyrki Alakuijala
https://arxiv.org/abs/2506.05987 did anyone read it
|
|
2025-06-12 04:45:33
|
It's a very nice paper, very thorough AND approachable. Some formatting nitpicks if you ever decide to update it: p10 fig4 misplaced caption "libjpeg-turbo -quality 10" should be moved to the right. p38 typo "contructed"? And maybe change "Legend:" to "Legend (Predictors):"
p41 "Adaptive LF smoothing" fig30: it'd be nice to have an example of JPEG XL without adaptive smoothing (also is that the best AVIF can do? I thought it had better LF filtering)
p55: "the dynamic approach is inherently slower, both for encoding and decoding": for (all) decoders and fast encoders yes, but some encoders that do RDO (or DP path search / optimal parsing for LZ, or Trellis quantization) iterate several times using the probabilities of the previous pass as cost estimations for the current one, and the (single-pass) dynamic approach ends up being faster. I don't think this currently applies to libjxl though.
p67 "slower encode speed settings lead to a lower image quality": it's the other way around, right?
|
|
|
|
spider-mario
|
2025-06-12 05:11:54
|
hopefully
|
|
|
|
_wb_
|
2025-06-12 09:10:13
|
Thanks for spotting these, will fix them and upload a revised version at some point. Maybe I will first wait a bit for more bugs to be found in the paper.
|
|
2025-06-13 12:21:04
|
uploading an updated version, will probably take until after the weekend for arXiv to process but it's in the pipeline
|
|
2025-06-13 12:22:09
|
added a version of that gradient with adaptive LF smoothing disabled, it does show quite clearly that it makes a difference
|
|
2025-06-13 12:23:40
|
also added this HEIC example to the figure since I wanted to keep an even number of examples
|
|
|
|
CrushedAsian255
|
|
_wb_
also added this HEIC example to the figure since I wanted to keep an even number of examples
|
|
2025-06-13 12:37:48
|
Literally looks like an 8x8 pixel image
|
|
|
|
_wb_
|
2025-06-13 12:40:00
|
HEIC is very much tuned for PSNR, which is horrible for avoiding macroblocking/banding (and blur, but that's not the issue here).
|
|
|
|
CrushedAsian255
|
2025-06-13 12:42:55
|
Is PSNR just finding the largest difference value?
|
|
|
|
_wb_
|
2025-06-13 12:44:37
|
psnr is just the root mean square error (on a logscale but that doesn't change anything)
|
|
2025-06-13 12:47:06
|
importantly, it doesn't include any spatial information, you can change the order of the pixels in any way you like (in the same way in both images) and that doesn't change the PSNR
|
|
2025-06-13 01:05:38
|
banding and macroblocking are artifacts that have a pretty low per-pixel error, but in smooth gradients we don't need large differences to see unnatural banding or blocking β there is no contrast masking whatsoever to hide the artifacts. But PSNR has no clue about contrast masking, it's just an average of per-pixel error.
|
|
|
|
Demiurge
|
2025-06-13 03:07:52
|
In ssimu2 and butter and similar metrics, how is banding detected and punished worse than other less damaging types of distortion?
|
|
2025-06-13 03:10:49
|
Like for example, high quality forms of dithering would have a better score right?
|
|