|
jonnyawsom3
|
2025-04-21 08:57:10
|
During our work for <#1358733203619319858>, we found that jxl-oxide can be up to 2x faster than libjxl in certain scenarios, showing there's still lots of room for improvement
|
|
|
Demiurge
Group by group sequential. Nothing progressive about it.
|
|
2025-04-21 08:57:48
|
Thinking about it, is centre-first group ordering still sequential?
|
|
|
Demiurge
|
2025-04-21 08:58:07
|
Technically yes-no-yes
|
|
|
|
jonnyawsom3
|
|
Mine18
Huh, didnt know that jxl is progressive at all times (thought you had to specify when encoding), and i didnt know that lossless trancodes to jpeg were always progressive
|
|
2025-04-21 09:01:40
|
I kinda already said but I'll clarify it further.
Lossy VarDCT is always progressive, but can be made more progressive with -p to the point of 0.1% giving an image.
Lossless loads per group by default (128 to 1024 blocks) but can have a custom order like centre-out, with -p replicating the behaviour in lossy
|
|
|
|
Demiurge
|
2025-04-21 09:02:40
|
Center-out is technically sequential but also kinda in its own special cool category
|
|
2025-04-21 09:03:05
|
But jxl can be BOTH sequential and center-out, or any combination of the two
|
|
2025-04-21 09:03:19
|
And it doesn't have to be in the center either
|
|
|
|
jonnyawsom3
|
2025-04-21 09:06:16
|
Group ordering can be arbitrary, though not exposed in the API yet, and level of progressiveness for lossless can also be customised, changing how many passes there are (needs testing)
|
|
|
Mine18
|
|
I kinda already said but I'll clarify it further.
Lossy VarDCT is always progressive, but can be made more progressive with -p to the point of 0.1% giving an image.
Lossless loads per group by default (128 to 1024 blocks) but can have a custom order like centre-out, with -p replicating the behaviour in lossy
|
|
2025-04-21 09:06:35
|
very neat
|
|
|
spider-mario
|
|
screwball
it seems impossible to me
i dont see any blocky artifacting or anything
|
|
2025-04-21 12:14:27
|
it looks ever so slightly blurrier to me (especially noticeable in the top right and when flipping between the two), but not bad indeed
|
|
|
CrushedAsian255
Will there ever be a Rust encoder?
|
|
2025-04-21 12:15:00
|
not a priority for us at the moment (completing the decoder is more important), but of course thereโs always the possibility that someone else would make one
|
|
2025-04-21 12:15:38
|
you could theoretically be the answer to your question!
|
|
|
CrushedAsian255
|
|
spider-mario
you could theoretically be the answer to your question!
|
|
2025-04-21 12:16:11
|
... if I learned Rust (and how JXL's coding tools work)
|
|
|
|
spider-mario
|
2025-04-21 12:16:42
|
is that out of the question?
|
|
|
|
CrushedAsian255
|
|
spider-mario
is that out of the question?
|
|
2025-04-21 12:18:25
|
am I allowed to ~~steal~~ borrow code from the jxl-rs project?
|
|
|
|
spider-mario
|
2025-04-21 12:28:44
|
itโs BSD3 ;)
|
|
|
screwball
|
|
spider-mario
it looks ever so slightly blurrier to me (especially noticeable in the top right and when flipping between the two), but not bad indeed
|
|
2025-04-21 05:34:44
|
i can see that but its definitely not noticable when zoomed out at the full 10k image
|
|
|
|
Demiurge
|
|
CrushedAsian255
am I allowed to ~~steal~~ borrow code from the jxl-rs project?
|
|
2025-04-21 07:42:31
|
https://github.com/libjxl/jxl-rs/blob/main/LICENSE
|
|
|
gb82
|
|
Demiurge
Center-out is technically sequential but also kinda in its own special cool category
|
|
2025-04-21 07:51:55
|
Hmm, center out โฆ reminds me of middle-out
|
|
|
|
Demiurge
|
2025-04-21 09:44:43
|
Dick jerk algorithm
|
|
2025-04-21 09:58:29
|
https://youtu.be/P-hUV9yhqgY
|
|
|
|
jonnyawsom3
|
|
_wb_
If it's mostly yellows getting desaturated in non-smooth regions, it suggests we need to allocate relatively more bits to the AC of the B component.
|
|
2025-04-22 09:52:55
|
Hopefully I'm wrong, but I don't think that will help. XYB itself seems to desaturate yellow
|
|
2025-04-22 09:53:02
|
sRGB
|
|
2025-04-22 09:53:04
|
XYB
|
|
2025-04-22 09:53:39
|
That's a ramp from 0,0,0 to 255,255,0
|
|
2025-04-22 09:56:57
|
Only the very end of the scale is the saturation you'd expect, so as soon as the colors are quantized, it starts to desaturate
|
|
2025-04-22 10:02:03
|
Unless this is more color management shenanigans throwing me off... Which also wouldn't surprise me
|
|
2025-04-22 10:21:07
|
Hard to tell... Using this site seems better, but I'm out of gamut constantly so it's hard to judge https://unicolour.wacton.xyz/colour-picker/
|
|
|
_wb_
|
2025-04-22 11:07:54
|
how did you do the RGB -> XYB -> RGB?
|
|
2025-04-22 11:10:44
|
doing a very low distance lossy (either with vardct, or with modular with or without squeeze) encode and decode does include an XYB roundtrip, and if I do that, I do get some off-by-ones and off-by-twos in the B channel but nothing nearly as big as the example you show
|
|
|
|
jonnyawsom3
|
2025-04-22 11:13:49
|
I had plucked it from this site, but now I see it's from 2021 and likely very outdated, sorry about that https://raphlinus.github.io/color/2021/01/18/oklab-critique.html
|
|
|
|
_wb_
|
2025-04-22 11:36:04
|
oh but that is doing the gradient in XYB space, which is expected to look different than doing the gradient in other color spaces. That's a way to see how perceptually uniform the space is: if it's perceptually uniform, colors interpolated linearly between two other colors should be "in between" the two colors and in equally spaced steps. You can see that sRGB for example is not very perceptually uniform in this example, since when going from red to cyan you get dark grayish colors in between that perceptually don't "belong" there.
|
|
|
|
jonnyawsom3
|
2025-04-22 11:56:23
|
Ahh right, makes sense
|
|
|
Lumen
|
2025-04-22 01:51:06
|
now let's ask the right questions
which XYB is it ahah
since it is different in ssimu2 or butteraugli for example
|
|
|
|
_wb_
|
2025-04-22 01:54:07
|
according to the description on the site, they use the cube root one, so the one in JPEG XL and ssimu2
|
|
|
|
Lumen
|
2025-04-22 01:54:15
|
I see
|
|
|
|
Demiurge
|
|
_wb_
If it's mostly yellows getting desaturated in non-smooth regions, it suggests we need to allocate relatively more bits to the AC of the B component.
|
|
2025-04-22 02:25:47
|
It's definitely in smooth regions too. It's in almost every single picture at d=1 and up. It's easy to see across a wide variety of images. Not just desaturation but also weird chroma ringing artifacts in very colorful images too, which is a completely separate issue that also affects the quality of colors across a wide range of images encoded with libjxl
|
|
2025-04-22 02:27:46
|
Since it affects the majority of images, literally more than half, and is often noticeable even when sitting a good distance away from the screen, I'm kinda surprised how long such a bug like that has survived for a long time
|
|
|
|
_wb_
|
|
A homosapien
I made an issue with a photographic example here: https://github.com/libjxl/libjxl/issues/3616
|
|
2025-04-22 02:40:25
|
Something weird is up with that original image. The original version I have lying around is less saturated.
|
|
2025-04-22 02:41:27
|
this is the version of that image that I know
|
|
2025-04-22 02:41:59
|
this is the version that is in the github issue
|
|
|
|
Demiurge
|
2025-04-22 02:44:30
|
I notice the desaturation issue in more than half of the lossy images I encode locally on my own PC using cjxl and cjpegli.
|
|
2025-04-22 02:44:44
|
It's not specific to a single comparison or image or website
|
|
|
|
_wb_
|
2025-04-22 02:44:58
|
these are both PNG files that are just sRGB images, this has nothing to do with jxl
|
|
|
|
Demiurge
|
2025-04-22 02:45:08
|
It's consistent across practically all images I encode locally myself
|
|
|
_wb_
these are both PNG files that are just sRGB images, this has nothing to do with jxl
|
|
2025-04-22 02:48:53
|
I know it's strange that there's an alternate version of the image with increased saturation. I know it has nothing to do with the issue in libjxl. But there is a real issue with libjxl, and it's noticeable across almost every image I try and usually noticeable from a distance too, depending on the image it's very noticeable even in side by side viewing
|
|
2025-04-22 02:51:05
|
Incremental fixes of bugs that have the biggest impact on image fidelity can easily add up and quickly close the gap between libaom and libjxl.
|
|
|
|
jonnyawsom3
|
|
Demiurge
It's definitely in smooth regions too. It's in almost every single picture at d=1 and up. It's easy to see across a wide variety of images. Not just desaturation but also weird chroma ringing artifacts in very colorful images too, which is a completely separate issue that also affects the quality of colors across a wide range of images encoded with libjxl
|
|
2025-04-22 03:32:27
|
At first I thought it affected smooth areas too, but then I double checked and I think it is the AC of the B channel. You can see yellow chroma bleed around the line on the turquoise with blue/grey bleeding into the yellow
|
|
2025-04-22 03:34:22
|
The AQ isn't taking into account that it's a rather narrow range of B required to hit saturated yellows
|
|
|
|
Demiurge
|
2025-04-22 03:40:44
|
But I see it desaturating the green dress in "Japan Expo" photo too
|
|
2025-04-22 03:41:00
|
Maybe there's some blue there too though...
|
|
2025-04-22 03:41:04
|
Hmm
|
|
2025-04-22 03:41:09
|
Yeah it might be
|
|
|
|
jonnyawsom3
|
2025-04-22 03:41:30
|
Original, v0.8 and main. Seems to avoid the yellow bled in the turquoise but desaturates the yellow even more
|
|
|
|
Demiurge
|
2025-04-22 03:41:38
|
B in XYB is kind of a blue-yellow axis
|
|
|
|
jonnyawsom3
|
|
Hard to tell... Using this site seems better, but I'm out of gamut constantly so it's hard to judge https://unicolour.wacton.xyz/colour-picker/
|
|
2025-04-22 03:43:08
|
That site shows the hue of each channel live, so you can see the 'yellow' target move as you adjust Y and B
|
|
|
juliobbv
|
|
_wb_
this is the version of that image that I know
|
|
2025-04-22 04:21:38
|
there are two versions of the daala subset1 floating around (where this image came from)
|
|
|
A homosapien
|
|
_wb_
Something weird is up with that original image. The original version I have lying around is less saturated.
|
|
2025-04-22 06:22:54
|
Actually, the version you have is not truly the original. I hunted down the source image, which has an Adobe RGB color profile. The daala image set that uses this image "converts" to sRGB by stripping the ICC profile, which is horrible! So I did my due diligence and properly converted it to sRGB (relative colormetric) then downscaled it in linear light (Fant 25%) to mimic the daala image set.
By the way, I did my due diligence and I tested it with the ICC profile stripped, identical to the daala set. The desaturation still happens around the yellow leaves. Same thing if the Adobe RGB profile is preserved.
|
|
2025-04-22 06:24:57
|
https://en.m.wikipedia.org/wiki/File:Abandoned_Packard_Automobile_Factory_Detroit_200.jpg
|
|
2025-04-22 06:25:02
|
It's the 2010 version
|
|
|
|
_wb_
|
2025-04-22 06:31:15
|
Ah, good find about the original color space! I was just confused about the difference in saturation but of course then your version is way more correct
|
|
2025-04-22 06:35:17
|
I will take a look tomorrow to see if there is a way to reduce this desaturation effect, I think it is related to the quantization of the HF of X where there's too much rounding towards zero happening
|
|
|
|
jonnyawsom3
|
2025-04-22 06:45:10
|
It could be worth inspecting the individual channels, comparing high quality to low quality if possible
|
|
|
username
|
|
A homosapien
It's the 2010 version
|
|
2025-04-22 06:55:53
|
what's the deal with the 2023 version? the comment for it says "ShiftN correction" and it's perspective is cropped and changed along with being wayy larger in file size
|
|
2025-04-22 06:58:14
|
the larger file size I assume is the image getting converted from JPEG to raw pixels and then to JPEG again
|
|
2025-04-22 07:00:13
|
I wonder if it's some kinda perspective correction based on the camera metadata embedded in it
|
|
|
|
A homosapien
|
2025-04-22 07:15:00
|
That seems to be the case, correcting for perspective and lens distortion is something I did with my RAWs
|
|
|
Paultimate
|
2025-04-23 06:31:45
|
All hail jxl
|
|
|
|
Demiurge
|
2025-04-23 06:34:53
|
Resistance is futile
|
|
|
Fab
|
2025-04-25 01:12:02
|
I ported some psychovisual improvements from hydrium and av2 to avif and jpeg
|
|
2025-04-25 01:13:14
|
|
|
2025-04-25 01:13:35
|
Should be posted in benchmark but this is relevsnt
|
|
|
Oleksii Matiash
|
|
Fab
I ported some psychovisual improvements from hydrium and av2 to avif and jpeg
|
|
2025-04-25 01:24:42
|
This is jxl server, not avif or jpeg
|
|
|
|
jonnyawsom3
|
2025-04-25 01:38:50
|
Ported from hydrium? That's the minimal memory VarDCT encoder, which I doubt has much in terms of psychovisual tuning
|
|
|
|
Fab
|
2025-04-25 07:28:32
|
|
|
2025-04-25 07:29:01
|
I ported another av2 feature subpel Pelรน
|
|
2025-04-25 07:29:34
|
See the red saturation how it increases
|
|
2025-04-25 07:30:04
|
Jon Sneyers had already the right measurements in JPEG xl and pareto front
|
|
2025-04-25 07:30:33
|
In two seconds i configured them for AVIF
|
|
|
Traneptora
|
|
Ported from hydrium? That's the minimal memory VarDCT encoder, which I doubt has much in terms of psychovisual tuning
|
|
2025-04-25 07:53:36
|
Almost none
|
|
2025-04-25 07:54:14
|
I have some cheap tricks like zeroing out HF coeffs equal to 1
|
|
2025-04-25 07:54:54
|
or locking hf_mult to 5
|
|
2025-04-25 07:55:07
|
(my revise that one)
|
|
2025-04-25 07:55:46
|
my current goal is to speed it up by trying to remove a lot of tiny mallocs
|
|
2025-04-25 07:56:06
|
use the stack instead
|
|
|
|
CrushedAsian255
|
2025-04-26 06:12:23
|
Did he mean the other way round?
|
|
2025-04-26 06:12:40
|
Maybe he ported stuff from AVIF and JPEG to hydrium and av2
|
|
|
|
Fab
|
2025-04-26 10:04:56
|
No is impossible
|
|
2025-04-26 10:06:53
|
Only jon knows what I cooked but is invasion of Orzivecchi privacy for two person I know
|
|
2025-04-26 10:16:16
|
https://www.pnas.org/doi/full/10.1073/pnas.1010076108
|
|
2025-04-26 10:16:36
|
I'm having a discussion with my cosin
|
|
2025-04-26 10:16:40
|
Cause of aomedia
|
|
2025-04-26 10:16:59
|
And i want to do what i want on the websites
|
|
2025-04-26 10:17:04
|
Gemini etc
|
|
2025-04-26 10:17:26
|
I have done this for 3 yesss been in the music induatry for 21 years
|
|
2025-04-26 10:18:10
|
And now a catholic minor is telling me to SHUT UP and my mind don't accept the refuse
|
|
|
|
jonnyawsom3
|
|
MSLP
|
2025-04-26 01:06:43
|
Is this the original fab spreading confusion again, or someone else roleplaying spreading fab confusion?
|
|
|
|
Fab
|
2025-04-26 02:22:21
|
Sorry
|
|
2025-04-26 02:22:58
|
But i don't want to get ass with 67,8% of disabled who got 23,9% of people minors cut off
|
|
2025-04-26 02:23:08
|
I'm innocent
|
|
2025-04-26 02:23:34
|
I don't care i want to stay in Discord cause i can act
|
|
2025-04-26 02:40:26
|
I blocked all three contacts for rudeness
|
|
2025-04-26 02:40:50
|
The Activity i do on internet Is seeuoys
|
|
|
|
jonnyawsom3
|
2025-04-26 02:50:08
|
*Huh*
|
|
|
Quackdoc
|
|
MSLP
Is this the original fab spreading confusion again, or someone else roleplaying spreading fab confusion?
|
|
2025-04-26 03:16:16
|
OG, too hard to emulate lmao
|
|
|
|
Oleksii Matiash
|
|
MSLP
Is this the original fab spreading confusion again, or someone else roleplaying spreading fab confusion?
|
|
2025-04-26 03:28:39
|
True original, or well trained AI
|
|
|
|
jonnyawsom3
|
2025-04-26 04:00:23
|
Maybe the original is AI
|
|
|
|
Fab
|
2025-04-26 04:26:56
|
|
|
2025-04-26 04:27:10
|
This video maie me scary
|
|
2025-04-26 04:49:23
|
I found Stress et รฉpuisement professionnel des enseignants tunisiensStress and burnout among Tunisian teachers
|
|
2025-04-26 04:49:32
|
I'm angry
|
|
2025-04-26 04:49:44
|
They discriminate me
|
|
2025-04-26 04:49:51
|
I'm superior
|
|
2025-04-26 08:17:08
|
AI spreads a lot of misinformation I don't trust things entitely lookly with AI
|
|
2025-04-26 08:18:43
|
But Jenny Di Guardiano (Catania) has been used by me and Mediaset one year ago in September to training of Gemini
|
|
2025-04-26 08:19:29
|
It learned to act badly and not simply an leader leaflet of the week
|
|
2025-04-26 08:21:38
|
It learned to have that confidence Thatcher rtpicallu of my cousin and also they rrained Ressit
|
|
2025-04-26 08:22:04
|
Now they are at 2.5 flash (thinking)
|
|
2025-04-26 08:22:35
|
But Google has still a lot off to do
|
|
|
|
Paultimate
|
2025-04-26 10:13:49
|
This is what happens when you try and compress better than jxl using only the human mind in 2025.
|
|
|
|
Demiurge
|
|
MSLP
Is this the original fab spreading confusion again, or someone else roleplaying spreading fab confusion?
|
|
2025-04-27 02:06:39
|
It's not roleplaying. I don't think anyone else can replicate this.
|
|
2025-04-27 02:08:41
|
Only the real fab can be this confusing and confabulous.
|
|
|
|
Fab
|
|
Paultimate
This is what happens when you try and compress better than jxl using only the human mind in 2025.
|
|
2025-04-27 04:59:23
|
https://www.instagram.com/p/DIv_JttT84A/?igsh=azhzazl6bTE2ZzEw
|
|
2025-04-27 04:59:36
|
I'm a slave to AOMEDIA
|
|
2025-04-27 04:59:50
|
Or at least ive done that for two years
|
|
|
|
CrushedAsian255
|
|
Huh
|
|
2025-04-27 05:08:31
|
Here's my best interpretation/translation of their messages with cultural context and logical connections:
**Corrected Message:**
*"I'm having a discussion with my cousin about AOMedia (Alliance for Open Media) issues. I want to use websites and services like Gemini (the privacy-focused protocol) freely with my preferred tools. I've worked in tech for 3 years and have 21 years of experience in the music industry. Now someone young from the Catholic community (or possibly a moderator using 'Catholic' metaphorically to mean strict) is telling me to shut up about this, and I can't accept being dismissed like this."*
**Key Clarifications:**
1. **"Cosin"** โ Likely "cousin" (Italian: *cugino*)
2. **"aomedia"** โ AOMedia, the consortium behind AV1/JPEG XL
3. **"Gemini"** โ Likely Gemini protocol, not the AI
4. **"Catholic minor"** โ Either:
- Literal: A young Catholic community member
- Metaphorical: A strict moderator (using "Catholic" as Italian slang for rigid authority)
5. **"Mind don't accept the refuse"** โ Rejecting being silenced (*rifiuto* = refusal/rejection in Italian)
-# DeepSeek-R1
|
|
|
|
Fab
|
2025-04-27 06:31:37
|
Forget about temptation island and Mediaset and September
|
|
2025-04-27 06:31:56
|
But anyway Ive been defended
|
|
|
CrushedAsian255
Here's my best interpretation/translation of their messages with cultural context and logical connections:
**Corrected Message:**
*"I'm having a discussion with my cousin about AOMedia (Alliance for Open Media) issues. I want to use websites and services like Gemini (the privacy-focused protocol) freely with my preferred tools. I've worked in tech for 3 years and have 21 years of experience in the music industry. Now someone young from the Catholic community (or possibly a moderator using 'Catholic' metaphorically to mean strict) is telling me to shut up about this, and I can't accept being dismissed like this."*
**Key Clarifications:**
1. **"Cosin"** โ Likely "cousin" (Italian: *cugino*)
2. **"aomedia"** โ AOMedia, the consortium behind AV1/JPEG XL
3. **"Gemini"** โ Likely Gemini protocol, not the AI
4. **"Catholic minor"** โ Either:
- Literal: A young Catholic community member
- Metaphorical: A strict moderator (using "Catholic" as Italian slang for rigid authority)
5. **"Mind don't accept the refuse"** โ Rejecting being silenced (*rifiuto* = refusal/rejection in Italian)
-# DeepSeek-R1
|
|
2025-04-27 06:33:03
|
How to do this with gemini flash 2.0 thinking or Deep seek on abdroid 15 and Windows can you share a tutorial on <#806898911091753051>
|
|
|
|
Demiurge
|
2025-04-27 07:16:25
|
No amount of AI processing will make fab's confab comprehensible
|
|
2025-04-28 04:32:55
|
XYB uses defined, constant color primaries? But it can represent out-of-gamut colors with values beyond 0.0-1.0?
|
|
2025-04-28 04:33:26
|
What are the color primaries?
|
|
|
Tirr
|
2025-04-28 05:17:40
|
XYB doesn't have primaries because it's not an RGB color space
|
|
2025-04-28 05:18:32
|
iirc it's derived from LMS
|
|
|
|
_wb_
|
2025-04-28 05:51:57
|
XYB has no nominal range, the range just gets larger when gamut or dynamic range gets larger.
|
|
|
|
Demiurge
|
2025-04-28 06:12:17
|
Really? I thought the nominal range was the whole basis for the perceptual model.
|
|
|
|
_wb_
|
2025-04-28 08:56:41
|
it just uses floats, Y is more or less 0..1 but X is signed and close to zero, while B is more or less 0..1 but in practice Y is always subtracted from it so it also becomes signed.
|
|
2025-04-28 08:57:30
|
https://github.com/cloudinary/ssimulacra2/blob/main/src/ssimulacra2.cc#L197 this is what I do in ssimulacra2 to turn XYB into something more or less 0..1
|
|
2025-04-28 08:58:36
|
jpegli when using XYB does something similar with an XYB icc profile that makes the range more or less 0..1
|
|
|
|
Demiurge
|
2025-04-28 09:59:58
|
Well, I just wonder, if the perceptual model is able to generalize well to different primary colors...
|
|
2025-04-28 10:00:42
|
I would imagine probably so.
|
|
2025-04-28 10:01:08
|
So when you create an XYB JPEG with jpegli, the embedded color profile has different primaries depending on the source image?
|
|
|
|
CrushedAsian255
|
|
Demiurge
So when you create an XYB JPEG with jpegli, the embedded color profile has different primaries depending on the source image?
|
|
2025-04-28 10:30:03
|
So each image has primaries set to encompass only the colours used in that specific image?
|
|
|
|
spider-mario
|
2025-04-28 10:56:19
|
as far as Iโm aware, we havenโt done that for jpegli (although I had plans to maybe look into that)
|
|
2025-04-28 10:56:29
|
iirc, we just use the XYB range that corresponds to sRGB
|
|
|
|
Demiurge
|
2025-04-28 10:59:53
|
what happens if I use `cjpegli --xyb` to encode an image with an attached color profile with color primaries beyond the sRGB primaries?
|
|
2025-04-28 11:01:06
|
Like Adobe RGB. Can I encode an Adobe RGB source image with cjpegli --xyb and the attached XYB profile will have the primaries for Adobe RGB?
|
|
|
|
Fab
|
2025-04-28 11:01:11
|
Vp9 encoder based on subliminal Jon Sneyers
|
|
|
|
Demiurge
|
2025-04-28 11:01:32
|
subliminal Jon Sneyers ๐
|
|
|
|
CrushedAsian255
|
2025-04-28 11:06:43
|
`1153 kbps`
|
|
2025-04-28 11:07:02
|
also didn't know you could vp9 in mp4 container
|
|
|
|
Fab
|
|
CrushedAsian255
also didn't know you could vp9 in mp4 container
|
|
2025-04-28 11:07:18
|
Discord re encodes
|
|
2025-04-28 11:11:43
|
|
|
2025-04-28 11:12:03
|
Magically I started to understand paper
|
|
2025-04-28 11:12:20
|
Svt av1 psy 3.0.2 in fb vp9 and av1
|
|
2025-04-28 12:07:36
|
Much better now
|
|
2025-04-28 12:07:57
|
Sorry that isn't related to image compression in particolar
|
|
2025-04-28 12:08:13
|
Is video compression in meta
|
|
2025-04-28 12:20:03
|
I think I have succeded and finally jg a bit more less honest in off topic
|
|
|
|
CrushedAsian255
|
|
Fab
Sorry that isn't related to image compression in particolar
|
|
2025-04-28 01:04:17
|
This should probably go in <#805176455658733570>
|
|
|
|
_wb_
|
|
spider-mario
iirc, we just use the XYB range that corresponds to sRGB
|
|
2025-04-28 01:13:53
|
You don't need a huge amount of extra room in X and B to cover the P3 gamut, which probably suffices in practice since few displays can do wider gamut than that...
|
|
|
Demiurge
Well, I just wonder, if the perceptual model is able to generalize well to different primary colors...
|
|
2025-04-28 01:15:39
|
XYB is already generalized to any primaries, since it is an absolute space that covers all visible colors (including gamuts as wide as Rec2020 and beyond, and dynamic range as large as PQ and beyond)
|
|
2025-04-28 02:39:59
|
here are slices of X,B for four values of Y, showing colors within the Rec2020 gamut and with a white border indicating colors within the sRGB gamut
|
|
2025-04-28 03:02:00
|
Here is a better visualization, zooming out a bit so all of Rec2020 fits
|
|
2025-04-28 04:23:46
|
tweaked it further, I might turn it into a figure for the big jxl paper now
|
|
2025-04-28 04:24:07
|
what is shown is Rec2020, yellow is P3, red is sRGB
|
|
2025-04-28 07:57:43
|
final version I'm gonna add to the paper
|
|
|
|
Demiurge
|
2025-04-29 12:35:22
|
I'm kind of confused about what happens to an input image with an attached color profile after cjpegli turns it into an xyb jpeg and creates an xyb profile... Is it always the same xyb profile or is it based off the input profile?
|
|
|
|
Traneptora
|
|
Demiurge
I'm kind of confused about what happens to an input image with an attached color profile after cjpegli turns it into an xyb jpeg and creates an xyb profile... Is it always the same xyb profile or is it based off the input profile?
|
|
2025-04-29 01:29:38
|
cjxl and cjpegli use a CMS to convert the image into XYB
|
|
2025-04-29 01:30:17
|
cjxl encodes the original profile as informative. cjpegli just attaches an XYB profile.
|
|
2025-04-29 01:31:06
|
Since the pixels described by xyb jpeg are described by an XYB profile, the input doesn't really matter
|
|
|
|
Demiurge
|
2025-04-29 03:23:28
|
So cjpegli always attaches the same XYB profile regardless of the input profile. And the XYB profile does not have color primaries, or a nominal range...
|
|
2025-04-29 03:24:15
|
I thought all ICC profile has to define primaries
|
|
|
|
_wb_
|
2025-04-29 05:47:25
|
IIRC, ICC profiles define a mapping between your color space and either CIE XYZ or CIE Lab. Defining RGB primaries is one way to do that.
The ICC version of XYB does have a nominal range, all components are scaled so they fit in a 0..1 range.
|
|
|
|
CrushedAsian255
|
|
_wb_
IIRC, ICC profiles define a mapping between your color space and either CIE XYZ or CIE Lab. Defining RGB primaries is one way to do that.
The ICC version of XYB does have a nominal range, all components are scaled so they fit in a 0..1 range.
|
|
2025-04-29 07:34:46
|
What about JXL XYB?
|
|
2025-04-29 07:34:55
|
Does it not care about primaries?
|
|
|
|
_wb_
|
2025-04-29 08:40:41
|
The jxl encoder takes RGB input and cares about primaries when converting it to XYB. But XYB is always the same space, you just end up using different subvolumes of it depending on what the primaries of the input image are (and the actual pixel values)
|
|
|
|
Demiurge
|
2025-04-29 10:20:04
|
I think he means how does the xyb icc define a mapping to ciexyz or cielab
|
|
|
|
_wb_
|
2025-04-29 10:31:50
|
It uses an `mAB` tag
|
|
2025-04-29 10:35:05
|
this one
|
|
2025-04-29 10:37:24
|
Here's the code that produces that key part of the xyb icc profile: https://github.com/google/jpegli/blob/main/lib/cms/jxl_cms_internal.h#L599
|
|
2025-04-29 10:39:04
|
it's basically a pretty good approximation of XYB, rescaled so the XYB components fit in the 0..1 range which is needed both for ICC profiles in general and for the way JPEG works (it also assumes that all components are in 0..1 range)
|
|
|
Comexs
|
2025-04-29 01:19:52
|
How can I verify that `cjxl -d 0` on a png is lossless. When I test it on the original jpeg and the output of djxl from a cjxl output the sha256sums are the same but with png isn't the same most likely because of djxl png encoder since djxl output png is bigger than the original png.
what can I do to test it. I have also used (Image Magick) `compare input.png input.jxl -compose src output_compare.png` to compare images with cjxl output and the djxl output too the original png and they came out with no red pixels.
Another question i had is my problem with using compare from Image Magick. When I use it on a jpeg and the cjxl output i see red pixels everywhere but if I try it on jpeg and the djxl output from the cjxl output from before it. I don't see any red pixels and as i said before they share the same sha256sums and when i compare jxl and og jpeg in a image viewer on those red pixel areas I don't see anything different.
|
|
|
RaveSteel
|
2025-04-29 01:32:11
|
Either use ssimulacra2 `ssimulacra2 orig.png distorted.png` or ImageMagick's identify `/usr/bin/identify -format "%m %#\n" IMG1 IMG2`
|
|
|
|
Comexs
|
2025-04-29 01:32:33
|
Thanks I will check them out
|
|
|
|
jonnyawsom3
|
|
Comexs
How can I verify that `cjxl -d 0` on a png is lossless. When I test it on the original jpeg and the output of djxl from a cjxl output the sha256sums are the same but with png isn't the same most likely because of djxl png encoder since djxl output png is bigger than the original png.
what can I do to test it. I have also used (Image Magick) `compare input.png input.jxl -compose src output_compare.png` to compare images with cjxl output and the djxl output too the original png and they came out with no red pixels.
Another question i had is my problem with using compare from Image Magick. When I use it on a jpeg and the cjxl output i see red pixels everywhere but if I try it on jpeg and the djxl output from the cjxl output from before it. I don't see any red pixels and as i said before they share the same sha256sums and when i compare jxl and og jpeg in a image viewer on those red pixel areas I don't see anything different.
|
|
2025-04-29 02:01:15
|
The reason for the difference between the jpeg and the JXL is that the JXL uses higher precision maths to squeeze a bit more quality out of the same data, but using djxl always returns the same jpeg so it can still be lossless too
|
|
|
|
Comexs
|
|
The reason for the difference between the jpeg and the JXL is that the JXL uses higher precision maths to squeeze a bit more quality out of the same data, but using djxl always returns the same jpeg so it can still be lossless too
|
|
2025-04-29 02:04:08
|
I have see it but only on some images. I guess i can't see it on the images on this test.
is the same for using `identify -format "%m %#\n"`?
why is "For lossless sources, -d 1 is the default." why is it -d 1 instead of -d 0?
and thanks for the useful info.
|
|
|
|
jonnyawsom3
|
2025-04-29 02:05:58
|
The logic is if you have a lossless image, it can be made lossy. If the image is already lossy (JPEG, GIF), store it as lossless to avoid further loss
|
|
|
DZgas ะ
|
2025-05-04 12:19:13
|
Is anyone developing an alternative jpeg xl encoder?
|
|
|
Orum
|
2025-05-04 12:29:12
|
IIRC there is a rust-based one in development?
|
|
2025-05-04 12:29:18
|
or maybe that's just a decoder, I don't recall
|
|
2025-05-04 12:30:18
|
ah yeah, decoder only: https://github.com/tirr-c/jxl-oxide
|
|
|
drhead
|
2025-05-04 01:28:57
|
Have any efforts been made towards a CUDA-accelerated encoder/decoder for JXL? I don't think I have quite enough CUDA experience to do it easily, but if someone has a rough idea of what parts of the encoding/decoding process can and cannot be parallelized easily and what parts would require CPU sync I would appreciate knowing that.
|
|
|
|
Orum
|
2025-05-04 01:30:09
|
CUDA ๐คฎ
|
|
|
|
drhead
|
2025-05-04 01:31:54
|
I think that existing pipelines for most CUDA accelerated image decoders do have some CPU operations at the beginning and end (with the exception of their NVJPG hardware decoders), so I wouldn't rule out a useful implementation being possible on that basis.
|
|
|
|
username
|
|
drhead
Have any efforts been made towards a CUDA-accelerated encoder/decoder for JXL? I don't think I have quite enough CUDA experience to do it easily, but if someone has a rough idea of what parts of the encoding/decoding process can and cannot be parallelized easily and what parts would require CPU sync I would appreciate knowing that.
|
|
2025-05-04 01:33:36
|
iirc there are a few parts of JXL that don't translate well or at all to GPU processing I wouldn't know which parts exactly but I remember there being some discussions in the past related to this
|
|
|
|
CrushedAsian255
|
2025-05-04 01:35:39
|
ANS and Modular MA trees aren't great for gpu
|
|
2025-05-04 01:36:08
|
but things like RCT, Squeeze, EPF, Gaborish might be able to
|
|
|
|
drhead
|
2025-05-04 01:38:45
|
I mean this is what nvidia describes their software nvJPEG pipeline as being like. So really it would depend on where those operations are. If it's just at the beginning or end it's practically a non issue, if we're doing it several times in the middle then yeah that'd be extremely bad
|
|
|
CrushedAsian255
ANS and Modular MA trees aren't great for gpu
|
|
2025-05-04 01:52:47
|
https://github.com/facebookresearch/dietgpu well it looks like Facebook managed to get ANS working, so that may not be a problem
|
|
|
|
Orum
|
|
drhead
I mean this is what nvidia describes their software nvJPEG pipeline as being like. So really it would depend on where those operations are. If it's just at the beginning or end it's practically a non issue, if we're doing it several times in the middle then yeah that'd be extremely bad
|
|
2025-05-04 01:58:45
|
imagine considering a "BMP" to be decoded <:KekDog:805390049033191445>
|
|
|
|
drhead
|
|
Orum
imagine considering a "BMP" to be decoded <:KekDog:805390049033191445>
|
|
2025-05-04 01:59:41
|
they're probably just referring to a uint8 image tensor since that's what you'd have in practice
|
|
|
|
Orum
|
2025-05-04 02:00:04
|
in modern times, probably, but it's still a nightmare of a format
|
|
|
|
CrushedAsian255
|
2025-05-04 02:00:20
|
`.ppm` supremacy
|
|
|
|
Quackdoc
|
2025-05-04 02:01:58
|
pfm double supremacy
|
|
|
Jarek Duda
|
|
drhead
https://github.com/facebookresearch/dietgpu well it looks like Facebook managed to get ANS working, so that may not be a problem
|
|
2025-05-04 02:16:21
|
also https://developer.nvidia.com/nvcomp - in theory both with dietgpu can exceed 100GB/s for rANS on GPU, however, it requires lots of independent data streams - like for different contexts ...
|
|
|
|
CrushedAsian255
|
2025-05-04 02:35:32
|
so its not decompressing 1 ans stream its allowing many ans streams to be decoded in parallel?
|
|
|
|
drhead
|
|
CrushedAsian255
so its not decompressing 1 ans stream its allowing many ans streams to be decoded in parallel?
|
|
2025-05-04 02:44:32
|
> // FIXME: We have no idea how large the decompression job is, as the
> // relevant information is on the device.
> // Just launch a grid that is sufficiently large enough to saturate the GPU;
> // blocks will exit if there isn't enough work, or will loop if there is
> // more work. We aim for a grid >4x larger than what the device can sustain,
> // to help cover up tail effects and unequal provisioning across the batch
Yeah. And as evidenced by this comment it isn't pretty, but it does work.
|
|
|
|
Jarek Duda
|
2025-05-04 03:54:34
|
the fastest ~2GB/s/CPU core SIMD rANS decoder https://github.com/jkbonfield/rans_static needs 32 independent data streams: 8 in vectorization times 4 in interleaving ... in GPU it is probably in hundreds or more, but I don't know the details.
|
|
|
|
CrushedAsian255
|
2025-05-04 04:25:17
|
One issue is I'm pretty sure the JPEG XL entropy coding multiplexes all the rANS streams together so you cannot easily "split" the bitstream into individual rANS contexts
|
|
|
|
Jarek Duda
|
2025-05-04 05:17:15
|
sure I understand, but maybe it could be overcomed e.g. like in above nvJPEG decoder diagram: start with blind entropy decoding into buffers of all e.g. separating contexts (needs some signaling of lengths), then further stages take symbols from such corresponding buffers of decoded?
|
|
|
|
Tirr
|
2025-05-04 05:35:03
|
it would be okay with plain JPEG but JXL changes context based on adjacent image samples within single ANS stream, so it can't be separated easily
|
|
|
|
Jarek Duda
|
2025-05-04 05:58:24
|
if same contexts still correspond to same distributions, you can blindly use such buffers of decoded symbols
|
|
|
|
Tirr
|
2025-05-04 06:04:10
|
in my understanding, within single stream, symbols decoded in order of distribution, say A-A-B, are different from those decoded in A-B-A order
|
|
|
|
Jarek Duda
|
2025-05-04 06:06:25
|
definitely, it needs fixing decoding order
|
|
|
|
CrushedAsian255
|
2025-05-04 06:06:42
|
im pretty sure the way JXL works is an entire set of clustered distributions has to be read sequentially
|
|
|
|
Tirr
|
2025-05-04 06:08:58
|
yeah, JXL can change to different distribution within a stream in data dependent way
|
|
|
|
Jarek Duda
|
2025-05-04 06:09:01
|
if these distributions are finally fixed for the image, still their symbols can be separately entropy decoded, and then used from buffer (maintaining order)
|
|
2025-05-04 06:10:59
|
if I properly understand, this MANIAC tree chooses context, then for each context histograms are calculated - if they are fixed, can be all initially entropy decoded
|
|
|
|
Tirr
|
2025-05-04 06:16:45
|
ah maybe I got what you mean, but I'd say it's no different than decoding image normally, because it's final decoded image sample that decides next distribution, so we still need to decode actual image
|
|
2025-05-04 06:16:56
|
or maybe I'm still not getting it
|
|
|
|
jonnyawsom3
|
|
drhead
Have any efforts been made towards a CUDA-accelerated encoder/decoder for JXL? I don't think I have quite enough CUDA experience to do it easily, but if someone has a rough idea of what parts of the encoding/decoding process can and cannot be parallelized easily and what parts would require CPU sync I would appreciate knowing that.
|
|
2025-05-04 06:17:30
|
Maybe not entirely related, but I did stumble across this a few months ago. AMD made hardware acceleration components for JPEG XL encoding
https://docs.amd.com/r/en-US/Vitis_Libraries/codec/guide_L2/kernels/jxlEnc.html_0
|
|
2025-05-04 06:18:49
|
|
|
|
|
Jarek Duda
|
|
Tirr
ah maybe I got what you mean, but I'd say it's no different than decoding image normally, because it's final decoded image sample that decides next distribution, so we still need to decode actual image
|
|
2025-05-04 06:19:00
|
so do probability distributions for given context from the tree vary through the decoding?
|
|
|
|
_wb_
|
2025-05-04 06:20:45
|
No
|
|
2025-05-04 06:21:04
|
And after clustering the number of distributions is spec limited to 255
|
|
2025-05-04 06:21:44
|
But the ANS decode is not usually the bottleneck anyway, figuring out the right context is
|
|
|
|
Jarek Duda
|
2025-05-04 06:21:47
|
so you can fix them, write in the beginning of file, then fast entropy decode all the symbols into buffers - to be used in fixed order
|
|
|
_wb_
But the ANS decode is not usually the bottleneck anyway, figuring out the right context is
|
|
2025-05-04 06:22:21
|
yes, I believe so, the decision tree seems the bottleneck
|
|
|
|
_wb_
|
2025-05-04 06:23:49
|
Depending on how complicated it is; simple ones can be translated into branchless lookup tables
|
|
|
|
Tirr
|
2025-05-04 06:24:27
|
or maybe even a single distribution
|
|
|
|
Jarek Duda
|
|
_wb_
Depending on how complicated it is; simple ones can be translated into branchless lookup tables
|
|
2025-05-04 06:26:28
|
it could be speedup by splitting image into regions, each using different shallower trees ...
|
|
2025-05-04 06:29:32
|
e.g. k-means clustering can be used in space of models/trees for that ( https://arxiv.org/pdf/2201.05028 ): assign each fragment to the best model, then build model for each cluster, and repeat a few times ...
|
|
|
|
Traneptora
|
2025-05-04 08:04:58
|
As far as I understand there's only one HF histogram set per frame
|
|
2025-05-04 08:05:16
|
You can't have one per LF Group
|
|
2025-05-04 08:05:36
|
without using separate frames per LF Group
|
|
|
|
DZgas ะ
|
|
|
|
2025-05-04 08:26:21
|
so that's why no one else has written alternative encoders :JXL:
|
|
|
|
jonnyawsom3
|
|
DZgas ะ
so that's why no one else has written alternative encoders :JXL:
|
|
2025-05-04 08:32:58
|
https://github.com/Traneptora/hydrium/
|
|
|
Orum
ah yeah, decoder only: https://github.com/tirr-c/jxl-oxide
|
|
2025-05-04 08:33:38
|
Also this, but also just a decoder https://github.com/libjxl/jxl-rs
|
|
|
|
Orum
|
2025-05-04 08:34:42
|
yeah, sadly only one encoder for now
|
|
|
|
username
|
2025-05-04 08:35:49
|
there is that one lossless zune rust encoder or whatever it's called but afaik it's just a port of some code from libjxl to rust
|
|
|
|
Tirr
|
2025-05-04 08:37:41
|
zune-image encoder is a port of libjxl lossless e1
|
|
|
|
jonnyawsom3
|
|
Orum
yeah, sadly only one encoder for now
|
|
2025-05-04 09:17:32
|
Hydrium is an encoder
|
|
|
|
Orum
|
2025-05-04 09:31:17
|
> At the moment, it is a work-in-progress and it is still in the early stages of development. The API and CLI are unstable and subject to change without notice.
not quite sure it qualifies yet...
|
|
|
|
jonnyawsom3
|
2025-05-04 10:19:00
|
I mean hey, libjxl isn't 1.0 either, you just said encoder ;P
|
|
|
|
Traneptora
|
|
Orum
> At the moment, it is a work-in-progress and it is still in the early stages of development. The API and CLI are unstable and subject to change without notice.
not quite sure it qualifies yet...
|
|
2025-05-04 10:27:56
|
I still got work to do but it definitely works
|
|
2025-05-04 10:28:28
|
Something I'm considering doing is adding the ability to multithread the encoder for API clients
|
|
2025-05-04 10:28:58
|
the library itself won't have any threading support but clients will be able to thread with it safely
|
|
|
|
DZgas ะ
|
2025-05-04 10:50:39
|
<:Thonk:805904896879493180>
|
|
|
|
Traneptora
|
2025-05-04 10:51:17
|
currently working on reducing memory consumption though
|
|
2025-05-04 10:51:23
|
in one-frame mode
|
|
2025-05-04 10:51:40
|
I find that small tiles, while compliant, are somewhat impractical as they take a very long time for libjxl to decode
|
|
2025-05-04 10:53:10
|
my idea is that I can use one HF Preset per LF Group, and cluster them so up to 256 LF groups lets me buffer only one set of symbols at a time
|
|
2025-05-04 10:53:26
|
the problem is that JPEG XL has one entropy stream for the whole frame
|
|
2025-05-04 10:53:55
|
if I can separate out the LF Groups via clustering, then I can remember the histograms but discard the un-encoded symbols after I encode them
|
|
2025-05-04 10:54:07
|
rather than buffer all the symbols to calculate the correct histograms
|
|
2025-05-04 10:54:36
|
this works provided I have fewer than 256 LF Groups
|
|
2025-05-04 10:54:56
|
if I have more, I can just base each cluster on `lf_id & 0xFF`
|
|
|
|
jonnyawsom3
|
2025-05-04 10:56:18
|
I've mentioned it before, but libjxl only decodes a single frame at a time currently, so using small tiles means singlethreaded decoding with the overhead of storing and then merging all the frames/layers
|
|
|
|
Traneptora
|
2025-05-04 10:56:47
|
yea, that's why I'm trying to improve upon the one-frame method
|
|
|
|
_wb_
|
2025-05-04 12:29:56
|
256 LF groups is one gigapixel, usually not a real limitation. I would cluster by `lf_id >> 1` (or larger shifts) for larger images, so neighboring LF groups get the same distribution since their content is probably more similar than groups one gigapixel away from one another...
|
|
|
|
CrushedAsian255
|
|
_wb_
256 LF groups is one gigapixel, usually not a real limitation. I would cluster by `lf_id >> 1` (or larger shifts) for larger images, so neighboring LF groups get the same distribution since their content is probably more similar than groups one gigapixel away from one another...
|
|
2025-05-04 01:59:39
|
is a gigapixel a lot of pixels?
|
|
|
|
_wb_
|
2025-05-04 02:00:09
|
1000 megapixels ๐
|
|
|
|
CrushedAsian255
|
2025-05-04 02:00:18
|
hmm 31623 x 31623
|
|
|
|
_wb_
|
2025-05-04 02:13:37
|
it's not like bigger than that would not be handled, it would just have potentially slightly worse compression
|
|
|
|
Traneptora
|
|
_wb_
256 LF groups is one gigapixel, usually not a real limitation. I would cluster by `lf_id >> 1` (or larger shifts) for larger images, so neighboring LF groups get the same distribution since their content is probably more similar than groups one gigapixel away from one another...
|
|
2025-05-05 01:43:30
|
may be worth just seeing how much im overcounted by using ceildiv, and then dividing by that number
|
|
2025-05-05 01:44:01
|
so <=256 get lfid / 1, <=512 would get lfid / 2
|
|
2025-05-05 01:44:04
|
etc.
|
|
2025-05-05 01:44:31
|
Ive currently implemented this locally but it has a notable drop in density
|
|
2025-05-05 01:45:30
|
compared to my pre-existing cluster map
|
|
2025-05-05 01:45:54
|
I'm wondering how worth it it is to separate out nonzero contextd from the rest
|
|
2025-05-05 01:46:08
|
I may compromise and do those separately
|
|
|
_wb_
256 LF groups is one gigapixel, usually not a real limitation. I would cluster by `lf_id >> 1` (or larger shifts) for larger images, so neighboring LF groups get the same distribution since their content is probably more similar than groups one gigapixel away from one another...
|
|
2025-05-05 03:33:41
|
Isn't it 268 MP
|
|
2025-05-05 03:34:05
|
(2048x8)^2 is 16384^2
|
|
|
|
Tirr
|
2025-05-05 03:36:12
|
one LF group has 4 megapixels (base 2) because it's 2048x2048
|
|
|
|
Traneptora
|
2025-05-05 03:36:19
|
Either way, if I can cluster by LF group, especially by adjacent LF groups, then I can discard the un-encoded symbols
|
|
2025-05-05 03:36:29
|
so 256 MiP <:KEK:1283989161111715913>
|
|
|
|
Tirr
|
2025-05-05 03:37:07
|
uh then 256 LF groups are 1024 MiP (4x256)
|
|
|
|
Traneptora
|
2025-05-05 03:37:19
|
what am I missing then
|
|
2025-05-05 03:38:00
|
(2048x8)^2 = 16384^2 right
|
|
2025-05-05 03:38:12
|
oh
|
|
2025-05-05 03:38:18
|
8^2 is 64
|
|
|
|
Tirr
|
2025-05-05 03:38:18
|
it's 16
|
|
|
|
Traneptora
|
2025-05-05 03:38:25
|
im smart
|
|
2025-05-05 03:38:29
|
16
|
|
2025-05-05 03:38:34
|
im tired
|
|
2025-05-05 03:38:56
|
either way
|
|
2025-05-05 03:39:35
|
atm in order to compute histograms I need to keep the symbols buffered
|
|
2025-05-05 03:40:28
|
since you need all the symbols to compute freqs
|
|
2025-05-05 03:40:54
|
and need freqs to write the symbols as stateflushes
|
|
2025-05-05 03:42:28
|
if I can compute the histograms by cluster, I can buffer much less
|
|
2025-05-05 03:42:44
|
by using HF presets
|
|
|
|
CrushedAsian255
|
|
Traneptora
since you need all the symbols to compute freqs
|
|
2025-05-05 06:23:18
|
If the frequencies are inaccuracies it cause data loss or just inefficiencies?
|
|
|
|
Traneptora
|
2025-05-05 11:31:33
|
imefficient
|
|
|
|
CrushedAsian255
|
|
Traneptora
imefficient
|
|
2025-05-05 11:33:20
|
If you just set each token to equal probabilities is that equivilent to just writing them one-by-one?
|
|
|
|
Traneptora
|
|
CrushedAsian255
If you just set each token to equal probabilities is that equivilent to just writing them one-by-one?
|
|
2025-05-05 12:44:07
|
afaik yes
|
|
|
|
Orum
|
2025-05-08 05:27:09
|
man I wish I could get some sort of dark bias on cjxl
|
|
2025-05-08 05:27:54
|
at -d 1, bright, higher contrast areas of the image are indistinguishable from the original, but dark, lower contrast areas are obviously different
|
|
|
|
A homosapien
|
|
Orum
man I wish I could get some sort of dark bias on cjxl
|
|
2025-05-08 05:38:37
|
`--intensity_target 1000`
|
|
|
|
Orum
|
2025-05-08 05:49:52
|
yeah, that fucks up decode/display though
|
|
2025-05-08 05:50:24
|
I used to use that though, because some image viewers don't take it into account and it works fine there, but that's little consolation
|
|
|
|
_wb_
|
|
Orum
at -d 1, bright, higher contrast areas of the image are indistinguishable from the original, but dark, lower contrast areas are obviously different
|
|
2025-05-08 11:31:33
|
Are you sure it's not some sRGB vs pure-gamma issue? That's something that can end up causing differences in the darks since many viewers misinterpret pure-gamma PNG files as being sRGB.
|
|
|
|
Orum
|
2025-05-08 11:33:09
|
๐ how would I know? I assume `-d 0` would not look lossless if that was the case
|
|
2025-05-08 11:34:08
|
I'm not even sure what you mean by "pure gamma"
|
|
|
|
_wb_
|
2025-05-08 11:34:11
|
that depends on how you view the jxl images
|
|
2025-05-08 11:35:26
|
I mean a PNG file without icc profile and without the sRGB chunk but with just the cHRM and gAMA chunks
|
|
|
|
Orum
|
2025-05-08 11:35:30
|
I'm normally viewing them in nomacs, and while I know that's *far* from perfect when it comes to viewing images, these are pretty vanilla settings (i.e. sRGB, SDR, etc)
|
|
|
|
jonnyawsom3
|
2025-05-08 11:35:48
|
libjxl seems to pass the gamma value to the viewer in a similar way to PNG. Lossless looked fine for me but `-d 0.01` had very different blacks. Likely due to requested colorspace vs keep_original_colorspace
|
|
|
|
Orum
|
|
_wb_
I mean a PNG file without icc profile and without the sRGB chunk but with just the cHRM and gAMA chunks
|
|
2025-05-08 11:36:33
|
Hmm, what would tell me if that was the case? `exiv2`?
|
|
|
|
_wb_
|
2025-05-08 11:38:15
|
yes, or `identify -verbose`, or `exiftool`, or `pngchunks` or whatever you have lying around
|
|
2025-05-08 11:38:24
|
or you can use `jxlinfo` on the jxl
|
|
|
|
Orum
|
2025-05-08 11:39:57
|
alright, so I assume if imagemagick says `Colorspace: sRGB` (on the PNG) that it has the ICC profile chunk?
|
|
2025-05-08 11:41:08
|
`jxlinfo` on a (losslessly) coded image says: `Color space: RGB, D65, sRGB primaries, sRGB transfer function, rendering intent: Relative`
|
|
|
|
jonnyawsom3
|
2025-05-08 11:41:35
|
I've been using PNGTweak, which is a bit outdated (No EXIF chunk support) but also lets me delete incorrect gAMA chunks. Though that doesn't look like it has Gamma
|
|
|
|
_wb_
|
2025-05-08 11:41:57
|
actually imagemagick is not a very good tool to see what's actually in the PNG file
|
|
2025-05-08 11:42:39
|
anyway that looks good, if it has `sRGB transfer function` then probably this gAMA vs sRGB issue is not causing the difference
|
|
2025-05-08 11:44:21
|
if you could share some example image (or a crop of it) that shows the quality issue, it would probably help. The goal is still to make d1 visually lossless for all (areas of) images...
|
|
|
|
Orum
|
2025-05-08 11:44:41
|
yeah, let me crop it down as it's a massive image RN...
|
|
2025-05-08 11:49:17
|
here it is, losslessly compressed
|
|
2025-05-08 11:49:51
|
at d1 (on v0.11.1) I notice a loss of detail on the dark side, while I see no changes on the right side
|
|
2025-05-08 11:51:23
|
I suppose if I really pixel peep I can see differences on the bright side, but they're not nearly as obvious
|
|
|
|
spider-mario
|
|
_wb_
actually imagemagick is not a very good tool to see what's actually in the PNG file
|
|
2025-05-08 11:57:52
|
yeah, Iย think `identify -verbose` still lies about it and makes up an sRGB chunk even when itโs not there
|
|
|
|
_wb_
|
2025-05-08 12:17:37
|
thanks for the example, I agree the smoothing on the left is more noticeable than on the right
|
|
2025-05-08 12:19:48
|
I think we're being too aggressive on the AC of the B component. <@532010383041363969> what's your opinion?
|
|
|
|
drhead
|
2025-05-08 01:40:42
|
So if I were to attempt to make my own decoder/encoder implementation, where would I want to start? At least for what I need it for, it would probably actually be fine to have only a subset of functionality implemented (where the encoder can produce valid JXL files and the decoder can decode those files but not necessarily arbitrary JXL files, I could just have those fall back to libjxl if needed).
The code for libjxl is certainly a lot to take in at once (and it doesn't help that it has been a while since I touched C++ but I'm quite used to learning as I go), but the best hint I can figure out from the documentation is that it might be easier to start by trying to implement the lowest effort level for each to get a bare minimum encoder and a decoder that will decode outputs of that encoder, then build up from there?
|
|
|
|
_wb_
|
2025-05-08 01:58:56
|
are you interested in lossless or lossy? For just lossless, it's not too hard to make a simple encoder...
|
|
|
|
jonnyawsom3
|
2025-05-08 02:00:15
|
VarDCT/regular lossy uses Modular for the DC 1:8 frame, so it may be easiest to only make a minimal modular en/decoder. You can also make it lossy by quantizing residuals after implementing Squeeze, like `cjxl -d 1 -m 1`. Huffman can also be used instead of ANS IIRC, for easier implementation
|
|
|
|
_wb_
|
2025-05-08 02:06:22
|
something like fast_lossless but without all of the SIMD stuff that complicates everything
|
|
2025-05-08 02:11:54
|
does anyone feel like making a simple_lossless? ๐
|
|
|
|
Demiurge
|
2025-05-08 04:58:48
|
How does the rate/distortion curve of libjxl-tiny compare to the main libjxl library I wonder...
|
|
|
|
_wb_
|
2025-05-08 05:10:14
|
For high distance, libjxl is better. At low distance the gap gets smaller. At camera qualities, they're very close.
|
|
|
|
drhead
|
|
_wb_
are you interested in lossless or lossy? For just lossless, it's not too hard to make a simple encoder...
|
|
2025-05-08 06:26:28
|
Primarily lossless, probably do want lossy down the line but lossless is priority
|
|
|
|
A homosapien
|
|
Orum
at d1 (on v0.11.1) I notice a loss of detail on the dark side, while I see no changes on the right side
|
|
2025-05-08 10:13:31
|
Also, it looks like it's affected by the color desaturation issue we found a while ago
|
|
2025-05-08 10:22:06
|
It does look much sharper on v0.8 and eariler
|
|
|
|
Demiurge
|
2025-05-09 08:05:22
|
These three recurring problems (blurry shadows, general desaturation and chroma ringing artifacts) keep biting libjxl in the side... I wonder if libjxl-tiny is affected by these problems too?
|
|
2025-05-09 08:14:16
|
Those 3 issues are serious enough to make or break most images. Especially the crazy chroma ringing patterns
|
|
2025-05-09 08:16:26
|
I hope someone does an investigation into what causes them to appear... I don't think libjxl is in a position where it can afford to sit on its laurels without any major RDO changes in years.
|
|
|
|
Orum
|
2025-05-09 08:17:55
|
hard to say if the desaturation is simply a side effect of the blurring
|
|
|
|
Demiurge
|
2025-05-09 08:18:35
|
Even though the underlying quantization techniques are very impressive compared to other codecs, the impressive advancements are undermined by simple or trivial mistakes/bugs like that
|
|
|
|
_wb_
|
|
drhead
Primarily lossless, probably do want lossy down the line but lossless is priority
|
|
2025-05-09 09:18:15
|
I just created this, perhaps it can be useful as a starting point: https://github.com/libjxl/simple-lossless-encoder
|
|
|
|
jonnyawsom3
|
2025-05-09 09:28:07
|
Like I mentioned before, wouldn't it be less work to implement Squeeze and quantization than VarDCT on top of that? Obviously quality is another matter but it should be relatively straightforward to make *a* lossy encoder
|
|
|
|
_wb_
|
2025-05-09 09:47:19
|
Yeah, it shouldn't be too hard to turn it into a lossy modular encoder. Even without Squeeze, you could just quantize predictor residuals and get something lossy that is not great but maybe good enough for some applications.
|
|
|
|
drhead
|
|
_wb_
I just created this, perhaps it can be useful as a starting point: https://github.com/libjxl/simple-lossless-encoder
|
|
2025-05-09 10:25:31
|
Does look useful, thanks!
|
|
|
Lucius
|
|
_wb_
I just created this, perhaps it can be useful as a starting point: https://github.com/libjxl/simple-lossless-encoder
|
|
2025-05-09 10:11:45
|
Thank you! Compiled nicely in Visual Studio, only needed to #define __builtin_clz std::countl_zero (c++20)
|
|
|
|
Quackdoc
|
2025-05-10 03:24:38
|
is the output Information that cjxl prints to console explained anywhere in app or github?
was asked by a friend what the output meant of some of the stuff and it got me curious
|
|
|
Jyrki Alakuijala
|
|
_wb_
I think we're being too aggressive on the AC of the B component. <@532010383041363969> what's your opinion?
|
|
2025-05-10 01:30:49
|
probably you are right
|
|
|
_wb_
I think we're being too aggressive on the AC of the B component. <@532010383041363969> what's your opinion?
|
|
2025-05-10 01:43:45
|
S receptors don't see blue AC much, but L and M receptors see it when they are not masked by R and G signals
|
|
|
|
jonnyawsom3
|
2025-05-10 02:26:58
|
At least for XYB, a rather narrow range of B is required for saturated yellows, so the lower quality causes it to drift and lower the saturation, as far as I can tell
|
|
|
New Player ๐ฉ๐ช
|
2025-05-10 09:33:22
|
i need information about which distance values to choose
|
|
|
|
A homosapien
|
|
New Player ๐ฉ๐ช
i need information about which distance values to choose
|
|
2025-05-10 09:37:15
|
These are my general guidelines.
Professional workflow = 0.5
High quality = 1 (default)
Medium quality = 2
Low quality = 3
Very low quality preview/thumbnail = 4
|
|
2025-05-10 09:38:54
|
Using distances higher than 2.5 for web images is not recommended in my opinion
|
|
|
|
jonnyawsom3
|
2025-05-10 09:48:47
|
0.3 is "Looks like the original zoomed in 5x"
1 is "Looks like the original without zooming in"
3 is "Good enough for the internet"
Very roughly, though anything higher isn't recommended due to lack of tuning
|
|
|
Kupitman
|
|
A homosapien
These are my general guidelines.
Professional workflow = 0.5
High quality = 1 (default)
Medium quality = 2
Low quality = 3
Very low quality preview/thumbnail = 4
|
|
2025-05-10 09:49:46
|
What
|
|
2025-05-10 09:49:57
|
Why you use lossy
|
|
|
|
A homosapien
|
2025-05-10 09:52:06
|
Ask new player not me ๐
|
|
2025-05-10 09:52:48
|
I know the guidelines but I don't use lossy, I have the storage space to afford lossless.
|
|
|
|
jonnyawsom3
|
2025-05-10 09:54:21
|
I use lossy to test lossy, but until we're done fixing bugs and improving ratios, I'm sticking with the originals
|
|
|
AccessViolation_
|
2025-05-10 10:20:06
|
for photographic images, nearly lossless (like quality 98 or 99) is still *so much smaller* than lossless, and even when pixel peeping you're unlikely to spot any meaningful difference. you'll get very slight, often imperceptible changes in pixel values and I don't see value in retaining those. it's not like my camera captured the scene as it truly was anyway: taking a picture is a already a lossy process, I don't see value in preserving the inaccuracies from my camera, it's worth it to shuffle those inaccuracies around a bit and get a massive reduction in file size
|
|
2025-05-10 10:21:51
|
if I did want to capture the exact data from my camera for whatever reason, that's a good place for lossless JXL. like in raw files
|
|
|
|
A homosapien
|
2025-05-10 10:23:21
|
Most of my image files are already jpegs or non-photographic. So I benefit the most from lossless
|
|
2025-05-10 10:23:31
|
I do have several raws lying around that I would like to compress one day
|
|
|
|
jonnyawsom3
|
2025-05-10 10:35:30
|
The main blocker for RAWs in my case is libraw not making a release for 2 years, and not even knowing if it'll support JPEG XL compression because of Adobe's funky licencing of their SDK
|
|
|
๐ฐ๐๐๐
|
2025-05-11 07:38:46
|
Most RAW formats are proprietary and you need their proprietary tools (most of the time Windows exclusive) to process them properly. They also need color mastering/profiling... So, unless you are a professional dealing with photographs, RAW images probably mean nothing?
|
|
|
|
jonnyawsom3
|
2025-05-11 08:30:27
|
In my case I mean Bayer DNG
|
|
|
|
Orum
|
2025-05-11 09:04:37
|
there is a lot more than just 1 bayer pattern
|
|
2025-05-11 09:05:12
|
and then there's also things like cell response that need to be known to decode it properly
|
|
|
|
jonnyawsom3
|
2025-05-11 09:08:50
|
...yeah that's the point of DNG
|
|
2025-05-11 09:09:15
|
Otherwise I'd just have a PNG
|
|
|
|
Fab
|
2025-05-11 04:47:41
|
I imported all the JPEG XL inprovements into avif on youtube and facebook
|
|
2025-05-11 04:48:14
|
Current the encoder is much advanced even of SVT av1 psy and also all
|
|
2025-05-11 04:48:41
|
But with jxl improvements enforcing encoding is far slow
|
|
2025-05-11 04:50:02
|
Just search rosy rey sciglie tu on yt
|
|
2025-05-11 04:50:18
|
We're doing on logical way
|
|
2025-05-11 04:51:53
|
|
|
2025-05-11 04:52:10
|
Av1 with jxl improvements actually retains noise
|
|
|
|
Demiurge
|
|
|
CrushedAsian255
|
|
Fab
Just search rosy rey sciglie tu on yt
|
|
2025-05-11 05:14:58
|
Uhhโฆ unless you work at Google any modifications made to your encoder doesnโt matter as YouTube re-encodes itโฆ.
|
|
|
|
Fab
|
|
CrushedAsian255
Uhhโฆ unless you work at Google any modifications made to your encoder doesnโt matter as YouTube re-encodes itโฆ.
|
|
2025-05-11 05:15:47
|
Yes because they are studio films
|
|
2025-05-11 05:15:55
|
Singers
|
|
2025-05-11 05:16:25
|
Romanian videos exibits lot of bandings
|
|
|
|
Demiurge
|
2025-05-11 05:21:27
|
Where can I download the ultimate fab encoder
|
|
2025-05-11 05:22:06
|
I hope it's compatible with my templeOS
|
|
|
|
CrushedAsian255
|
|
Demiurge
Where can I download the ultimate fab encoder
|
|
2025-05-11 05:22:26
|
I should fine tune a small LLM
|
|
|
|
Fab
|
|
Demiurge
Where can I download the ultimate fab encoder
|
|
2025-05-11 05:26:24
|
SVT av1 hdr
|
|
2025-05-11 05:26:59
|
|
|
2025-05-11 05:27:15
|
18 hours ago
|
|
|
|
CrushedAsian255
|
2025-05-11 05:27:21
|
That looks quite blocky
|
|
|
|
Fab
|
2025-05-11 05:27:44
|
SVT av1 psy ex according to Julio is worse
|
|
2025-05-11 05:27:49
|
Like 44%
|
|
2025-05-11 05:27:59
|
If you want that
|
|
2025-05-11 05:28:22
|
Also this is 8 bit with zero optimizations
|
|
2025-05-11 05:28:27
|
๐
|
|
2025-05-11 05:29:09
|
You know pixel 9a Samsung isocell gn8
|
|
2025-05-11 05:29:45
|
Is an innovative sensor but is cheap
|
|
2025-05-11 05:37:34
|
|
|
2025-05-11 05:37:53
|
Another people has bragged off svt av1 hdr
|
|
2025-05-11 05:38:29
|
At 8 bit unfortunately is not really better than original SVT or libaom
|
|
|
|
jonnyawsom3
|
2025-05-11 05:44:35
|
<#805176455658733570>
|
|
|
|
Kupitman
|
|
Fab
At 8 bit unfortunately is not really better than original SVT or libaom
|
|
2025-05-12 08:12:21
|
i have result where av1-psy worse than new svt
|
|
|
|
Orum
|
2025-05-12 08:35:12
|
which psy?
|
|
|
|
Kupitman
|
|
Orum
which psy?
|
|
2025-05-12 10:50:25
|
Advanced ssim/psy
|
|
|
|
Orum
|
2025-05-12 10:50:51
|
๐ what?
|
|
2025-05-12 10:50:59
|
I'm asking which encoder
|
|
|
|
Jyrki Alakuijala
|
2025-05-12 04:25:09
|
I have started on reducing oversmoothing in JPEG XL vardct quality. The first PR is https://github.com/libjxl/libjxl/pull/4250
|
|
|
|
A homosapien
|
|
Jyrki Alakuijala
I have started on reducing oversmoothing in JPEG XL vardct quality. The first PR is https://github.com/libjxl/libjxl/pull/4250
|
|
2025-05-12 04:29:21
|
I will compile and test on my local image corpus later today
|
|
|
|
Jyrki Alakuijala
|
|
A homosapien
I will compile and test on my local image corpus later today
|
|
2025-05-12 04:59:58
|
don't expect much
I will read all feedback seven times and reflect on it
|
|
|
New Player ๐ฉ๐ช
i need information about which distance values to choose
|
|
2025-05-12 05:02:11
|
Choose distance = 1. If it looks too good, go to 1.5, if it looks too bad, go to 0.6
|
|
|
|
CrushedAsian255
|
|
Jyrki Alakuijala
Choose distance = 1. If it looks too good, go to 1.5, if it looks too bad, go to 0.6
|
|
2025-05-12 11:12:27
|
> looks too good
|
|
|
|
Demiurge
|
|
Jyrki Alakuijala
I have started on reducing oversmoothing in JPEG XL vardct quality. The first PR is https://github.com/libjxl/libjxl/pull/4250
|
|
2025-05-13 05:01:43
|
Wish there was an example image attached ๐
|
|
|
|
Jyrki Alakuijala
|
2025-05-13 10:09:27
|
before, after and original
|
|
2025-05-13 10:12:48
|
I'll try to make the L2-based selection criteria to have some SSIM inspiration today in the afternoon, with hopes that I can push for even more sharpness without losing all the good characteristics of smoothing
|
|
|
|
Tirr
|
2025-05-13 10:15:34
|
the new one looks better to me indeed
|
|
|
|
Jyrki Alakuijala
|
2025-05-13 10:16:26
|
๐
๐
๐
if it looked worse, I don't merge the PR ๐
๐
๐
|
|
|
|
JKUser4592
|
2025-05-13 04:50:47
|
How do I use Image Toolbox from T8RIN to play animated JXL files on Android devices?
https://github.com/T8RIN/ImageToolbox
https://github.com/T8RIN/ImageToolbox/issues/1733
|
|
|
|
AccessViolation_
|
|
Jyrki Alakuijala
before, after and original
|
|
2025-05-13 05:18:19
|
nice ๐
I wonder how much this affects the file size?
|
|
|
|
jonnyawsom3
|
|
JKUser4592
How do I use Image Toolbox from T8RIN to play animated JXL files on Android devices?
https://github.com/T8RIN/ImageToolbox
https://github.com/T8RIN/ImageToolbox/issues/1733
|
|
2025-05-13 05:43:50
|
Please stop opening issues, posting to Reddit and asking here at the same time. It causes a mess and no one knows where they're meant to awnser you
|
|
|
|
Mine18
|
|
JKUser4592
How do I use Image Toolbox from T8RIN to play animated JXL files on Android devices?
https://github.com/T8RIN/ImageToolbox
https://github.com/T8RIN/ImageToolbox/issues/1733
|
|
2025-05-13 06:12:01
|
use the preview feature
|
|
|
|
JKUser4592
|
|
Mine18
use the preview feature
|
|
2025-05-13 06:12:18
|
How does that work?
|
|
|
|
Mine18
|
2025-05-13 06:12:34
|
you go to the feature, select the image you want, and you view it
|
|
|
|
Jyrki Alakuijala
|
|
AccessViolation_
nice ๐
I wonder how much this affects the file size?
|
|
2025-05-13 08:23:55
|
0.1 % perhaps, or 0.05 %, the butteraugli vals get slightly worse so it is a gut feeling guess rather than an exact value
|
|
|
Please stop opening issues, posting to Reddit and asking here at the same time. It causes a mess and no one knows where they're meant to awnser you
|
|
2025-05-13 08:24:49
|
Isn't all PR good PR?!
|
|
|
|
jonnyawsom3
|
|
Jyrki Alakuijala
Isn't all PR good PR?!
|
|
2025-05-13 08:27:24
|
The Reddit is good, but opening an issue on github isn't doing much for PR, just making more work for maintainers
|
|
2025-05-13 08:29:07
|
The developer of the app already answered and closed the issue, then they asked the same question on Reddit and here at the same time. Just annoys me a bit since everyone ends up having to say the same thing in three different places
|
|
2025-05-13 08:30:48
|
Wanting help is fine, but they've done this every time they've had a question, so it's getting a bit spammy for me
|
|
|
|
Jyrki Alakuijala
|
|
The Reddit is good, but opening an issue on github isn't doing much for PR, just making more work for maintainers
|
|
2025-05-13 08:36:59
|
I consider every issue is a documented signal of interest in JPEG XL and can end up being valuable in "breaking dams" and letting water to flow. In the past I always tried to encourage creating issues.
|
|
|
|
jonnyawsom3
|
|
Jyrki Alakuijala
I consider every issue is a documented signal of interest in JPEG XL and can end up being valuable in "breaking dams" and letting water to flow. In the past I always tried to encourage creating issues.
|
|
2025-05-13 08:54:08
|
An interesting view. I agree with your perspective, but I don't think it applies much when the software already has support. Then questions are better asked here or in the community, if it's technical then an issue is valid. But crossposting across all three should be avoided, it only splits the help that people give and makes it harder to find a definite awnser
|
|
|
|
AccessViolation_
|
|
Jyrki Alakuijala
0.1 % perhaps, or 0.05 %, the butteraugli vals get slightly worse so it is a gut feeling guess rather than an exact value
|
|
2025-05-13 11:02:23
|
oh nice, not bad at all!
by the way, are you aware of this thread? might be helpful for benchmarking your work against cherry picked documented cases of the regression if that's something you want to do
https://discord.com/channels/794206087879852103/1278292301038227489
|
|
2025-05-13 11:04:17
|
(idk how to make that not sound like I'm requesting something - just making you aware ๐)
|
|
|
|
Jyrki Alakuijala
|
|
Jyrki Alakuijala
I'll try to make the L2-based selection criteria to have some SSIM inspiration today in the afternoon, with hopes that I can push for even more sharpness without losing all the good characteristics of smoothing
|
|
2025-05-14 07:20:24
|
SSIM as a smoothing selection objective did not work out, not even weighted added to L2. I gave up with it. Now looking at adding an interblock delta correctness objectives for smoothing selection. This looked promising in initial runs, overnight optimization of heuristics parameters have been running... I'm eager to see the results soon ๐๐๐
|
|
|
|
Demiurge
|
|
Jyrki Alakuijala
before, after and original
|
|
2025-05-15 07:15:02
|
WAY better! NICE!!
|
|
2025-05-15 07:16:42
|
What promise and potential. If you keep pulling off miracles like this Jyrki you'll really be a wizard
|
|
2025-05-15 07:25:57
|
Is it possible to make photographic images more noisy and gritty without causing mosquito artifacts on high contrast graphics?
|
|
2025-05-15 07:29:14
|
Actually, the most important thing to fix right now is probably the most serious bugs first, with extreme chroma ringing noise as seen in "clovisfest" image, extreme color desaturation as seen in almost all images with yellow/orange/green, and blurry shadows as seen in "pont du qebec" image.
|
|
|
Jyrki Alakuijala
I have started on reducing oversmoothing in JPEG XL vardct quality. The first PR is https://github.com/libjxl/libjxl/pull/4250
|
|
2025-05-15 07:30:14
|
Does this PR make a difference on "pont du qebec" bridge image with lots of dark shadows?
|
|
2025-05-15 07:32:39
|
https://commons.wikimedia.org/wiki/File:125_-_Qu%C3%A9bec_-_Pont_de_Qu%C3%A9bec_de_nuit_-_Septembre_2009.jpg
|
|
|
|
Jyrki Alakuijala
|
|
Demiurge
Is it possible to make photographic images more noisy and gritty without causing mosquito artifacts on high contrast graphics?
|
|
2025-05-16 03:47:13
|
We could have modes of operation, for example if photon noise option has been chosen then we could use those larger transforms more eagerly, those that are effective at compressing but create a bit of spatial noise in their operation
|
|
|
Demiurge
What promise and potential. If you keep pulling off miracles like this Jyrki you'll really be a wizard
|
|
2025-05-16 03:49:31
|
Im just fixing my own old bugs ๐
|
|
|
|
Demiurge
|
|
Jyrki Alakuijala
We could have modes of operation, for example if photon noise option has been chosen then we could use those larger transforms more eagerly, those that are effective at compressing but create a bit of spatial noise in their operation
|
|
2025-05-16 04:15:29
|
What about automatically measuring and replacing lost noise after encoding instead of relying on manual selection of an ISO number...?
|
|
2025-05-16 04:19:00
|
Either with or without a pre-encode filtering step, whichever's more convenient.
|
|
|
|
_wb_
|
2025-05-16 05:24:51
|
Detection without preprocessing seems the safest approach to me. Where detection is mostly needed (imo) to ensure it's a photographic image, because you don't want to apply photon noise to a screenshot or a perfectly clean illustration.
|
|
2025-05-16 05:26:50
|
The detected noise level would then put an upper bound on the noise added, but the distance setting should also modulate it (less noise added at lower distances).
|
|
|
|
Demiurge
|
|
_wb_
Detection without preprocessing seems the safest approach to me. Where detection is mostly needed (imo) to ensure it's a photographic image, because you don't want to apply photon noise to a screenshot or a perfectly clean illustration.
|
|
2025-05-16 06:23:18
|
But for a clean illustration, without any grain like in a natural image, the detected amount of uniform noise loss after encoding would be much lower than for a natural photographic image, right? So maybe that's how you would be able to detect a clean graphic vs natural photo
|
|
2025-05-16 06:31:20
|
https://afontenot.github.io/image-formats-comparison/#pont-de-quebec&AV1=l&JPEGXL=l
|
|
2025-05-16 06:32:38
|
This is a really bad image for jxl, I wonder if Jyrki's newest PR decreases blurring on the bridge at all?
|
|
2025-05-16 06:34:34
|
https://github.com/afontenot/image-formats-comparison/blob/master/comparisonfiles/subset1/original/125_-_Qu%C3%A9bec_-_Pont_de_Qu%C3%A9bec_de_nuit_-_Septembre_2009.png
|
|
2025-05-16 06:35:05
|
Here's a link to the same version of the file used on the comparison page
|
|
2025-05-16 06:35:12
|
For convenience
|
|
2025-05-16 06:37:19
|
It's the perfect image for demonstrating how jxl reacts badly to dark shadows. You can see JXL preserves the texture of the bricks well. But the steel struts and columns are a complete mess.
|
|
2025-05-16 06:37:42
|
compared to other codecs.
|
|
2025-05-16 06:42:11
|
In fact, even mozjpeg outperforms jxl here
|
|
2025-05-16 06:42:22
|
It's pretty serious
|
|
2025-05-16 06:42:43
|
At least, on the comparison page it does.
|
|
|
|
_wb_
|
|
Demiurge
But for a clean illustration, without any grain like in a natural image, the detected amount of uniform noise loss after encoding would be much lower than for a natural photographic image, right? So maybe that's how you would be able to detect a clean graphic vs natural photo
|
|
2025-05-16 06:42:59
|
Exactly, so it would make sense to have some threshold in the detection where if the detected noise is below the threshold, noise generation is just skipped. Possibly this could also be a trigger to make some other decisions like gaborish or the amount of effort spent on patch detection.
|
|
|
|
Demiurge
|
2025-05-16 06:43:00
|
https://afontenot.github.io/image-formats-comparison/#pont-de-quebec&MOZJPEG=l&JPEGXL=l
|
|
|
_wb_
Exactly, so it would make sense to have some threshold in the detection where if the detected noise is below the threshold, noise generation is just skipped. Possibly this could also be a trigger to make some other decisions like gaborish or the amount of effort spent on patch detection.
|
|
2025-05-16 06:43:22
|
Yeah, that would be a super clever idea.
|
|
2025-05-16 06:43:35
|
It would be like knocking out multiple birds with one stone.
|
|
|
|
A homosapien
|
|
Demiurge
https://afontenot.github.io/image-formats-comparison/#pont-de-quebec&MOZJPEG=l&JPEGXL=l
|
|
2025-05-16 07:08:50
|
What? Mozjpeg looks terrible here, banding in the sky, blockiness all over
|
|
|
Jyrki Alakuijala
Im just fixing my own old bugs ๐
|
|
2025-05-16 09:01:39
|
Question, is it possible that epf and/or gaborish are not doing their job properly? In my opinion they seem to ignore artifacts and smooth out detail, adding noise to places where it shouldn't and blurring noisy areas, it's like inverse logic.
|
|
2025-05-16 09:06:02
|
Here is a visual example, in 0.8 it looks like the filters help image quality when compared to `--epf 0 --gaborish 0`. But in Main (with your sharpness PR) the filters looks like it somewhat hurts image quality (in some regions). __Open these animated WebP's in a browser or download them to avoid Discord's compression.__
|
|
2025-05-16 09:07:20
|
This is high fidelity by the way, distances 1.2 - 1.4. All comparisons with similar BPP.
|
|
2025-05-16 09:12:06
|
I think I've mentioned this before, even at a baseline level with `--epf 0 and --gaborish 0` Main still looks blurrier than 0.8. It's just that the filters widen the gap even more I think.
|
|
2025-05-16 09:12:52
|
Oh yeah I did do some testing before hand, sorry for being redundant. ๐
https://discord.com/channels/794206087879852103/1278292301038227489/1297641128333410404
|
|
|
|
jonnyawsom3
|
2025-05-16 11:27:39
|
During the generation loss PRs, I recall people saying that Gaborish was misaligned with the decoder, causing more blurring than there should be
|
|
|
|
_wb_
|
2025-05-16 12:32:06
|
Encoder gaborish is not perfectly the inverse of decoder gaborish. It does make sense to sharpen slightly more than only inverting decoder gaborish, to compensate for the blurring introduced by DCT quantization.
But I think it's somewhat ad hoc right now, not very principled. Encoder gaborish always does the same thing, which doesn't make sense: it should converge towards being as close as possible to the inverse of decoder gaborish as distance goes to zero, while it can deviate more from that as distance gets higher. Also, ideally encoder gaborish should take adaptive quantization into account too (but that is complicated since AQ is done after fwd gaborish is already done).
|
|
|
|
CrushedAsian255
|
2025-05-16 12:41:42
|
does the spec allow that? wouldn't it cause an increase in error?
|
|
|
|
Tirr
|
2025-05-16 01:11:34
|
it's lossy encoder anyway
|
|
|
|
username
|
2025-05-16 01:12:00
|
I mean doesn't the spec just define decoding for the most part? like an encoder can do whatever it wants as long as the result is a valid JXL file or stream that can be decoded
|
|
|
|
CrushedAsian255
|
2025-05-16 01:12:25
|
Oh I thought the decoder was off
|
|
|
|
_wb_
|
2025-05-16 01:15:31
|
The spec only defines decoder gaborish. An encoder can do whatever it wants โ of course the goal is always to get as much fidelity as possible at every bitrate. The straightforward thing to do would be to make it so that dec_gaborish(enc_gaborish(image)) = image, but this is not quite possible with a small convolution kernel, and it's also not necessarily the best thing to do because the end result will be something like dec_gaborish(IDCT(DCT(enc_gaborish(image)))) so if enc_gaborish can compensate a bit for the error introduced by the lossy compression, it's better than if it just compensates for dec_gaborish...
|
|
|
|
CrushedAsian255
|
|
_wb_
The spec only defines decoder gaborish. An encoder can do whatever it wants โ of course the goal is always to get as much fidelity as possible at every bitrate. The straightforward thing to do would be to make it so that dec_gaborish(enc_gaborish(image)) = image, but this is not quite possible with a small convolution kernel, and it's also not necessarily the best thing to do because the end result will be something like dec_gaborish(IDCT(DCT(enc_gaborish(image)))) so if enc_gaborish can compensate a bit for the error introduced by the lossy compression, it's better than if it just compensates for dec_gaborish...
|
|
2025-05-16 01:38:33
|
ohhh so `dec_gaborish` is well-defined but the encoder can write whatever bits they want
|
|
|
|
Traneptora
|
|
Please stop opening issues, posting to Reddit and asking here at the same time. It causes a mess and no one knows where they're meant to awnser you
|
|
2025-05-16 03:21:57
|
pretty sure they're teh same person as https://discord.com/channels/794206087879852103/794206170445119489/1199019206486806548
|
|
|
|
jonnyawsom3
|
|
|
Jyrki Alakuijala
|
|
_wb_
Encoder gaborish is not perfectly the inverse of decoder gaborish. It does make sense to sharpen slightly more than only inverting decoder gaborish, to compensate for the blurring introduced by DCT quantization.
But I think it's somewhat ad hoc right now, not very principled. Encoder gaborish always does the same thing, which doesn't make sense: it should converge towards being as close as possible to the inverse of decoder gaborish as distance goes to zero, while it can deviate more from that as distance gets higher. Also, ideally encoder gaborish should take adaptive quantization into account too (but that is complicated since AQ is done after fwd gaborish is already done).
|
|
2025-05-17 08:52:19
|
Also a matter of added entropy. Id anticipate that encoder does a little less sharpening than the decoder does fot blurring... ๐
|
|
|
CrushedAsian255
ohhh so `dec_gaborish` is well-defined but the encoder can write whatever bits they want
|
|
2025-05-17 08:53:32
|
Gaborish coefficients are in the bitstream (to override the default gaborish), so one could play with that
|
|
|
|
Demiurge
|
|
A homosapien
What? Mozjpeg looks terrible here, banding in the sky, blockiness all over
|
|
2025-05-17 09:42:46
|
On Large size mozjpeg looks better. On Medium yes the sky is blocky but the bridge is all smudged in libjxl whereas mozjpeg retains more bridge details. libjxl does extremely bad on this image because of all the details in the shadows.
|
|
2025-05-17 09:43:41
|
Aside from the blockiness of the sky, mozjpeg is far better than libjxl here
|
|
2025-05-17 09:44:00
|
Just look at the bridge.
|
|
2025-05-17 09:44:19
|
Even on Large filesize, aka d=1
|
|
2025-05-17 09:44:34
|
The default quality setting of libjxl
|
|
|
|
jonnyawsom3
|
2025-05-17 09:45:03
|
So half the image looks terrible in mozjpeg, half the image looks bad in JXL
|
|
|
|
Demiurge
|
2025-05-17 09:45:08
|
libjxl is supposed to be optimized for high bitrate high fidelity, so losing to mozjpeg is pretty bad
|
|
|
So half the image looks terrible in mozjpeg, half the image looks bad in JXL
|
|
2025-05-17 09:47:35
|
https://raw.githubusercontent.com/afontenot/image-formats-comparison/refs/heads/master/comparisonfiles/subset1/large/MOZJPEG/125_-_Qu%C3%A9bec_-_Pont_de_Qu%C3%A9bec_de_nuit_-_Septembre_2009.jpg
|
|
2025-05-17 09:47:39
|
Does this look terrible to you?
|
|
2025-05-17 09:47:55
|
This is mozjpeg at the same size as libjxl d=1
|
|
2025-05-17 09:48:45
|
https://github.com/afontenot/image-formats-comparison/raw/refs/heads/master/comparisonfiles/subset1/large/JPEGXL/125_-_Qu%C3%A9bec_-_Pont_de_Qu%C3%A9bec_de_nuit_-_Septembre_2009.jxl
|
|
2025-05-17 09:49:15
|
Here's libjxl with less sharpness and more blurring on the bridge details
|
|
2025-05-17 09:53:34
|
mozjpeg large is clearly superior to libjxl large here
|
|
2025-05-17 09:54:40
|
libjxl is supposed to be very well optimized at this bitrate, so this is a pretty severe and embarrassing bug
|
|
2025-05-17 09:55:05
|
The problem lies in how libjxl handles details in dark shaded regions.
|
|
2025-05-17 09:55:44
|
It's a very common problem in a lot of old video codecs
|
|
2025-05-17 09:56:21
|
You can see it in a lot of digital video whenever there is a fade-to-black and the image suddenly looks horrible as it gets darker.
|
|
2025-05-17 09:56:41
|
libjxl evidently has the same problem
|
|
2025-05-17 09:57:36
|
This isn't a problem in newer and more sophisticated video codecs, like libaom, but often a problem with older and more primitive codecs, like hardware encoders.
|
|
|
|
CrushedAsian255
|
2025-05-17 10:38:39
|
Is it due to it not taking into account the 1+1 vs 100+1 human perception thing?
|
|
|
|
Demiurge
|
2025-05-17 12:24:28
|
Basically. It does take it into account, but not very well.
|
|
2025-05-17 12:25:43
|
It over-aggressively quantizes low-contrast, dark regions much worse than mozjpeg or libaom.
|
|
|
|
jonnyawsom3
|
2025-05-17 12:33:23
|
I wonder if that's related to the high quantization of the B channel
|
|
|
|
A homosapien
|
|
Demiurge
Does this look terrible to you?
|
|
2025-05-17 12:46:59
|
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.
|
|
|
|
Demiurge
|
|
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:30:41
|
You can easily compare here
https://afontenot.github.io/image-formats-comparison/#pont-de-quebec&MOZJPEG=l&JPEGXL=l
|
|