|
Demiurge
|
2025-05-17 01:31:46
|
Idk what kind of monitor you're using but it's pretty obvious that libjxl blurs and softens the bridge and mozjpeg is sharper and more detailed here.
|
|
|
A homosapien
Yes actually, the JPEG artifacts are too extreme to be considered "high fidelity". The blocking is unacceptably bad and the ringing is immediately apparent at first glance. At worst blacks look about the same in the JXL. Actually JXL is preserving more of what little details there are in the blacks. MozJPEG is noisy and blocky to all hell back, not faithful to the original image at all.
Also, the reason I call it "blacks" and not "shadows" is because I consider the night sky a huge shadowed area, which has been marred beyond recognition. Also, the images as a whole seems to be slightly fuzzy/blurry, which is one of my major gripes with MozJPEG in general.
I agree with the general sentiment of JXL neglecting darkness at times. I just don't know what you are smoking to say that MozJPEG is better here.
|
|
2025-05-17 01:36:07
|
Are these the "unacceptably bad" artifacts you're referring to?
|
|
2025-05-17 01:42:16
|
Actually I think it could depend on the software environment. On my PC mozjpeg looks undeniably better. On my phone jxl looks better.
|
|
2025-05-17 01:42:53
|
I was using chrome on PC
|
|
2025-05-17 01:45:10
|
Try comparing with avif instead of jpeg, if you like.
|
|
2025-05-17 01:48:04
|
Yeah, the JPEG decoder on my PC is much better than the one on my phone.
|
|
2025-05-17 01:48:33
|
Either way the jxl has bizarre and awful artifacts on the bridge even on the Large image
|
|
2025-05-17 01:50:14
|
Also the extremely weird colorful chroma ringing artifacts are prominent too
|
|
|
RaveSteel
|
2025-05-17 01:52:03
|
On Firefox JXL isn't even in the same ballpark with mozjpeg, it looks much better. Comparing AVIF and JXL the detail is comparable but the slight colour desaturation in JXL is noticeable
|
|
|
|
Demiurge
|
2025-05-17 02:21:10
|
|
|
2025-05-17 02:21:51
|
This is how they look on my desktop. Which looks better, A or B?
|
|
2025-05-17 02:22:38
|
One has far more fidelity to the original than the other. And it's mozjpeg.
|
|
2025-05-17 02:22:56
|
But on my phone mozjpeg looks worse...
|
|
2025-05-17 02:25:17
|
Yeah, I dunno, my desktop setup just has insanely good JPEG decoding I guess, because the JPEG looks clearly, obviously better than JXL on this system.
|
|
2025-05-17 02:26:52
|
the JXL is desaturated and has all kinds of weird artifacts the JPEG doesn't have.
|
|
|
spider-mario
|
2025-05-17 02:35:40
|
I struggle to find any area in the image that looks better with JPEG
|
|
|
|
Demiurge
|
2025-05-17 02:52:09
|
B is JPEG
|
|
2025-05-17 02:52:17
|
A is JXL
|
|
2025-05-17 02:55:00
|
The holes in the red beams are completely messed up and smeared in JXL
|
|
2025-05-17 02:55:12
|
The separate holes become a smeared line.
|
|
2025-05-17 02:55:57
|
On my software and hardware, it's incredibly obvious.
|
|
2025-05-17 02:56:24
|
The JXL artifacts are much more noticeable from a distance compared to JPEG
|
|
|
|
spider-mario
|
|
Demiurge
The separate holes become a smeared line.
|
|
2025-05-17 03:33:10
|
I see that in the JPEG, not the JXL
|
|
2025-05-17 03:33:55
|
especially the vertical one, at x ≈ 75%
|
|
|
|
Demiurge
|
2025-05-17 03:39:09
|
It's definitely the other way around on my system
|
|
2025-05-17 03:40:01
|
B has more ringing but the holes are clearly defined by comparison and A has all the bizarre artifacts
|
|
|
|
spider-mario
|
2025-05-17 04:05:07
|
wait, I do see one line where it is indeed slightly more smeared in the JXL
|
|
2025-05-17 04:05:18
|
you are referring to the second line from the left on that pillar
|
|
2025-05-17 04:05:25
|
I was referring to the next two on the right
|
|
|
KKT
|
2025-05-17 04:16:18
|
Yeah on my Mac in Safari, the JXL is a clear winner.
|
|
|
_wb_
|
2025-05-17 04:16:31
|
I see way more detail in the jxl and way more ringing in the jpeg. Is there an easy way to flip to the original in that interface?
|
|
|
|
Demiurge
|
2025-05-17 04:17:11
|
The original is one of the codec options in the drop down menu
|
|
2025-05-17 04:20:16
|
I dunno... it's like night and day on my system. The JPEG has more ringing but the JXL undeniably has less fidelity, less detail, desaturated and blotchy colors, and utterly messes up the holes in the red beams to be smeared and indistinct.
|
|
2025-05-17 04:21:31
|
The jxl has more chroma ringing and the jpeg has more luma ringing
|
|
2025-05-17 04:23:40
|
The JPEG ringing is easier to see zoomed in but the JXL artifacts are easier to see at 1x scale
|
|
|
|
spider-mario
|
2025-05-17 04:26:31
|
the JPEG also messes up the holes
|
|
2025-05-17 04:26:40
|
just different ones
|
|
|
|
_wb_
|
2025-05-17 04:28:26
|
What kind of display are you using, <@1028567873007927297> ? Maybe it does something that somehow amplifies jxl artifacts more
|
|
|
|
Demiurge
|
2025-05-17 04:55:48
|
It's an old HP screen. But I doubt the screen could make a difference like this. I'll try it on a Mac later.
|
|
2025-05-17 04:56:17
|
It seems like too big and obvious a difference for the screen to be it.
|
|
|
Demiurge
|
|
2025-05-17 04:57:36
|
Is the blurriness not obvious here?
|
|
|
diskorduser
|
2025-05-17 05:19:18
|
For me b looks bad
|
|
|
|
Demiurge
|
2025-05-17 05:24:35
|
I'll try looking at it on different hardware later...
|
|
|
|
diskorduser
|
|
|
Demiurge
|
2025-05-17 05:48:36
|
Are you looking at the dark, shaded red beams underneath the bridge?
|
|
|
jonnyawsom3
|
2025-05-17 06:27:47
|
Everyone else so far agrees, JPEG is worse. I don't think focusing on a specific area is going to change that
|
|
|
|
_wb_
|
2025-05-17 06:57:22
|
It is interesting if there are local areas where jxl can be improved, it can be useful feedback to improve heuristics. After all jxl has way more flexibility than jpeg to make local quality decisions...
|
|
|
Vision
|
2025-05-17 08:59:43
|
Hi, I'd like to know whether ``-e 10 -d 0 --brotli_effort=11 -I 100 -g 3 -E 11`` is suitable for converting JPG to JXL. I thought I saw an image that had doubled in size.
|
|
|
|
_wb_
|
2025-05-17 09:02:16
|
That should work but it shouldn't be much different from just using defaults (cjxl in.jpg out.jxl)
|
|
|
|
spider-mario
|
2025-05-17 09:02:30
|
yeah, I was going to write – I’d just use the defaults
|
|
|
|
_wb_
|
2025-05-17 09:04:02
|
A jpg doubling in size when losslessly recompressed is very strange and likely a bug or a jpg that ends up being decoded to pixels and then encoded losslessly from that (which is like converting jpeg to PNG, not a good idea)
|
|
|
|
spider-mario
|
2025-05-17 09:04:21
|
I’ve just tested on a very representative sample of one image and got the following outcome:
your settings: 12 seconds to get from 7.74MB to 6.66MB
defaults: less than a second to get from 7.74MB to 6.69MB
|
|
2025-05-17 09:04:38
|
(the image is 20MP)
|
|
|
|
_wb_
|
2025-05-17 09:10:08
|
Extra effort beyond the default is going to be extremely diminishing returns in case of jpeg recompression. For the AC, currently extra effort doesn't really make any difference at all, so it's only in the DC and possibly some metadata where there can be a slight difference, but that's usually only 10-20% of the image data and the gains above e7 are generally pretty small
|
|
|
|
Vision
|
2025-05-17 09:48:57
|
For a JPEG of 9.937 MB, I go to 9.420 MB with `-e 7`, 9.033 MB with `-e 10` and 9.030 MB if I add `-I 100`. Maybe it's because my files are in 256-color bitmap.
|
|
2025-05-17 09:53:13
|
I reran a batch, and once again, several images have increased in size. I'll try again later using the default settings.
|
|
|
|
spider-mario
|
2025-05-17 10:16:17
|
that sounds like an unusual set of images; do you happen to know how they ended up as JPEGs in the first place?
|
|
|
|
Vision
|
2025-05-17 10:48:38
|
No idea, but I then optimized them with ECT.
|
|
|
A homosapien
|
|
Vision
I reran a batch, and once again, several images have increased in size. I'll try again later using the default settings.
|
|
2025-05-17 11:03:08
|
They increased in size from JPEG to JXL? Or from JXL to JXL?
|
|
|
|
diskorduser
|
|
Demiurge
Are you looking at the dark, shaded red beams underneath the bridge?
|
|
2025-05-18 02:14:16
|
This area?
|
|
|
|
Demiurge
|
2025-05-18 02:15:10
|
No. The vertical red beam, lower and slightly to the left
|
|
2025-05-18 02:15:25
|
See the evenly spaced holes in the beam?
|
|
2025-05-18 02:15:57
|
In the bottom image they are distinct, in the top one it's just a smear
|
|
2025-05-18 02:16:19
|
I can definitely see it on my phone too... I don't think it's peculiar to the screen I'm using
|
|
2025-05-18 02:18:26
|
I'm surprised no one else sees it. The JPEG definitely shows more faithfulness and details from the original image.
|
|
|
|
diskorduser
|
2025-05-18 02:19:25
|
There are few dark areas where details are missing in jxl
|
|
|
|
Demiurge
|
2025-05-18 02:19:27
|
Both in color, and in recognizable features
|
|
2025-05-18 02:22:45
|
The JXL mangles the colors and makes certain details and features unrecognizable and obliterated. The artifacts In mozjpeg still allow you to see what's underneath
|
|
2025-05-18 02:23:41
|
So when viewing from a distance at 1x scale I think the jxl is worse
|
|
2025-05-18 02:26:03
|
Surely I can't be the only one that sees it...
|
|
|
|
A homosapien
|
2025-05-18 02:47:30
|
Your display might be broken or miscalibrated, because I don't see any loss of detail when compared to JPEG. When increasing the exposure and doing a flicker test, I do see a tiny bit of color desaturation in the reds, but there are wayyyy worse artifacts in the JPEG that we can clearly see without manipulating the image. So everyone else believes JXL is the winner here.
|
|
2025-05-18 02:56:31
|
In fact, increasing the exposure just makes JPEG look even worse, it suffers from all of the problems you accuse JXL of suffering from, it blurs, disregards small details, not to mention the banding is awful on HDR displays.
|
|
|
|
Demiurge
|
|
A homosapien
In fact, increasing the exposure just makes JPEG look even worse, it suffers from all of the problems you accuse JXL of suffering from, it blurs, disregards small details, not to mention the banding is awful on HDR displays.
|
|
2025-05-18 04:51:15
|
You're not looking at the shaded area. Although the desaturation of the JXL is noticeable from a distance here in this animation.
|
|
|
|
A homosapien
|
2025-05-18 04:55:31
|
Where? I'm cranking up the exposure and JXL still looks better
|
|
|
|
Demiurge
|
2025-05-18 04:57:02
|
You see the two support pillars coming out of the brick foundation?
|
|
2025-05-18 04:57:32
|
The one on the right
|
|
2025-05-18 04:57:37
|
The vertical steel beam
|
|
2025-05-18 04:59:42
|
There's a brick covered foundation on the ground supporting the bridge, with two central pillars supporting the bridge coming from the foundation
|
|
2025-05-18 05:00:31
|
There are dark shadows under the bridge there that are more clearly defined in the JPEG
|
|
2025-05-18 05:00:42
|
and all smudgy in the JXL
|
|
2025-05-18 05:02:04
|
The evenly spaced holes in the steel beams are blurred and softened and even smeared away entirely
|
|
|
A homosapien
In fact, increasing the exposure just makes JPEG look even worse, it suffers from all of the problems you accuse JXL of suffering from, it blurs, disregards small details, not to mention the banding is awful on HDR displays.
|
|
2025-05-18 05:04:07
|
But even on my iPhone, from a distance, the color here is more obviously true in the JPEG and desaturated in the JXL. The JXL only looks better when close enough to see the pixels.
|
|
2025-05-18 05:05:27
|
Well, even from a distance the JPEG looks a little softer there, in your animation
|
|
|
|
A homosapien
|
2025-05-18 05:05:32
|
I feel like I'm being trolled right now
|
|
2025-05-18 05:05:51
|
Everything you are describing points to the JPEG I'm seeing
|
|
|
|
Demiurge
|
2025-05-18 05:06:51
|
The JXL does look slightly sharper in your animation even when viewed from a distance. But the loss of color is more noticeable to me.
|
|
|
|
A homosapien
|
2025-05-18 05:07:12
|
That's not your initial point though
|
|
|
Lumen
|
2025-05-18 05:07:13
|
I dont see a difference in color even when pixel peeping on my phone
|
|
|
|
Demiurge
|
2025-05-18 05:07:25
|
But that's a different part of the image than what I was looking at
|
|
|
|
A homosapien
|
|
Lumen
I dont see a difference in color even when pixel peeping on my phone
|
|
2025-05-18 05:07:55
|
It's very minor, I had to increase the exposure and saturation to see it clearly.
|
|
|
|
Demiurge
|
2025-05-18 05:08:58
|
Could you look at the region near the support beams coming out of the foundation?
|
|
2025-05-18 05:09:05
|
And tell me what you see there?
|
|
|
|
A homosapien
|
2025-05-18 05:11:16
|
Okay I found ONE tinyyyyyy detail where JPEG preseves over JXL
|
|
|
|
Demiurge
|
|
Lumen
I dont see a difference in color even when pixel peeping on my phone
|
|
2025-05-18 05:11:49
|
The color and desaturation problems aren't unique to this image and has been a problem for a long time in basically every color image with libjxl.
|
|
|
|
A homosapien
|
2025-05-18 05:12:04
|
And yes it's real detail from the original PNG, not some noise pretending to be detail
|
|
|
|
Demiurge
|
|
A homosapien
Okay I found ONE tinyyyyyy detail where JPEG preseves over JXL
|
|
2025-05-18 05:13:44
|
The problem is always with details in shadows. Shadows don't pop and any depth gets flattened out after libjxl compression. Look for details and depth in the dark areas and it's easy to notice the flattening of shadows.
|
|
|
|
A homosapien
|
|
Demiurge
The problem is always with details in shadows. Shadows don't pop and any depth gets flattened out after libjxl compression. Look for details and depth in the dark areas and it's easy to notice the flattening of shadows.
|
|
2025-05-18 05:13:53
|
I found a tiny strut in between the beams, within the shadow that gets blurred out in the JXL while the JPEG still keeps it in.
|
|
|
|
Demiurge
|
2025-05-18 05:14:00
|
It's a very common artifact in many primitive codecs
|
|
|
|
A homosapien
|
2025-05-18 05:14:07
|
I had to boost exposure a ton to find it
|
|
2025-05-18 05:14:23
|
your display's black levels must be outta wack or something
|
|
|
|
Demiurge
|
|
Demiurge
|
|
2025-05-18 05:14:54
|
I thought it was easy to see here...
|
|
|
A homosapien
I found a tiny strut in between the beams, within the shadow that gets blurred out in the JXL while the JPEG still keeps it in.
|
|
2025-05-18 05:15:11
|
Where is the vertical beam??
|
|
2025-05-18 05:15:22
|
Please look at the vertical support beam
|
|
2025-05-18 05:15:51
|
I don't even know what part of the image that is
|
|
2025-05-18 05:16:41
|
Oh I see it's to the right of the support pillars
|
|
2025-05-18 05:16:58
|
Look at the vertical pillars themselves
|
|
2025-05-18 05:17:30
|
Like in the crop I made
|
|
2025-05-18 05:19:40
|
The massive vertical pillars coming from the foundation
|
|
|
|
A homosapien
|
2025-05-18 05:20:19
|
|
|
2025-05-18 05:20:23
|
That's not real detail, that's just random noise + DCT artifacts.
|
|
2025-05-18 05:21:42
|
Not fathiful to the orginal image
|
|
2025-05-18 05:33:19
|
I'm talking to a brick wall again
|
|
|
|
Demiurge
|
2025-05-18 05:39:34
|
|
|
2025-05-18 05:39:47
|
Holy crap what did discord do to it
|
|
|
|
A homosapien
|
2025-05-18 05:40:05
|
discord's compression sucks
|
|
|
|
Demiurge
|
2025-05-18 05:40:06
|
How do you prevent discord from mangling it
|
|
|
|
A homosapien
|
2025-05-18 05:40:23
|
I personally open it in a browser
|
|
|
|
Demiurge
|
|
A homosapien
I personally open it in a browser
|
|
2025-05-18 05:41:19
|
that seems to work... But how come yours aren't getting mangled?
|
|
|
|
A homosapien
|
2025-05-18 05:42:17
|
Nearest neighbor 2x-4x upscale
|
|
2025-05-18 05:42:38
|
So that lossy webp's compression doesn't affect it as much
|
|
|
|
Demiurge
|
2025-05-18 05:43:43
|
|
|
2025-05-18 05:43:54
|
Still looks mangled as all hell
|
|
|
|
A homosapien
|
2025-05-18 05:44:48
|
Lossy animated WebP compression is forced on
|
|
|
|
Demiurge
|
2025-05-18 05:44:56
|
That's so bad... :(
|
|
|
|
A homosapien
|
2025-05-18 05:45:26
|
Also in your comparison image, that's AVIF not JPEG
|
|
2025-05-18 05:46:45
|
I have been successfully trolled and ragebaited
|
|
2025-05-18 05:46:49
|
Wonderful
|
|
|
|
Demiurge
|
2025-05-18 05:48:30
|
Wait a sec, no, I did mess up when making this
|
|
2025-05-18 05:49:44
|
I accidentally used the original, not the JPEG :(
|
|
2025-05-18 05:49:56
|
It was a comparison with the JXL and original
|
|
2025-05-18 05:50:15
|
First time making one of these animations, let me try again
|
|
2025-05-18 05:58:54
|
|
|
2025-05-18 05:59:11
|
Here, this time I carefully included all 3
|
|
2025-05-18 06:00:16
|
Open in browser, look at the vertical beam all the way to the right
|
|
2025-05-18 06:02:33
|
Here it is 3x scale
|
|
2025-05-18 06:02:59
|
still totally mangled though unless "open in browser..."
|
|
2025-05-18 06:05:11
|
The unlabeled one is the original image
|
|
2025-05-18 06:09:20
|
Here it is with just the two.
|
|
2025-05-18 06:48:12
|
It does look different on my phone than on my pc. I should find some more shadowy pictures to demonstrate this problem, other than the bridge image. You can kinda see it a little in the dark mountains too.
|
|
2025-05-18 07:01:55
|
My phone seems to make everything look better for JXL so maybe I actually have an anti-JXL PC monitor...
|
|
2025-05-18 07:05:50
|
The color issue is still there but somehow the shadows actually look more detailed in jxl than even in av1 whereas on my desktop they look terrible
|
|
|
|
Vision
|
|
A homosapien
They increased in size from JPEG to JXL? Or from JXL to JXL?
|
|
2025-05-18 08:24:17
|
JPG to JXL.
|
|
|
Vision
I reran a batch, and once again, several images have increased in size. I'll try again later using the default settings.
|
|
2025-05-18 08:48:40
|
Same issue with the default settings. I think the bug comes from XL Converter, as I don't encounter this problem when I compress the files individually.
|
|
|
|
_wb_
|
2025-05-18 08:56:41
|
Many/most converters will not do lossless JPEG recompression, but just decode the input to pixels and then encode that.
|
|
|
|
Vision
|
2025-05-18 09:19:19
|
I think XL Converter uses ``--lossless-jpeg=0`` by default, which sometimes gives better results — and sometimes worse.
|
|
|
|
spider-mario
|
2025-05-18 09:37:09
|
it might sometimes give smaller results, but that will be at the cost of quality
|
|
2025-05-18 09:37:34
|
except with `-d 0`, but then it will probably be larger most of the time
|
|
|
HCrikki
|
2025-05-18 09:57:54
|
xl converter has 2 poor default settings not revisited since - conversions from jpg to jxl are not reversible transcoding but normal full lossy conversions, and metadata is wiped by default
|
|
2025-05-18 10:00:35
|
its not an issue if you change those yourself or select "lossless jpeg transcoding" as the conversion objective but should always be the default normally - a jpeg converted at quality 100% with guaranteed smaller filesize is miles better than a worse lossy jxl thats not even guaranteed to have smaller filesize without lowering the quality % even more
|
|
|
Fab
|
2025-05-18 10:39:05
|
Jxl looks better on my Oppo
|
|
2025-05-18 10:39:43
|
Way better 50%
|
|
2025-05-18 10:39:58
|
What is the settings and effort
|
|
2025-05-18 10:40:09
|
<@1028567873007927297>
|
|
2025-05-18 10:41:01
|
But anyway with my changes Vp9 shouldn't be worse than jxl. I implemented good changes into yt now and webp
|
|
2025-05-18 10:41:21
|
And the whole internet is using it
|
|
2025-05-18 10:41:53
|
Cloudinary now has its measurements at around q50
|
|
|
|
Demiurge
|
|
Vision
For a JPEG of 9.937 MB, I go to 9.420 MB with `-e 7`, 9.033 MB with `-e 10` and 9.030 MB if I add `-I 100`. Maybe it's because my files are in 256-color bitmap.
|
|
2025-05-18 10:42:30
|
What is 256 color JPEG? No such thing?
|
|
|
Fab
What is the settings and effort
|
|
2025-05-18 10:44:04
|
https://afontenot.github.io/image-formats-comparison/
|
|
|
|
Fab
|
2025-05-18 10:52:25
|
|
|
2025-05-18 10:52:36
|
Honestly JPEG xl is an ugly mess
|
|
|
damian101
|
|
Demiurge
What is 256 color JPEG? No such thing?
|
|
2025-05-18 10:52:36
|
grayscale JPEG 😅
|
|
|
|
Fab
|
2025-05-18 10:52:53
|
X50 slower at p6 than SVT av1 hdr
|
|
2025-05-18 10:53:12
|
Better looking and quality YES NATIVE NARICE
|
|
2025-05-18 10:53:20
|
But who cares
|
|
2025-05-18 10:53:44
|
The software is difficult to use
|
|
2025-05-18 10:53:59
|
No gui for Windows regularly updated and open source
|
|
2025-05-18 10:54:31
|
Difficulty in reproducing yellow tones
|
|
2025-05-18 10:54:56
|
At same speed svt av1 hdr is better
|
|
2025-05-18 10:55:49
|
JPEG xl competes with av2 but it hasn't the same voice Sand thing
|
|
2025-05-18 10:56:28
|
Also faces and sausages now are more distorted and reticular oversharpened
|
|
2025-05-18 10:56:36
|
The second got solved
|
|
2025-05-18 10:56:47
|
The First still missEs
|
|
2025-05-18 10:58:10
|
Sure if you have a good looking file like Isocell gn8 it makes Sensei to use Majestic JPEG XL inprovements into avif from Jxl
|
|
|
|
Vision
|
|
Demiurge
What is 256 color JPEG? No such thing?
|
|
2025-05-18 11:00:07
|
24-bit with 256 colors.
|
|
|
|
Fab
|
2025-05-18 11:00:57
|
|
|
2025-05-18 11:01:23
|
Jxl is as restrictive as svt av1 psy is if it not worse s
|
|
|
Jyrki Alakuijala
|
|
Demiurge
My phone seems to make everything look better for JXL so maybe I actually have an anti-JXL PC monitor...
|
|
2025-05-18 06:12:58
|
Check if there is a sharpening or contrast setting
|
|
|
|
Demiurge
|
|
Jyrki Alakuijala
Check if there is a sharpening or contrast setting
|
|
2025-05-18 06:13:54
|
On the anti-JXL monitor? There is, but I thought I had disabled it by setting it in the middle or something.
|
|
|
|
Jyrki Alakuijala
|
|
Fab
Jxl looks better on my Oppo
|
|
2025-05-18 06:14:20
|
Same on my cubot 😅
|
|
|
Demiurge
On the anti-JXL monitor? There is, but I thought I had disabled it by setting it in the middle or something.
|
|
2025-05-18 06:15:12
|
Contrast is often ok at 50 but sharpening is usually not on at zero or 3/10 or so
|
|
|
|
Demiurge
|
2025-05-18 06:15:18
|
It's crazy because now that I'm testing on my phone, all the samples where jxl flattened blacks compared to other codecs now show jxl having better more detailed shadows than the other codecs
|
|
2025-05-18 06:15:30
|
It's crazy to think a monitor could do that
|
|
|
|
Jyrki Alakuijala
|
|
Demiurge
It's crazy because now that I'm testing on my phone, all the samples where jxl flattened blacks compared to other codecs now show jxl having better more detailed shadows than the other codecs
|
|
2025-05-18 06:16:07
|
I used very expensive and calibrated monitors to come up with xyb
|
|
|
|
Demiurge
|
2025-05-18 06:16:16
|
I need more hardware to test and be sure
|
|
|
|
Jyrki Alakuijala
|
2025-05-18 06:16:22
|
And jxl heuristics
|
|
|
username
|
|
Demiurge
It's crazy to think a monitor could do that
|
|
2025-05-18 06:16:55
|
just making sure but what browser where you using with what color management settings?
|
|
|
|
Jyrki Alakuijala
|
2025-05-18 06:16:56
|
NEC and EIZO photography monitors
|
|
2025-05-18 06:18:30
|
Our stock monitors gave different colors and no deep blacks, so i bought new ones for this use
|
|
|
|
Demiurge
|
2025-05-18 06:18:39
|
I always thought jxl crushes shadows too much. Even in digital art, crosshatch patterns on a dark background would get blurred compared to other codecs. But I need to test it on more hardware...
|
|
|
username
just making sure but what browser where you using with what color management settings?
|
|
2025-05-18 06:18:54
|
A fresh flatpak brave install
|
|
|
|
Jyrki Alakuijala
|
|
Demiurge
I always thought jxl crushes shadows too much. Even in digital art, crosshatch patterns on a dark background would get blurred compared to other codecs. But I need to test it on more hardware...
|
|
2025-05-18 06:19:30
|
Supposedly sometimes lower bit panels are used and temporally dithered to more bits
|
|
2025-05-18 06:19:50
|
In which case you see some odd flickering
|
|
|
|
Demiurge
|
2025-05-18 06:20:10
|
Jyrki, any idea what accounts for the persistent desaturation issue and chromatic ringing artifacts with libjxl?
|
|
|
|
Jyrki Alakuijala
|
2025-05-18 06:20:17
|
Sometimes the internal gamma lut of monitors is too few bits
|
|
|
Demiurge
Jyrki, any idea what accounts for the persistent desaturation issue and chromatic ringing artifacts with libjxl?
|
|
2025-05-18 06:20:44
|
Desaturation: not yet
|
|
|
|
Demiurge
|
2025-05-18 06:21:40
|
It's probably a very simple bug somewhere in the way it's being quantized
|
|
|
|
Jyrki Alakuijala
|
|
Demiurge
Jyrki, any idea what accounts for the persistent desaturation issue and chromatic ringing artifacts with libjxl?
|
|
2025-05-18 06:22:11
|
Chromatic ringing seems to be due to adding many pnorm values in the heuristic and comparing to a single pnorm of a bigger block. If i fix that it goes away. I just cannot make it work otherwisr yet well.
|
|
|
|
Demiurge
|
2025-05-18 06:22:16
|
It's very slight, but noticeable enough from a distance
|
|
|
Jyrki Alakuijala
Chromatic ringing seems to be due to adding many pnorm values in the heuristic and comparing to a single pnorm of a bigger block. If i fix that it goes away. I just cannot make it work otherwisr yet well.
|
|
2025-05-18 06:23:23
|
The chromatic ringing is easier to notice from close up but the desaturation is easier to see from a distance
|
|
|
|
Jyrki Alakuijala
|
2025-05-18 06:23:42
|
I find esthetic problems in my code in enc_ac_strategy.cc, ill try to fix them to have a stronger foundation for other changes
|
|
|
|
Fab
|
2025-05-18 06:23:42
|
<@532010383041363969> you could look at this site
|
|
2025-05-18 06:23:54
|
https://cloudinary.com/blog/what_to_focus_on_in_image_compression_fidelity_or_appeal
|
|
|
|
Demiurge
|
2025-05-18 06:24:09
|
It's nice that Jyrki is back 🎉
|
|
|
|
Fab
|
2025-05-18 06:24:11
|
Is updated with latest cookie 19:50
|
|
|
|
Demiurge
|
2025-05-18 06:24:18
|
Thanks Jyrki for all you do
|
|
|
|
Jyrki Alakuijala
|
2025-05-18 06:24:40
|
I think we use relatively large dead zone for chromacity
|
|
|
|
Fab
|
2025-05-18 06:24:56
|
HDblog is where i see visual improvements on jpg
|
|
|
|
Demiurge
|
2025-05-18 06:24:57
|
Fab, that was written by jon and I think Jyrki already knows about that
|
|
|
|
Fab
|
2025-05-18 06:25:03
|
Dday.it not sure
|
|
|
|
Jyrki Alakuijala
|
2025-05-18 06:25:07
|
That would give a 18 % improvement or so
|
|
|
|
Fab
|
2025-05-18 06:25:16
|
Because avif anyway on tin resolution look worse
|
|
|
|
Jyrki Alakuijala
|
2025-05-18 06:25:47
|
I was doing audio and machine learning, now time to improve jxl quality
|
|
2025-05-18 06:26:43
|
"zimtohrli" audio metric, like butteraugli but for sound
|
|
|
|
damian101
|
2025-05-18 06:27:08
|
oh, I've used that a lot <:woag:1070464147805970432>
|
|
|
|
username
|
2025-05-18 06:27:20
|
speaking of. are there any plans for at some point in the future adding knusperli like decoding for transcoded JPEG JXLs in libjxl?
|
|
|
|
Demiurge
|
2025-05-18 06:27:42
|
Anyone seen dzgas around? I think that was his name
|
|
|
|
Jyrki Alakuijala
|
|
username
speaking of. are there any plans for at some point in the future adding knusperli like decoding for transcoded JPEG JXLs in libjxl?
|
|
2025-05-18 06:27:49
|
Would be nice
|
|
|
|
Demiurge
|
2025-05-18 06:28:07
|
I remember he would always bring up chroma problems
|
|
|
|
damian101
|
|
username
speaking of. are there any plans for at some point in the future adding knusperli like decoding for transcoded JPEG JXLs in libjxl?
|
|
2025-05-18 06:28:10
|
wouldn't it more sense to use djepgli for that? and maybe combine features of both projects?
|
|
|
|
Demiurge
|
2025-05-18 06:28:18
|
He talked about them and noticed them more than others
|
|
|
|
damian101
|
2025-05-18 06:28:23
|
actually, I think the jpegli project is supposed to be separated...
|
|
2025-05-18 06:29:31
|
https://discord.com/channels/794206087879852103/794206087879852107/1373608619722936331
|
|
|
|
Jyrki Alakuijala
|
|
Demiurge
Anyone seen dzgas around? I think that was his name
|
|
2025-05-18 06:29:52
|
He was quite pointy in the beginning, but the community treating him well we were able to integrate his valuable insights. Im really happy to get input from DZgas
|
|
2025-05-18 06:30:45
|
He saw many many things that i had missed and had not been able to derisk myself
|
|
|
|
username
|
|
wouldn't it more sense to use djepgli for that? and maybe combine features of both projects?
|
|
2025-05-18 06:31:15
|
isn't djpegli decoding the same as libjxl JPEG decoding? also yeah I don't think there is anything stopping both from being "combined" since afaik djpegli/libjxl produce nice decodes because they just do everything with a higher internal precision
|
|
|
|
Demiurge
|
2025-05-18 06:31:26
|
Actually I would really prefer jpegli stay with libjxl, add support for building multiple api versions at once, add a header for using the `jpegli_` api, add the high bit depth `jpeg10_` api, and have the library code in a separate repo from the "extras" code
|
|
|
|
Jyrki Alakuijala
|
|
actually, I think the jpegli project is supposed to be separated...
|
|
2025-05-18 06:32:17
|
Id like libjpg replaced with jpegli in linux distros
|
|
2025-05-18 06:32:55
|
This will never happen if suddenly jxl comes along
|
|
|
|
damian101
|
|
|
Jyrki Alakuijala
|
2025-05-18 06:33:34
|
It is a sad but necessary split
|
|
|
|
Demiurge
|
|
Jyrki Alakuijala
Id like libjpg replaced with jpegli in linux distros
|
|
2025-05-18 06:33:57
|
Me too. But it doesn't need to be in a separate repo from jxl for that. It just needs to be convenient to build and package it as a drop in replacement library. Would help to have some headers too.
|
|
|
|
damian101
|
2025-05-18 06:33:58
|
I hope it properly splits soon, because currently it's quite a mess...
|
|
|
|
Jyrki Alakuijala
|
2025-05-18 06:34:04
|
I think ML will eventually decode the most beautiful jpegs
|
|
|
|
Demiurge
|
2025-05-18 06:34:11
|
Since libjpeg includes headers
|
|
2025-05-18 06:34:26
|
And a lot of stuff depends and expects headers
|
|
|
|
damian101
|
|
Jyrki Alakuijala
I think ML will eventually decode the most beautiful jpegs
|
|
2025-05-18 06:34:56
|
yeah, a ML decoder that actually works with internal JPEG data could do wonders, I think...
|
|
|
|
Demiurge
|
2025-05-18 06:34:57
|
It makes sense for libjpegli and libjxl to share a source tree since most of the code is common
|
|
|
|
Jyrki Alakuijala
|
|
Demiurge
Me too. But it doesn't need to be in a separate repo from jxl for that. It just needs to be convenient to build and package it as a drop in replacement library. Would help to have some headers too.
|
|
2025-05-18 06:35:10
|
If you want to replace the decoder in Chrome then jxl being added would create unusual excitement.
|
|
2025-05-18 06:35:46
|
For political and package size issues best separated...
|
|
|
|
Demiurge
|
2025-05-18 06:35:48
|
Don't say that forbidden cursed browser's name here in this sacred place!
|
|
|
|
username
|
2025-05-18 06:35:59
|
speaking of jpegli, thoughts on this PR?: https://github.com/google/jpegli/pull/130
|
|
|
|
Demiurge
|
|
Jyrki Alakuijala
For political and package size issues best separated...
|
|
2025-05-18 06:36:50
|
Well just make it easy for the packager to build and install jpegli separately from libjxl.
|
|
2025-05-18 06:37:10
|
That makes way more sense than having a separate repo
|
|
2025-05-18 06:37:38
|
That way they can share code but the packager can still install them separately and make separate packages for them!
|
|
2025-05-18 06:37:48
|
Everyone wins
|
|
2025-05-18 06:38:14
|
Plus it helps drive awareness of jxl if they have to download libjxl source to compile and build/install jpegli
|
|
2025-05-18 06:38:34
|
And the binary package size remains minimal
|
|
2025-05-18 06:38:42
|
Everyone wins
|
|
2025-05-18 06:40:58
|
Idk much about cmake but there should be an "install" target specific to jpegli that only installs jpegli related stuff. It should be obvious for newcomers how to use it so packagers can make a separate package for libjpegli
|
|
|
|
Fab
|
2025-05-18 06:44:13
|
I've integrated slow bot improvements to fight Rebecca sindrome
|
|
2025-05-18 06:45:02
|
Now I have succeded to ruin high popular 500 milion views video quality and libaom is disabled on 99% of videos and most uses a hw SVT av1 hdr
|
|
2025-05-18 06:45:32
|
No stupid things
|
|
2025-05-18 06:46:19
|
No svt av1 psy ex
|
|
|
|
Jyrki Alakuijala
|
|
username
speaking of jpegli, thoughts on this PR?: https://github.com/google/jpegli/pull/130
|
|
2025-05-18 07:02:47
|
Looks like a big PR. Usually id ask if it can be split into five separate PRs, but on the other hand it is ready as is and this is volunteer work...
|
|
|
|
Fab
|
2025-05-18 07:30:49
|
That's some serious marketing. My single got duped by creating a new account and make seems like dove ti trovi tu was something I wrote
|
|
2025-05-18 07:31:04
|
Sony music knows their marketing
|
|
|
|
spider-mario
|
|
Demiurge
Anyone seen dzgas around? I think that was his name
|
|
2025-05-18 08:56:56
|
now it’s <@226977230121598977>
|
|
|
|
Demiurge
|
2025-05-18 08:59:17
|
Oh
|
|
2025-05-18 09:10:47
|
Adaptive quantization isn't useful at high quality ycbcr JPEG?
|
|
|
|
jonnyawsom3
|
|
Demiurge
Adaptive quantization isn't useful at high quality ycbcr JPEG?
|
|
2025-05-18 10:01:53
|
https://discord.com/channels/794206087879852103/1301682361502531594
|
|
|
Quackdoc
|
2025-05-19 12:21:38
|
discord will always show that thread as unknown until I click it lmao
|
|
|
|
jonnyawsom3
|
|
Jyrki Alakuijala
Looks like a big PR. Usually id ask if it can be split into five separate PRs, but on the other hand it is ready as is and this is volunteer work...
|
|
2025-05-19 01:10:21
|
It was originally just a subsampling change, then we realised a lot of things were misconfigured/contradicting each other. I can try and split it soon, I was sick the past week so haven't had a chance to work on the repos
|
|
|
|
Demiurge
|
2025-05-19 02:04:09
|
Well it's small enough it might get approved anyways
|
|
2025-05-19 02:04:39
|
Even though it covers lots of different things it's mostly just cleanup
|
|
|
|
jonnyawsom3
|
2025-05-19 02:13:19
|
If anything needs to be reverted in future, it's mostly one line changes or moving of code, so wouldn't be hard
|
|
|
DZgas Ж
|
|
Demiurge
Anyone seen dzgas around? I think that was his name
|
|
2025-05-19 08:38:52
|
DZgas has gone insane after 9 years of being in Discord, has become disillusioned with computers and their ideology. Everything is always broken. Disillusioned with the fact that there is no goal, no meaning. Lost the idea. No motivation. People are also annoying. Sitting among people who do not break the law, but at the same time do things condemned by society, turned out to be nice. But for some reason my soul is still so empty... I don’t want to do anything, neither watch, nor listen, nor play... I don’t even know what to do with myself. I have already achieved everything I dreamed of 9 years ago. And then there is only emptiness. Daily emptiness, in which there is no meaning or goals.
—————————
Oh, and with such an avatar and nickname, for some reason people perceive criticism more normally, no longer seriously. And they don’t start attacking me for any word. Because I often have an unpopular, harsh opinion. Multipolarity of opinions. <:jxl:1300131149867126814>
|
|
|
|
Demiurge
|
2025-05-19 08:40:37
|
Haha, wow!
|
|
|
|
DZgas Ж
|
2025-05-19 08:42:16
|
jpeg xl is still not accepted anywhere. Where would I think. On strong LQ compression its artifacts are annoying. Okay. And on high compression... I use loseless when reducing the image size.
Have you solved the color problem yet? Discoloration? Fading?
|
|
|
|
Demiurge
|
2025-05-19 08:44:09
|
The chief psychovisual-tuning expert Jyrki was working on a different project and recently returned to worknig on libjxl
|
|
2025-05-19 08:45:07
|
He's aware of the strong chromatic ringing artifacts and desaturation problem
|
|
2025-05-19 08:45:30
|
Now that he's back it's likely there will be more improvements soon.
|
|
|
|
DZgas Ж
|
|
Demiurge
The chief psychovisual-tuning expert Jyrki was working on a different project and recently returned to worknig on libjxl
|
|
2025-05-19 08:45:52
|
well... he did a good job of correcting my earlier reports to him about color artifacts. but those were isolated cases. which were mostly with red. but the current problem is so global
|
|
|
|
Demiurge
|
2025-05-19 08:46:34
|
I agree. I have recently started to notice, when looking closer, that there are these chromatic ripples throughout every image.
|
|
2025-05-19 08:47:14
|
I think he's aware of it and planning to do some more tuning
|
|
|
|
DZgas Ж
|
|
DZgas Ж
what is this? at the beginning of the file
|
|
2025-05-19 08:49:16
|
I wish someone else would answer this <:This:805404376658739230> https://discord.com/channels/794206087879852103/794206170445119489/1352325058680459390
|
|
|
|
Demiurge
|
|
DZgas Ж
DZgas has gone insane after 9 years of being in Discord, has become disillusioned with computers and their ideology. Everything is always broken. Disillusioned with the fact that there is no goal, no meaning. Lost the idea. No motivation. People are also annoying. Sitting among people who do not break the law, but at the same time do things condemned by society, turned out to be nice. But for some reason my soul is still so empty... I don’t want to do anything, neither watch, nor listen, nor play... I don’t even know what to do with myself. I have already achieved everything I dreamed of 9 years ago. And then there is only emptiness. Daily emptiness, in which there is no meaning or goals.
—————————
Oh, and with such an avatar and nickname, for some reason people perceive criticism more normally, no longer seriously. And they don’t start attacking me for any word. Because I often have an unpopular, harsh opinion. Multipolarity of opinions. <:jxl:1300131149867126814>
|
|
2025-05-19 08:50:06
|
I have such an innocent looking name and avatar... and yet people are still on the edge of their nerves.
|
|
2025-05-19 08:50:56
|
People have a lot of stress in their lives and we don't need to make any more of it
|
|
2025-05-19 08:51:46
|
I always hope people will let go of unnecessary tension and smile even when you're with people you disagree with.
|
|
|
|
Lumen
|
|
DZgas Ж
DZgas has gone insane after 9 years of being in Discord, has become disillusioned with computers and their ideology. Everything is always broken. Disillusioned with the fact that there is no goal, no meaning. Lost the idea. No motivation. People are also annoying. Sitting among people who do not break the law, but at the same time do things condemned by society, turned out to be nice. But for some reason my soul is still so empty... I don’t want to do anything, neither watch, nor listen, nor play... I don’t even know what to do with myself. I have already achieved everything I dreamed of 9 years ago. And then there is only emptiness. Daily emptiness, in which there is no meaning or goals.
—————————
Oh, and with such an avatar and nickname, for some reason people perceive criticism more normally, no longer seriously. And they don’t start attacking me for any word. Because I often have an unpopular, harsh opinion. Multipolarity of opinions. <:jxl:1300131149867126814>
|
|
2025-05-19 08:51:50
|
(side note, I love your avatar and the fact that you got multiple expressions of it, it is really beautiful >w< I wish I had something like that too)
|
|
|
|
Demiurge
|
2025-05-19 08:52:10
|
Disagreement can be a nice thing and not a bad thing.
|
|
2025-05-19 08:52:27
|
I like being surrounded by many different perspectives. It's too creepy when everyone thinks the same.
|
|
|
|
DZgas Ж
|
|
Demiurge
I have such an innocent looking name and avatar... and yet people are still on the edge of their nerves.
|
|
2025-05-19 08:53:09
|
people can't believe that some person on the internet would be so smart, smarter than them, that they deny it until the end
so you have to be a psycho, a mad scientist. yeah, this guy is nuts.
and suddenly your words are perceived better. paradox. society.
|
|
|
|
Demiurge
|
2025-05-19 08:54:47
|
People perceive what better? Mad scientists?
|
|
|
|
DZgas Ж
|
|
|
Demiurge
|
2025-05-19 08:55:24
|
In my experience, people hate that kind of thing. Anything perceived as quirky or silly or unusual is highly frowned upon.
|
|
2025-05-19 08:55:47
|
Because Life is Serious Buddy, Serious Business Only!
|
|
2025-05-19 08:56:43
|
No one really understands the "ha ha only serious" ethos
|
|
|
|
DZgas Ж
|
|
Lumen
(side note, I love your avatar and the fact that you got multiple expressions of it, it is really beautiful >w< I wish I had something like that too)
|
|
2025-05-19 08:57:35
|
I had to brush she hair a little for my avatar
|
|
|
Demiurge
In my experience, people hate that kind of thing. Anything perceived as quirky or silly or unusual is highly frowned upon.
|
|
2025-05-19 08:59:24
|
It depends on how smart the person is. If he gets angry at your appearance and preferences. This is an argument to understand that he is just stupid, he is ignorant. And you shouldn't communicate with him more
|
|
2025-05-19 09:00:22
|
yes i can write top 50 reasons why jpeg xl is bad. but this is a discussion, these are arguments, and no one will be against here
|
|
|
|
Demiurge
|
2025-05-19 09:00:47
|
There are always at least 2 or 3 of that kind of person in every place.
|
|
|
|
DZgas Ж
|
|
Demiurge
There are always at least 2 or 3 of that kind of person in every place.
|
|
2025-05-19 09:01:40
|
🧱 👋 be prepared
|
|
|
|
Demiurge
|
|
DZgas Ж
yes i can write top 50 reasons why jpeg xl is bad. but this is a discussion, these are arguments, and no one will be against here
|
|
2025-05-19 09:01:58
|
Maybe people forget that you wouldn't be writing up something like that unless you actually cared enough to
|
|
2025-05-19 09:02:33
|
People actually criticize things they like and care about...
|
|
|
|
DZgas Ж
|
|
Demiurge
Maybe people forget that you wouldn't be writing up something like that unless you actually cared enough to
|
|
2025-05-19 09:05:02
|
maybe people don't know what they want, why they want it, what for...
you start to argue with a person? to find out his opinion - good. to get to the truth in disputes - good... but to just prove to him that he is wrong, or just like that. well, it can be fun, but it wastes time. 9 years in discord grows skin of incredible thickness.
|
|
2025-05-19 09:06:45
|
jpeg xl could have been done in silence, somewhere in the office, all these years. but the fact that there is a place where I am now deserves respect :JXL:
|
|
2025-05-19 09:07:07
|
<:jxl:1300131149867126814> :JXL: <:logo:829708783336816671> <:JPEG_XL:805860709039865937> <:Xjxl:822166843313225758>
|
|
|
|
Demiurge
|
2025-05-19 09:34:38
|
<:JXL:805850130203934781>
|
|
|
DZgas Ж
maybe people don't know what they want, why they want it, what for...
you start to argue with a person? to find out his opinion - good. to get to the truth in disputes - good... but to just prove to him that he is wrong, or just like that. well, it can be fun, but it wastes time. 9 years in discord grows skin of incredible thickness.
|
|
2025-05-19 09:36:33
|
People are also locked into a dualistic, black and white worldview without nuance, where multiple different perspectives can't coexist, because there has to be a winner and a loser.
|
|
2025-05-19 09:36:51
|
Truth isn't the objective, only "winning"
|
|
2025-05-19 09:37:05
|
And there's no nuance in the "truth"
|
|
|
|
Jyrki Alakuijala
|
|
DZgas Ж
jpeg xl is still not accepted anywhere. Where would I think. On strong LQ compression its artifacts are annoying. Okay. And on high compression... I use loseless when reducing the image size.
Have you solved the color problem yet? Discoloration? Fading?
|
|
2025-05-19 11:14:40
|
I'm finding some improvements right now 😄
|
|
2025-05-19 11:15:24
|
I found a way to make 'EstimateEntropy' in enc_ac_strategy.cc more compatible on how it is used (to be surface weighted) in a way that didn't make the images look worse
|
|
2025-05-19 11:15:38
|
it looks to me that this will solve the ringing and the color fading
|
|
2025-05-19 11:16:20
|
I'll be able to surface this within two weeks, I just found this solution 30 min ago so it is a bit early to tell if it has side effects
|
|
2025-05-19 11:16:51
|
it seems to me that it is aesthetically the right thing and it seems to also be an improvement right on, so probably it opens up a ton of other tuning possibilities
|
|
|
Demiurge
Adaptive quantization isn't useful at high quality ycbcr JPEG?
|
|
2025-05-19 11:22:41
|
not sure, perhaps we didn't know how to make it quickly -- intuitively it would be useful
|
|
|
Mine18
|
|
Jyrki Alakuijala
I found a way to make 'EstimateEntropy' in enc_ac_strategy.cc more compatible on how it is used (to be surface weighted) in a way that didn't make the images look worse
|
|
2025-05-19 11:36:21
|
did that thread on 0.8 images looking better than 0.11 help in this discovery?
|
|
|
|
DZgas Ж
|
|
Jyrki Alakuijala
it looks to me that this will solve the ringing and the color fading
|
|
2025-05-19 11:50:40
|
I can hardly wait to run the tests in two weeks and uncover even more new issues 😉 😉 <:jxl:1300131149867126814>
|
|
|
|
Jyrki Alakuijala
|
|
Mine18
did that thread on 0.8 images looking better than 0.11 help in this discovery?
|
|
2025-05-19 11:52:17
|
yes of course
|
|
|
DZgas Ж
I can hardly wait to run the tests in two weeks and uncover even more new issues 😉 😉 <:jxl:1300131149867126814>
|
|
2025-05-19 11:53:12
|
I will appreciate this of course! and very likely new weaknesses (or other old weaknesses) will be exposed by changing this kind of changes
|
|
|
|
DZgas Ж
|
2025-05-19 11:53:28
|
but, for now, the problems are going away. (except for the modular loseless problem.) things are only getting better for vardct. However, there are problems with fading in 0.6, 0.7 and 0.8. I checked. It's always been like this
|
|
|
|
Demiurge
|
2025-05-19 11:57:26
|
Progress is slow, but... steady, which is good :)
|
|
|
|
DZgas Ж
|
2025-05-19 11:58:35
|
<:PepeHands:808829977608323112> I've managed to get old while it's being made
|
|
|
|
Demiurge
|
2025-05-19 11:58:55
|
Well then get young
|
|
|
|
DZgas Ж
|
2025-05-19 11:59:27
|
No, I guess not <:H264_AVC:805854162079842314>
|
|
|
|
Demiurge
|
2025-05-19 02:59:01
|
Just transmute a philosopher's stone and obtain eternal youth? Duh?
|
|
2025-05-19 03:00:38
|
Sick and tired of being sick and tired? Is getting old starting to get old? Well I've got good news for you. With the latest ancient advances in alchemy, you too can get your youth back. Eternally.
|
|
2025-05-19 03:01:49
|
Complete your magnum opus today. Call now and get a copy of the Emerald Tablet signed by Sir Isaac Newton!
|
|
2025-05-19 03:02:15
|
3 easy payments of your heart, mind and soul.
|
|
2025-05-19 03:03:11
|
Act fast! You don't have eternity to wait! Not yet anyways.
|
|
|
|
Jyrki Alakuijala
|
2025-05-19 04:44:22
|
make a next generation of hackers/coders/researchers if you are concerned about the eternity 👶 🍼 👶 🍼 👶 🍼 👶
|
|
|
|
jonnyawsom3
|
|
Jyrki Alakuijala
I found a way to make 'EstimateEntropy' in enc_ac_strategy.cc more compatible on how it is used (to be surface weighted) in a way that didn't make the images look worse
|
|
2025-05-19 05:53:10
|
While we were exploring some other areas, we noticed EstimateCost was giving very poor results in certain scenarios, due to assuming the use of certain predictors.
I'm sure there's lots of room for improvement in most Estimate functions, either for more accuracy or smarter heuristics
|
|
|
|
Jyrki Alakuijala
|
2025-05-19 06:12:28
|
it looks rather promising, but some more work is needed to actually submit this
before/after/original
|
|
|
|
damian101
|
2025-05-19 06:46:10
|
after loses some detail throughout the image compared to before...
but doesn't produce those very annoying artifacts...
|
|
|
|
Jyrki Alakuijala
|
2025-05-19 06:47:49
|
yes, you cannot have better quality everywhere -- compression unfortunately rarely works like that -- it is some sort of a compromise 🙂
I may be able to restore the sharpness a little, but don't know yet
it is difficult to balance because I made the mistake of deciding to have one integral transform block selection for all XYB, instead of having three separate -- three separate would be so much easier to encode for
|
|
2025-05-19 06:48:29
|
next time someone makes an image format, don't make that mistake :------)
|
|
2025-05-19 06:48:50
|
at the time it seemed like a great idea
|
|
|
|
username
|
2025-05-19 06:49:14
|
spec level mistake I'm assuming based on the words surrounding it?
|
|
|
|
Jyrki Alakuijala
|
2025-05-19 06:49:50
|
yeeees, i believe so -- although I haven't tried it out ever if it would be better the other way around, it is just very difficult like it is
|
|
|
|
damian101
|
2025-05-19 06:51:29
|
didn't know it was used for intra coding as well actually, but makes sense
|
|
2025-05-19 06:53:04
|
H.264 appears to use it for inter only
|
|
|
|
_wb_
|
2025-05-19 06:57:18
|
Having things more per-component rather than mixing it would also have the advantage of being able to do grayscale more efficiently and allowing stuff like CMYK. Then again there's some signaling cost for doing the control fields 3 times instead of once, and we do get some decode speedups from being able to hardcode 3 components...
|
|
|
|
Jyrki Alakuijala
|
2025-05-19 07:16:15
|
this change is starting to look increasingly good -- I'm optimistic I will be able to make a PR this week
|
|
|
|
Demiurge
|
|
Jyrki Alakuijala
it looks rather promising, but some more work is needed to actually submit this
before/after/original
|
|
2025-05-20 06:40:24
|
It's not an obvious improvement? The grass looks like it got softer and blurrier. The "ridge" at the top of the bench's back-rest looks more distorted too.
|
|
2025-05-20 06:40:52
|
I actually can't see the improvement on this anti-jxl monitor
|
|
|
|
Mine18
|
2025-05-20 06:46:02
|
lol these images are so close together that they're basically identical to me, a pixel peeper i am not
|
|
|
Tirr
|
2025-05-20 07:04:27
|
I do see less chroma ringing in the second image, but yeah, it's blurrier
|
|
|
|
_wb_
|
2025-05-20 07:21:45
|
it depends a lot on where I look, some regions are better, some regions are worse. The chroma halos indeed are reduced but overall it's blurrier.
|
|
|
|
Demiurge
|
|
Mine18
lol these images are so close together that they're basically identical to me, a pixel peeper i am not
|
|
2025-05-20 07:26:07
|
It actually helps not to zoom in too close at first, but to see if you can pick up any differences when looking from a comfortable and healthy distance away.
|
|
|
|
Mine18
|
2025-05-20 07:27:03
|
yeah but the differences seem to be more of pixel shifting than any definitive noise reduction, or better detail retention (at least for me)
ironically looking closer helped me notice a stray artifact in the before picture that's not in the after picture
|
|
|
|
Demiurge
|
2025-05-20 07:28:10
|
The grass is definitely flatter and lower fidelity in the "after" image from what I can tell over here
|
|
2025-05-20 07:29:53
|
As well as the gravel near the top edge of the image
|
|
2025-05-20 07:30:10
|
Maybe it would be helpful to test at a "slightly" lower bitrate
|
|
|
|
Mine18
|
2025-05-20 07:30:38
|
yeah, doesn't help that the source image itself isn't particularly high fidelity
|
|
|
|
Demiurge
|
2025-05-20 07:40:19
|
I think testing at a high bitrate is usually more important though and should be given priority. Shouldn't compare at low bitrate without also comparing at high bitrate at the same time
|
|
|
|
Mine18
|
2025-05-20 07:41:04
|
yeah that's also important, just thats its much harder to compare them
|
|
|
|
Demiurge
|
2025-05-20 08:16:45
|
It's not that hard if you have a bit of patience and enough experience.
|
|
2025-05-20 08:17:48
|
And have the patience to view at a normal viewing distance at 1x scale as well...
|
|
|
|
Jyrki Alakuijala
|
|
Mine18
yeah, doesn't help that the source image itself isn't particularly high fidelity
|
|
2025-05-20 10:10:16
|
I took that photo using a Canon DSLR with a hobbyist lense and subsampled it 4x4.
|
|
|
_wb_
it depends a lot on where I look, some regions are better, some regions are worse. The chroma halos indeed are reduced but overall it's blurrier.
|
|
2025-05-20 10:16:44
|
I believe I will be able to restore some of the textures, but there is no free lunch in compression -- when bits are redivided, some parts will be better, others worse
with larger integral transforms we get better complex textures and more precise curved geometries, but ringing comes necessarily too, as their drunken uncle, and R-G ringing is not such a great beauty for the eye
I only compute a luma-mask in the encoder, I could compute and R-G mask, too, which would make the ringing decisions a bit better, but that would increase the memory consumption and slow down the encoding (and further complexify everything quite a bit), so I'm not planning to do that for now
|
|
|
|
Demiurge
|
2025-05-20 05:12:40
|
I wonder, Jyrki, if you also have an interest in possible psychovisual tricks and optimizations that could be applied to Squeeze and other Modular tools outside of DCT
|
|
2025-05-20 05:13:38
|
With different distortion patterns and different possible techniques for hiding the distortion
|
|
2025-05-20 05:14:21
|
Sometimes there IS a free lunch in compression, since we are talking about subjective, lossy techniques that are designed to trick our eyes. You get a free lunch when you get better at hiding the distortion from our eyes.
|
|
2025-05-20 05:16:11
|
You can have courser and less accurate quantization, objectively worse distortion, but at the same time higher fidelity. Simply by hiding the quantization artifacts in places where it gets masked by the signal.
|
|
2025-05-20 05:16:52
|
And spreading/diffusing the error in ways that allow our eyes to see the original image underneath
|
|
|
|
jonnyawsom3
|
2025-05-20 05:16:57
|
You want noise based compression artifacts
|
|
|
|
Demiurge
|
2025-05-20 05:19:06
|
Really any errant signal that isn't part of the original signal is often called "noise" like in "peak signal/noise ratio"
|
|
2025-05-20 05:19:20
|
But some noise is harder to see than others
|
|
2025-05-20 05:19:50
|
The trick with lossy compression is to make all the errors as hard to see as possible
|
|
2025-05-20 05:20:26
|
By hiding all the errors in places where the original signal helps to mask/hide it
|
|
2025-05-20 05:20:52
|
And using error diffusion so the error seems to average itself out closer to the original signal
|
|
|
|
jonnyawsom3
|
2025-05-20 05:21:06
|
`--iso_photon_noise 200` banding is now solved, noise hides the quantization :P
|
|
|
juliobbv
|
|
You want noise based compression artifacts
|
|
2025-05-20 06:46:20
|
noise normalization? 😛
|
|
2025-05-20 06:46:48
|
taking a page from Vorbis ~~and SVT-AV1~~
|
|
|
|
Jyrki Alakuijala
|
|
Demiurge
Sometimes there IS a free lunch in compression, since we are talking about subjective, lossy techniques that are designed to trick our eyes. You get a free lunch when you get better at hiding the distortion from our eyes.
|
|
2025-05-20 08:14:44
|
I mean that the existing situation is pretty close to an optimum and it is not easy to make progress on all axes. And red green ringing is the worse artefact right now.
|
|
|
|
Demiurge
|
|
Jyrki Alakuijala
I mean that the existing situation is pretty close to an optimum and it is not easy to make progress on all axes. And red green ringing is the worse artefact right now.
|
|
2025-05-20 08:15:51
|
I think a really good test image to tune the ringing, where it's really noticeable, is the Clovisfest image
|
|
2025-05-20 08:17:47
|
https://github.com/afontenot/image-formats-comparison/blob/master/comparisonfiles/subset1/original/Clovisfest.png
|
|
|
|
Jyrki Alakuijala
|
|
You want noise based compression artifacts
|
|
2025-05-20 08:20:23
|
The ac strategy could use larger transforms when there is photon noise.
|
|
|
|
A homosapien
|
|
Jyrki Alakuijala
I believe I will be able to restore some of the textures, but there is no free lunch in compression -- when bits are redivided, some parts will be better, others worse
with larger integral transforms we get better complex textures and more precise curved geometries, but ringing comes necessarily too, as their drunken uncle, and R-G ringing is not such a great beauty for the eye
I only compute a luma-mask in the encoder, I could compute and R-G mask, too, which would make the ringing decisions a bit better, but that would increase the memory consumption and slow down the encoding (and further complexify everything quite a bit), so I'm not planning to do that for now
|
|
2025-05-20 08:21:15
|
I feel like the slower technique could be relegated to efforts 8+. Some love and care for higher efforts would be nice.
|
|
2025-05-20 08:21:36
|
Since currently effort 6/7 is about as good as JXL gets honestly
|
|
|
|
juliobbv
|
|
Jyrki Alakuijala
I believe I will be able to restore some of the textures, but there is no free lunch in compression -- when bits are redivided, some parts will be better, others worse
with larger integral transforms we get better complex textures and more precise curved geometries, but ringing comes necessarily too, as their drunken uncle, and R-G ringing is not such a great beauty for the eye
I only compute a luma-mask in the encoder, I could compute and R-G mask, too, which would make the ringing decisions a bit better, but that would increase the memory consumption and slow down the encoding (and further complexify everything quite a bit), so I'm not planning to do that for now
|
|
2025-05-20 08:28:37
|
Have you considered performing a preliminary DCT analysis on blocks to determine if those regions are "grainy" vs "stripey", and chosen influence transform size based on that info?
|
|
2025-05-20 08:30:26
|
depending on how it's done, total overhead shouldn't be too bad especially for the higher effort levels I think
|
|
2025-05-20 08:34:16
|
JXL doesn't have semi-decoupled chroma partitioning, right?
|
|
|
|
_wb_
|
2025-05-20 08:36:14
|
Block selection is for all components at once
|
|
2025-05-20 08:36:26
|
And so is adaptive quantization
|
|
|
|
juliobbv
|
2025-05-20 08:40:36
|
yeah, JXL will need to get creative then
|
|
2025-05-20 08:41:31
|
maybe a saturation mask could do a trick?
|
|
|
|
_wb_
|
2025-05-20 08:41:46
|
There are so many potential heuristics to try. My intuitive idea would be to start from all 8x8 and greedily merge adjacent blocks that are sufficiently similar, in terms of the amount of energy in the different frequency bands but also maybe just in terms of DC values (at a strong DC discontinuity you probably want to avoid using large blocks).
|
|
|
|
juliobbv
|
2025-05-20 08:42:28
|
that sounds like a reasonable approach
|
|
|
|
_wb_
|
2025-05-20 08:44:54
|
Also note that we can do non-naturally aligned blocks (like an 8x8 followed by a 32x32) so there a bit more options than what you can usually do in formats with a recursive splitting approach
|
|
2025-05-20 08:48:23
|
Though I think libjxl currently only or mostly only uses naturally aligned blocks, filling one 64x64 region at a time.
|
|
|
|
Demiurge
|
2025-05-20 08:52:36
|
I think that the most important thing is that the quantization error is diffused and rounded/quantized in a way that balances/averages out without over-/under-exaggeration like ringing/blurring
|
|
2025-05-20 08:55:15
|
I think a lot of the big visual problems stem from how certain values get rounded
|
|
2025-05-20 08:56:28
|
And I think a more careful way handling the rounding error could help
|
|
2025-05-20 08:56:44
|
Like the desaturation issue is probably a simple rounding problem for example
|
|
2025-05-20 08:58:15
|
Like it looks like it's rounding a value down rather than trying to round it in a way that it balances out to the original value. I think error diffusion can probably be applied to DCT coefficients too
|
|
|
|
_wb_
|
2025-05-20 08:58:43
|
The default quant matrices for X and especially B are very steep compared to that for Y. That makes sense but it can cause ugly chroma ringing. It might be better to use less steep matrices... There is no big signaling cost to using non-default quant matrices as long as they're still of the parametric kind.
|
|
|
|
Demiurge
|
2025-05-20 08:59:55
|
Default matrices as in they're part of the spec or just default in libjxl?
|
|
|
CrushedAsian255
|
|
_wb_
The default quant matrices for X and especially B are very steep compared to that for Y. That makes sense but it can cause ugly chroma ringing. It might be better to use less steep matrices... There is no big signaling cost to using non-default quant matrices as long as they're still of the parametric kind.
|
|
2025-05-20 09:00:35
|
so its like how pretty much every JPEG file has a custom DQT and DHT ?
|
|
|
|
_wb_
|
2025-05-20 09:01:52
|
Spec has various layers of default matricess (super default, parameterized, fully custom), I think libjxl only uses super default
|
|
|
|
Demiurge
|
2025-05-20 09:01:53
|
I assumed every file defines the quant matrix just like jpeg91
|
|
2025-05-20 09:03:16
|
I didn't know there was a "super default" matrix or is there multiple "super default" matrices?
|
|
|
|
_wb_
|
2025-05-20 10:05:58
|
There's a default with just one global scaling factor iirc. And then you can also deviate from that with a collection of parametrized matrices to choose from. Or you can go fully custom. But that's only used for jpeg recompression.
|
|
|
|
Demiurge
|
2025-05-20 10:43:58
|
So the spec itself is somewhat opinionated on the quant matrix it sounds like?
|
|
|
|
juliobbv
|
2025-05-20 10:48:41
|
sounds more like: you can get a "good enough" general purpose default matrix for very cheap, and if you're thinking for a more advanced scenario custom QMs are available
|
|
|
|
CrushedAsian255
|
|
_wb_
There's a default with just one global scaling factor iirc. And then you can also deviate from that with a collection of parametrized matrices to choose from. Or you can go fully custom. But that's only used for jpeg recompression.
|
|
2025-05-21 05:00:47
|
What is the signalising overhead for the fully custom matrix
|
|
|
|
jonnyawsom3
|
|
CrushedAsian255
What is the signalising overhead for the fully custom matrix
|
|
2025-05-21 05:10:38
|
Depends. Fully custom is stored as a float modular subframe with dimensions matching the size of the table
|
|
|
|
Jyrki Alakuijala
|
|
_wb_
There's a default with just one global scaling factor iirc. And then you can also deviate from that with a collection of parametrized matrices to choose from. Or you can go fully custom. But that's only used for jpeg recompression.
|
|
2025-05-21 08:17:19
|
quantization matrices have parameterized forms, I think that is also in the spec as an alternative
I came up with the quantization matrices by lots and lots of experimentation and optimizing things using my test corpora
everything was connected, i.e., gaborish strength, balance between luma to chroma, etc. affected the quantization matrices
|
|
2025-05-21 08:17:52
|
I just optimized them for the set I thought would be useful
|
|
2025-05-21 08:18:06
|
as a result some of the transforms are more and some less useful
|
|
2025-05-21 08:20:38
|
the quantization matrices take up space when computed, especially the 256x256 (x 3 for XYB) (x 4 for float), 768 kB for that alone...
|
|
|
|
_wb_
|
2025-05-21 08:24:18
|
yeah, we only materialize them when they're actually used, for that reason
|
|
2025-05-21 08:28:19
|
and yes, parameterized quant matrices are in the spec, and you can even choose the granularity of the parameterization, with e.g. 1 to 16 parameters per dct8x8 table.
|
|
2025-05-21 08:29:32
|
but I think at this point libjxl only uses the all_default matrices when doing normal lossy encoding; only for jpeg recompression and for non-perceptual encoding it uses different matrices
|
|
2025-05-21 08:30:30
|
the all_default matrices for dct8x8 corresponds to these parameters:
`{ {3150.0, 0.0, −0.4, −0.4, −0.4, −2.0}, {560.0, 0.0, −0.3, −0.3, −0.3, −0.3}, {512.0, −2.0, −1.0, 0.0, −1.0, −2.0} }`
|
|
2025-05-21 08:31:26
|
I suppose those parameters correspond to diagonal frequency bands and express how steep they go
|
|
2025-05-21 08:34:30
|
These are the default matrices for dct8x8 (after rescaling them to have 1 in the DC position, to make it easier to compare them)
|
|
2025-05-21 08:41:52
|
B is super coarse in the highest frequencies (and so is X in the very highest freqs), which usually makes perceptual sense but I think it sometimes bites us and going less steep would be safer (and to avoid too much increase in bpp, you could compensate by zeroing some of those high freq coeffs conditionally (only when the error is sufficiently masked) rather than always being aggressive on those coeffs.
|
|
2025-05-21 08:48:44
|
The signaling cost of deviating from the default tables should be small enough. Each of the parameters is represented as an f16, so for dct8x8 when using 6 parameters like in the default, it costs 6x3x2=36 bytes and a few bits (but you could also use fewer than 6 parameters and it would cost even less).
|
|
|
Kleis Auke
|
2025-05-21 11:08:32
|
I'm not sure if this is possible, but is there a XYB ICC profile available that can be used to convert images into XYB color space? I think the "XYB_Per" ICC profile is input/view only, it does contain a `B2A0` (PCS -> device) transform tag but that seems to be no-op. Context: <https://github.com/libvips/libvips/issues/4360>.
|
|
|
|
Demiurge
|
2025-05-21 11:41:11
|
afaik there is no default quant matrix in original jpeg92
|
|
2025-05-21 11:42:05
|
The spec was un-opinionated you could say, and every encoder used its own different matrices
|
|
2025-05-21 11:42:49
|
You can even tell what sort of camera was used to take a photo by comparing it to known quant matrices
|
|
2025-05-21 11:43:17
|
It's a whole lesson on digital forensics
|
|
2025-05-21 11:45:07
|
Storing the matrix as a modular subframe sounds like a cool idea that's obvious in a way
|
|
2025-05-21 11:45:56
|
Since the matrix is conveniently expressed as a 2D bitmap
|
|
2025-05-21 11:46:25
|
I also heard that jxl has more than just the standard zigzag dct
|
|
|
|
_wb_
|
|
Kleis Auke
I'm not sure if this is possible, but is there a XYB ICC profile available that can be used to convert images into XYB color space? I think the "XYB_Per" ICC profile is input/view only, it does contain a `B2A0` (PCS -> device) transform tag but that seems to be no-op. Context: <https://github.com/libvips/libvips/issues/4360>.
|
|
2025-05-21 11:51:13
|
<@604964375924834314> would it be hard to make an ICC profile which also includes the fwd xyb transform? Seems useful indeed, to leverage existing cms libraries to do this conversion...
|
|
|
Demiurge
afaik there is no default quant matrix in original jpeg92
|
|
2025-05-21 11:54:33
|
I think the original idea was to have implicit quant tables in some use cases, but I don't think anyone actually used that because it's usually not worth the filesize saving for the system level complication of having to know what the implicit quant table actually is...
|
|
|
Demiurge
I also heard that jxl has more than just the standard zigzag dct
|
|
2025-05-21 11:58:19
|
Coefficient ordering can be signaled, zigzag is the default (iirc) but you can use any other order. It can help a bit with entropy coding if you can do that — and also it is how progressive passes are done in jxl: all coefficients are always signaled in every pass but you just reorder them so if you don't signal some, they end up in the tail of zeroes...
|
|
|
|
spider-mario
|
2025-05-21 11:59:16
|
forward transform might be possible with some effort and especially file size, whereas we were trying to keep the profile as compact as we could when we made it (hence the use of CIELAB as connection space instead of XYZ so that dropping to an 8-bit LUT wouldn’t be so bad)
|
|
|
|
_wb_
|
2025-05-21 12:01:19
|
File size is less of a concern here, you can have an authoring profile that is bulky and use the delivery profile when needed
|
|
|
|
Demiurge
|
|
_wb_
These are the default matrices for dct8x8 (after rescaling them to have 1 in the DC position, to make it easier to compare them)
|
|
2025-05-21 12:03:19
|
I wonder if the quantization error can be "shaped" and diffused in a manipulative way that avoids the usual ringing and blurring... I mean mozjpeg looked miraculous when it first came out, avoiding the ringing artifacts around text for example, then Jyrki figured out how to do even better somehow with jpegli pulling a rabbit out of a hat
|
|
2025-05-21 12:04:31
|
It looks like Jyrki basically figured out how to solve the issue... except for some reason not with chroma.
|
|
2025-05-21 12:05:10
|
Only the chroma channels have ringing still
|
|
|
|
_wb_
|
2025-05-21 12:06:38
|
Mozjpeg avoids ringing around text by pretending black is super black and white is super white, and then relying on the decoder to clamp things back to normal black and white. That only works for specifically black text on a white background or white text on a black background, though...
|
|
2025-05-21 12:07:10
|
(also there is some overflow issue that still needs to be fixed: https://github.com/mozilla/mozjpeg/issues/444)
|
|
|
|
Demiurge
|
2025-05-21 12:07:24
|
Clever cheating like that is great
|
|
|
|
_wb_
|
2025-05-21 12:08:06
|
With jxl I guess we could also do it to some extent, but we can also use patches for text so I think it's less urgent...
|
|
2025-05-21 12:08:40
|
Anyway that deringing approach doesn't work to prevent chroma ringing
|
|
|
|
Demiurge
|
2025-05-21 12:10:05
|
Well just in general, the manipulation and prediction of original/quantized/final values and rounding idiosyncrasies is exactly the sort of outside the box thinking that lossy compression is all about
|
|
2025-05-21 12:11:13
|
Along with preserving hints of the original image for the human visual system to recognize through the distorted signal
|
|
2025-05-21 12:12:03
|
Basically, using the quantization errors to your advantage instead of disadvantage
|
|
2025-05-21 12:12:25
|
That's how you win at lossy
|
|
2025-05-21 12:13:11
|
Even the error conveys useful info distributed into the error
|
|
2025-05-21 12:13:51
|
Information the human eye can notice
|
|
2025-05-21 12:14:59
|
If you can shape the error to include and represent real information mixed into it, then you win
|
|
|
|
Jyrki Alakuijala
|
|
_wb_
With jxl I guess we could also do it to some extent, but we can also use patches for text so I think it's less urgent...
|
|
2025-05-21 03:09:11
|
we don't have a maximum brightness concept in jpeg xl, minimum is of course there at 0.0
|
|
|
|
_wb_
|
2025-05-21 03:11:48
|
Yes so you could only do it in one direction (making black text -10 instead of 0), unless I guess you rely on the clamping done when converting to integer formats... But that's more risky
|
|
|
|
Jyrki Alakuijala
|
2025-05-21 03:39:34
|
we don't do this in jpegli btw
|
|
|
|
Demiurge
|
|
Jyrki Alakuijala
we don't do this in jpegli btw
|
|
2025-05-21 05:41:55
|
jpegli does a good job avoiding banding despite not using this trick. Idk what you did but you solved the ringing problem. Just not in the chroma space for some reason.
|
|
|
|
Jyrki Alakuijala
|
|
Demiurge
jpegli does a good job avoiding banding despite not using this trick. Idk what you did but you solved the ringing problem. Just not in the chroma space for some reason.
|
|
2025-05-21 05:54:41
|
jpegli computes intensity only masking field so that it knows where it is ok to ring and where it is dangerous -- because the masking field is intensity only, it doesn't properly compute the masking of chromacity ringing and there, something happens, not so good things
|
|
|
|
Demiurge
|
2025-05-21 05:55:25
|
I can't find any academic papers on error diffusion applied to DCT quantization, except for this one, where it's used to get rid of banding: https://www.sciencedirect.com/science/article/abs/pii/S0020019014002610
|
|
|
|
Jyrki Alakuijala
|
2025-05-21 05:55:59
|
I have tried to compute masking fields for R-G (V direction in jpeg), but it is difficult and stopped doing it
|
|
|
|
Demiurge
|
|
Jyrki Alakuijala
jpegli computes intensity only masking field so that it knows where it is ok to ring and where it is dangerous -- because the masking field is intensity only, it doesn't properly compute the masking of chromacity ringing and there, something happens, not so good things
|
|
2025-05-21 05:58:09
|
The same masking model can probably also be applied to the chroma channels in XYB as well, right? I imagine probably the same masking model would work well there - Sudden high-contrast chroma borders is a danger zone, low-contrast areas are okay.
|
|
|
|
Jyrki Alakuijala
|
2025-05-21 05:58:54
|
some earlier version perhaps around 2019-2021 used to have some R-G masking, but it was waste of computation as I didn't know how to do it well -- also masking is frequency specific, a high frequency masks other high frequencies and possibly low frequencies about half the wave length but not frequencies lower than that
|
|
2025-05-21 05:59:35
|
computing all that is complicated, takes a lot of time and effort to get right, and then encoding is really slow for a half a percent of improvement 🙂
|
|
|
|
Demiurge
|
|
Jyrki Alakuijala
some earlier version perhaps around 2019-2021 used to have some R-G masking, but it was waste of computation as I didn't know how to do it well -- also masking is frequency specific, a high frequency masks other high frequencies and possibly low frequencies about half the wave length but not frequencies lower than that
|
|
2025-05-21 05:59:53
|
Is this psychovisual masking theory documented anywhere? It sounds like a great thing that should be written down to help guide codec devs
|
|
|
Jyrki Alakuijala
computing all that is complicated, takes a lot of time and effort to get right, and then encoding is really slow for a half a percent of improvement 🙂
|
|
2025-05-21 06:00:50
|
Well, if it gets rid of weird chroma ringing artifacts, that's a pretty nice deal... Unless there's a cheaper way to do it...
|
|
2025-05-21 06:02:17
|
It's already done for the luma channel, just not chroma?
|
|
|
|
Jyrki Alakuijala
|
2025-05-21 06:04:29
|
yes
|
|
2025-05-21 06:04:47
|
but all decisions need to be fused because integral transform is chosen once for all XYB
|
|
|
|
Demiurge
|
2025-05-21 06:05:07
|
Maybe it's the kind of thing that's slow at first, but later on someone finds a really fast and efficient way to reduce the cost of computing the masking fields
|
|
|
|
Jyrki Alakuijala
|
2025-05-21 06:05:11
|
making it right for all leads to more small transforms, less continuity and 'texture'
|
|
2025-05-21 06:05:33
|
I'm counting on future generations getting that right 😛
|
|
|
|
Demiurge
|
2025-05-21 06:06:07
|
Optimization is always the last step
|
|
|
|
Jyrki Alakuijala
|
2025-05-21 06:06:36
|
for jpeg1 it took ~30 years for jpegli to arrive 😄
|
|
|
|
Demiurge
|
|
Jyrki Alakuijala
but all decisions need to be fused because integral transform is chosen once for all XYB
|
|
2025-05-21 06:06:42
|
You mean the varblock size right?
|
|
|
|
Jyrki Alakuijala
|
2025-05-21 06:06:53
|
varblock, yes
|
|
2025-05-21 06:07:08
|
but not just size there are 10 8x8 transforms to choose from
|
|
2025-05-21 06:07:15
|
but once chosen it is the same for all
|
|
2025-05-21 06:07:41
|
I was thinking that intensity decides it in any case and the rest is cheap to code so I didn't repeat it like I believe other codecs do
|
|
|
|
Demiurge
|
2025-05-21 06:08:58
|
10 transforms? Sounds a lot more complicated than jpeg92
|
|
|
|
jonnyawsom3
|
|
|
Demiurge
|
|
Jyrki Alakuijala
for jpeg1 it took ~30 years for jpegli to arrive 😄
|
|
2025-05-21 06:12:08
|
Well I know DCT compression is an incredible constantly evolving field but I should hope it doesn't take 30 years to at least get DCT more or less perfect in JXL encoders
|
|
2025-05-21 06:18:54
|
Or if not perfect then at I least hope it becomes more common for DCT encoders to use modular sub-frames more to assist with compression
|
|
2025-05-21 06:20:03
|
Dots, patches, splines, shape/cartoon layers...
|
|
|
|
Jyrki Alakuijala
|
2025-05-22 12:41:40
|
color ringing reduction refined
when I started with this I reworked the whole ac strategy selection to have more respect for elegance and mathematics, like not so sum up 8th powers of numbers and compare them to a 8th power of sum etc. but logic didn't beat tradition, and I just ended up complicating the existing somewhat funky code
https://github.com/libjxl/libjxl/pull/4267 is the PR
|
|
|
|
Demiurge
|
2025-05-22 03:06:18
|
Sounds like a gruelingly difficult problem that requires a lot of trial and error... Like a winding maze full of dead ends.
|
|
2025-05-22 03:13:28
|
Call me crazy but I don't really notice any significant chroma artifacts in the bench pic like I do with this one.
|
|
2025-05-22 03:16:21
|
jxl does really, really poorly on this balloon image, with very noticeable chroma ringing. I don't notice anything really in the bench picture, mostly the grass and gravel getting softer.
|
|
|
|
Jyrki Alakuijala
|
|
Demiurge
Sounds like a gruelingly difficult problem that requires a lot of trial and error... Like a winding maze full of dead ends.
|
|
2025-05-22 03:38:00
|
Correct analysis 🌞
|
|
|
|
Demiurge
|
2025-05-22 04:13:11
|
The subtle shading of the contoured surface of the balloons makes it very easy to notice any chroma ringing in this balloon image
|
|
2025-05-22 04:13:49
|
And jxl does particularly poorly on it. It's a "killer sample"
|
|
2025-05-22 04:16:32
|
Maybe a before and after picture of the balloons would be more enlightening.
|
|
|
Jyrki Alakuijala
color ringing reduction refined
when I started with this I reworked the whole ac strategy selection to have more respect for elegance and mathematics, like not so sum up 8th powers of numbers and compare them to a 8th power of sum etc. but logic didn't beat tradition, and I just ended up complicating the existing somewhat funky code
https://github.com/libjxl/libjxl/pull/4267 is the PR
|
|
2025-05-22 04:17:37
|
I can't say which one is better or worse here.
|
|
|
Jyrki Alakuijala
it looks rather promising, but some more work is needed to actually submit this
before/after/original
|
|
2025-05-22 04:18:15
|
But it's better than this at least.
|
|
2025-05-22 06:40:23
|
But I think the balloon image would be a much better test...
|
|
|
|
juliobbv
|
|
Demiurge
I can't say which one is better or worse here.
|
|
2025-05-22 07:23:02
|
focus on this particular region
|
|
2025-05-22 07:23:17
|
there's less R-G ringing in the new image
|
|
2025-05-22 07:42:55
|
unlike the previous before/after compo, most of the image seems to be unchanged otherwise, so it's easy to overlook the targeted improvement
|
|
|
|
Demiurge
|
2025-05-23 01:20:52
|
It's way harder to tell, compared to the curvy, contoured surface of the balloons, which is much more sensitive to artifacts like this
|
|
|
|
A homosapien
|
2025-05-23 01:53:35
|
R-G ringing is apparent in both images, but more so on the bench image since red/green artifacts are more visible with a grey background.
|
|
|
|
Demiurge
|
2025-05-23 02:51:06
|
I think the grainy gravel texture makes it harder to notice.
|
|
2025-05-23 02:51:46
|
If a single pixel is out of place on the balloons it changes the contoured shape and appearance and stands out a lot easier to see
|
|
2025-05-23 02:53:22
|
At least for my eyes. Plus like I said jxl does extremely badly on that Clovisfest image compared to other codecs.
|
|
|
|
jonnyawsom3
|
2025-05-23 02:55:04
|
Are you sure this isn't your anti-JXL monitor again?
|
|
|
|
Demiurge
|
2025-05-23 02:57:48
|
It's ugly as hell even on my iPhone.
https://afontenot.github.io/image-formats-comparison/#clovisfest&AV1=l&JPEGXL=l
|
|
2025-05-23 02:58:15
|
Look at the balloons on the rightmost edge of the image frame
|
|
2025-05-23 02:58:36
|
Especially the one on the bottom right. That one has tons of colorful noise added by JXL
|
|
2025-05-23 02:59:05
|
It would be delightful to see if these new patches fix that
|
|
|
|
jonnyawsom3
|
2025-05-23 03:00:09
|
That's not what the PRs have tried to fix. That's the desaturation/low B channel AC quality
|
|
|
|
Demiurge
|
2025-05-23 03:01:26
|
But that balloon is red and yellow.
|
|
2025-05-23 03:01:47
|
But I see colorful specs getting added to it
|
|
|
|
jonnyawsom3
|
|
Demiurge
But that balloon is red and yellow.
|
|
2025-05-23 03:15:05
|
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 03:15:26
|
https://unicolour.wacton.xyz/colour-picker/
|
|
|
|
Demiurge
|
2025-05-23 03:24:42
|
Still, those are ringing artifacts.
|
|
|
|
jonnyawsom3
|
2025-05-23 03:28:36
|
I don't see any ringing, just DCT/mosquito noise in the chroma
|
|
2025-05-23 04:46:45
|
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
|
|