|
retr0id
|
2021-06-24 09:23:58
|
Is the Squeeze transform used anywhere outside of jxl?
|
|
|
_wb_
|
2021-06-24 10:01:59
|
I came up with it in fuif
|
|
|
Jyrki Alakuijala
|
|
lithium
A little curious, new vardct improve also can affect -d 0.5 and -d 1.0 quality?
I still can see some tiny ringing on those distance for anime content image,
(Those tiny ringing like white sugar spread on smooth gradient and sharp lines detail area,
not easy to notable, but feel little annoying.)
> Tuning ac strategy heuristics
> https://github.com/libjxl/libjxl/commit/45692670c6d414e8ec60eb2ed0ba2c4b948ca617
> Reversing the decision tree
> https://github.com/libjxl/libjxl/commit/32594679eddab5578922b0e20064a6a3dc2d3fde
|
|
2021-06-24 10:34:42
|
I'm still trying to find improvements. I consider that it is likely about half of the improvements I'm able to find I have submitted in those two CLs. I certainly hope there is a substantial improvement already.
|
|
2021-06-24 10:35:04
|
There may be some more improvements possible with more exotic things like delta palettization use for anime.
|
|
2021-06-24 10:35:24
|
it already works 20 % more dense for some types of graphics than jxl:d1
|
|
2021-06-24 10:35:38
|
20 % more dense in bpp * pnorm metric
|
|
2021-06-24 10:36:08
|
delta palettization has some dithering artefacts still that can be annoying, but those are easier to fix than VarDCT heuristics
|
|
2021-06-24 10:37:04
|
it looks to me that some of these anime pics were painted directly to pixels with tools that left some pixels as pixels
|
|
2021-06-24 10:37:26
|
when/if the artists use tools that do less discretization, then automatically VarDCT will be a better fit
|
|
2021-06-24 10:37:55
|
when the pixels are bare and disjoint, then delta palettization should be/become awesome, especially in the higher quality end
|
|
|
|
retr0id
|
2021-06-24 11:02:31
|
I think I understand what Squeeze is doing at an intuitive level now. Would it be fair to say that it's almost like DCT, but cheaper, and operating over the whole Group?
|
|
|
|
Jyrki Alakuijala
|
2021-06-25 12:30:03
|
The compression artefacts from squeeze are slightly worse than those of dct -- however, squeeze is better suited for progression
|
|
2021-06-25 12:30:33
|
next 0.14 % improvement with some improvements to ringing is pending: https://github.com/libjxl/libjxl/pull/221
|
|
2021-06-25 12:30:51
|
it is much less effective than I expected
|
|
2021-06-25 12:31:34
|
I was hoping for 0.5+ % and for a significant impact on ringing, this is probably just a 2 % reducting in ringing surface area
|
|
2021-06-25 12:32:00
|
but there are more ideas to try 🙂
|
|
2021-06-25 12:32:22
|
...
|
|
2021-06-25 12:33:10
|
any ideas on what would be the best way to test JPEG XL vs. AVIF for 'camera quality' settings, i.e., d0.5-d1 range?
|
|
2021-06-25 12:33:42
|
I'm thinking of 2x pixels, flicker test with gray in between
|
|
2021-06-25 12:33:53
|
corpus level size calibration instead of image level
|
|
2021-06-25 12:35:22
|
... either corpus level size calibration that or users could be asked to choose a size for both where the flicker test no longer flickers when displayed with original
|
|
2021-06-25 12:36:41
|
the usual image quality testing methodology stops working at around 1 bpp (at least when combined with a large mixture of qualities in the same test set), and I believe we need something better for the highest quality
|
|
|
|
_wb_
|
2021-06-25 05:26:38
|
See <#794206087879852106>
|
|
|
retr0id
I think I understand what Squeeze is doing at an intuitive level now. Would it be fair to say that it's almost like DCT, but cheaper, and operating over the whole Group?
|
|
2021-06-25 05:29:26
|
It's a reversible Haar transform which is modified to have a built-in nonlinear predictor that tries to avoid ringing by interpolating in locally monotonic regions but falling back to basically NN in locally nonmonotonic regions.
|
|
2021-06-25 05:30:11
|
That's the best one-sentence description I can do :)
|
|
|
Cool Doggo
|
2021-06-25 06:10:21
|
long sentence
|
|
|
lithium
|
|
Jyrki Alakuijala
I'm still trying to find improvements. I consider that it is likely about half of the improvements I'm able to find I have submitted in those two CLs. I certainly hope there is a substantial improvement already.
|
|
2021-06-25 11:20:34
|
I understand, Thank you for your work. 🙂
|
|
|
|
retr0id
|
2021-06-25 01:39:29
|
noooooo, I have to write an ANS decoder now...
|
|
2021-06-25 01:41:34
|
scary math
|
|
|
|
Deleted User
|
|
Jyrki Alakuijala
Matt, there has been so many quality improvements that you might want to consider -q 92 --noise=1 already 😄
|
|
2021-06-25 02:05:05
|
But I thought they were mostly for lower quality images. Or are these x% improvements consistent across any reasonable quality level?
|
|
|
Pieter
|
|
retr0id
noooooo, I have to write an ANS decoder now...
|
|
2021-06-25 03:32:40
|
of all possible entropy decoders, ANS is possibly the easiest :)
|
|
2021-06-25 03:32:50
|
at least if it doesn't need to be fast
|
|
|
|
retr0id
|
2021-06-25 03:34:45
|
yeah it doesn't look *too* complicated, mathematically speaking, but the spec is pretty hard to follow (imho)
|
|
|
raysar
|
2021-06-25 04:52:08
|
i found a "bug", if i convert jxl into png with djxl, there is a exposition variation. It's the png convertion the problem. Original file is a ffmpeg rgb with no icc.
|
|
2021-06-25 04:52:25
|
orginal png:
|
|
2021-06-25 04:52:51
|
jxl (works great) :
|
|
2021-06-25 04:53:12
|
Converted jxl:
|
|
|
spider-mario
|
2021-06-25 04:54:15
|
they don’t have this issue when opened in Chrome
|
|
2021-06-25 04:54:21
|
are you sure that your viewer is properly color-managed?
|
|
2021-06-25 04:55:43
|
hm, interestingly, we create a png with iCCP and gAMA but no cHRM
|
|
2021-06-25 04:55:53
|
that’s an odd combination
|
|
|
|
raysar
|
2021-06-25 04:55:56
|
oh you're right, it's xnviewMP the problem :/
|
|
|
|
lithium
|
2021-06-25 04:56:22
|
> Input file: out_djxl.png | 597105 bytes
> Image: 800x450 pixels | 8 bits/sample | RGB | 241095 color(s)
> Delta filter: Mixed
> Chunks: gAMA, iCCP
>
> Input file: out_youtube.png | 766916 bytes
> Image: 800x450 pixels | 8 bits/sample | RGB | 119537 color(s)
> Delta filter: None
> Chunks: cHRM, gAMA, pHYs
|
|
|
|
raysar
|
2021-06-25 05:06:36
|
BUT !, i create an APNG with imagemagick and the exposition problem is present, look:
|
|
2021-06-25 05:08:26
|
I resume my apng creation 😄
- ffmpeg -ss 00:00:30 -i .\youtube.mp4 -vf 'select=not(mod(n\,500)),scale=160:90,tile=5x5' out_youtube.png
- cjxl.exe .\out_youtube.png .\out_youtube.jxl --target_size 47000
- magick.exe -quality 45 .\out_youtube.png .\out_youtube.webp
- magick.exe .\out_youtube.webp .\out_webp.png
- magick.exe .\out_youtube.jxl .\out_jxl.png
- edit with photoshop CC2019 in png
- magick.exe -delay 200 .\1.png .\2.png .\3.png .\thumbnail_youtube.apng
|
|
2021-06-25 05:09:28
|
It's the same webp quality than youtube thumbnail when you seek into video.
|
|
|
|
_wb_
|
2021-06-25 05:10:41
|
IM and many viewers assume a PNG is intending to be sRGB while it actually is a gamma 2.2 image if you interpret the png spec correctly
|
|
2021-06-25 05:11:27
|
Cjxl/djxl/chrome do it correctly, but it makes them seem wrong because so many others do it wrong
|
|
|
|
spider-mario
|
2021-06-25 05:17:47
|
this one is even neither, it’s gamma 2
|
|
2021-06-25 05:17:57
|
which is a bit odd
|
|
|
|
raysar
|
2021-06-25 05:21:23
|
But it's a problem, many picture have no color information like this png and we do not change it when we convert it in jxl.
|
|
|
|
spider-mario
|
2021-06-25 05:22:49
|
what do you mean? this one does have cHRM and gAMA chunks
|
|
|
|
raysar
|
2021-06-25 05:26:58
|
i don't understank well chunks http://www.libpng.org/pub/png/spec/1.2/PNG-Chunks.html
|
|
2021-06-25 05:31:10
|
i understand, it's the photoshop export the problem :/
|
|
|
|
_wb_
|
2021-06-25 05:31:35
|
Gamma 2 is maybe the compromise between the old Apple gamma 1.8 and sRGB?
|
|
|
|
Deleted User
|
|
_wb_
IM and many viewers assume a PNG is intending to be sRGB while it actually is a gamma 2.2 image if you interpret the png spec correctly
|
|
2021-06-25 05:33:04
|
What is the default for JXL?
|
|
|
|
_wb_
|
2021-06-25 05:33:20
|
There is no default
|
|
2021-06-25 05:33:30
|
There is always something explicit
|
|
2021-06-25 05:33:40
|
No room for interpretation
|
|
2021-06-25 05:34:28
|
Of course cjxl does need to make assumptions when it gets untagged input - it always assumes sRGB then
|
|
2021-06-25 05:34:51
|
(or maybe for pfm input it assumes linear sRGB, I guess)
|
|
|
|
spider-mario
|
2021-06-25 05:39:30
|
iirc yes, and for EXR as well
|
|
2021-06-25 05:39:46
|
(for EXR, I am more or less certain)
|
|
|
|
_wb_
|
2021-06-25 05:40:30
|
The ambiguity of untagged images and videos is something that has caused a lot of trouble in the past and still does
|
|
2021-06-25 05:40:48
|
We explicitly wanted to make that impossible in jxl
|
|
|
|
raysar
|
2021-06-25 05:40:56
|
Photophop is the problem here, it's the out_djxl.png that it cannot open correctly, exactly same problem for XNviewMP, imageGlass and Nomacs, only chrome do it correctly, i think it's a big problem :/
|
|
|
|
_wb_
|
2021-06-25 05:41:34
|
Maybe we should let djxl just always output an icc profile even if it's not strictly needed
|
|
|
|
spider-mario
|
2021-06-25 05:41:41
|
here, it does
|
|
|
|
_wb_
|
2021-06-25 05:41:49
|
Oh
|
|
2021-06-25 05:42:00
|
What is the issue then?
|
|
|
|
spider-mario
|
2021-06-25 05:42:39
|
the most effective solution here would likely be to convert the input to sRGB before converting, but if that is not desirable, another option is to ask djxl to do so when decompressing
|
|
2021-06-25 05:42:47
|
`djxl --color_space=RGB_D65_SRG_Rel_SRG`
|
|
|
|
_wb_
|
2021-06-25 05:45:15
|
We need abbreviations for common color spaces, no way I can remember that string
|
|
2021-06-25 05:45:30
|
--color_space=sRGB
|
|
2021-06-25 05:46:17
|
Maybe also one for DisplayP3 and Rec2100PQ, and an actual help screen for this :)
|
|
|
|
raysar
|
|
spider-mario
`djxl --color_space=RGB_D65_SRG_Rel_SRG`
|
|
2021-06-25 05:53:59
|
This change nothing, event with djxl --color_space=RGB_D65_SRG_Rel_SRG image have not the same exposition :/
|
|
2021-06-25 05:54:19
|
|
|
|
|
spider-mario
|
2021-06-25 05:56:05
|
this suggests that the viewer possibly displays the original image wrong as well
|
|
2021-06-25 05:56:16
|
not sure
|
|
2021-06-25 05:56:32
|
it’s not just chrome but gimp as well that displays both the same for me
|
|
2021-06-25 05:57:12
|
from what I recall when I looked at nomacs, it didn’t seem to have any color management at all
|
|
|
|
raysar
|
2021-06-25 05:58:19
|
orginal png file created by ffmpeg gamma is 1.961 ... cjxl do not copy this strange gamma 😄
|
|
|
|
spider-mario
|
2021-06-25 05:58:29
|
it does
|
|
|
|
_wb_
|
2021-06-25 05:58:36
|
Viewers displaying the original wrong is annoying.
|
|
2021-06-25 05:58:52
|
Likely the viewer ignores gAMA
|
|
2021-06-25 05:59:26
|
Many things ignore it, even if they do handle ICC profiles correctly
|
|
|
|
spider-mario
|
2021-06-25 05:59:52
|
```
$ examples/jxlinfo .../out_youtube.jxl
[…]
data color profile:
[…]
transfer_function gamma: 0.509940
```
|
|
2021-06-25 05:59:58
|
(it’s the inverse but it represents the same information)
|
|
|
|
_wb_
|
2021-06-25 05:59:59
|
They just see no ICC and assume sRGB
|
|
2021-06-25 06:00:08
|
Or assume display space
|
|
|
raysar
orginal png file created by ffmpeg gamma is 1.961 ... cjxl do not copy this strange gamma 😄
|
|
2021-06-25 06:01:14
|
Try `convert out_youtube.png test.ppm`
|
|
2021-06-25 06:01:27
|
Does test.ppm look the same as the png in your viewer?
|
|
|
|
raysar
|
2021-06-25 06:03:50
|
Yes it's exact same than png in xnviewMP
|
|
|
|
_wb_
|
2021-06-25 06:04:16
|
Then your viewer is the problem
|
|
2021-06-25 06:04:45
|
That command just takes the pixel values and puts them in a ppm
|
|
2021-06-25 06:04:57
|
A ppm is assumed to be sRGB
|
|
|
|
raysar
|
2021-06-25 06:10:38
|
You don't see the problem on xnviewMp on linux?
|
|
2021-06-25 06:19:57
|
So if png is correctly decoded (so without phoshop xnview imaglass and nomacs) it works great 😄
You can see here the apng comparison with png >webp(youtube quality)>jxl
|
|
|
cmov
|
2021-06-25 07:24:30
|
Hello there ! Sorry you probably hear this question often, but when is the spec gonna be released ?
|
|
|
improver
|
2021-06-25 07:27:38
|
"official release" when ISO procedures are over (someone else probably knows when this will happen) but otherwise FDIS is already released which means that spec is effectively frozen and only editorial changes are allowed
|
|
|
|
Jyrki Alakuijala
|
|
But I thought they were mostly for lower quality images. Or are these x% improvements consistent across any reasonable quality level?
|
|
2021-06-25 07:32:22
|
yes, and likely more effective at highest levels than lower levels
|
|
|
|
Cool Doggo
|
2021-06-25 07:33:33
|
what does the --noise 1 do <:thonkang:265487232083689473>
|
|
|
|
raysar
|
|
cmov
Hello there ! Sorry you probably hear this question often, but when is the spec gonna be released ?
|
|
2021-06-25 07:34:35
|
Maybe it leaks on z-library, maybe 😇
|
|
|
|
_wb_
|
|
improver
"official release" when ISO procedures are over (someone else probably knows when this will happen) but otherwise FDIS is already released which means that spec is effectively frozen and only editorial changes are allowed
|
|
2021-06-25 07:40:14
|
We are currently in the limbo state where the JPEG committee has approved the FDIS text (in January) to be submitted to ISO for balloting, so they recommended SC 29 to submit it, which has happened, but ISO has not accepted the submission yet because the ISO editor is still 'processing' the document, so the ballot hasn't started yet.
|
|
2021-06-25 07:40:48
|
Once the submission has been officially accepted, the ballot will start, which takes ~5.5 months
|
|
2021-06-25 07:41:35
|
So maybe we will have an approved IS end of 2021, maybe it will be early 2022
|
|
2021-06-25 07:41:51
|
The ISO process is frustratingly slow
|
|
2021-06-25 07:42:33
|
Nothing is going to change anymore though, except typo fixes maybe
|
|
2021-06-25 07:43:50
|
(if we even can get the typos fixed at this point, we might need to initiate a second edition to do that, which means doing the whole process again)
|
|
|
|
cmov
|
2021-06-25 07:44:17
|
Oh ok, thanks for the info 🙂
|
|
|
|
_wb_
|
2021-06-25 07:46:43
|
In a way, the reference implementation is in practice more normative than the spec itself. If there's a discrepancy at this point, we'll fix the spec, not the code.
|
|
2021-06-25 07:52:19
|
Theoretically the spec is the source of truth, but there are likely more bugs in the spec than in the code at this point, so I see the spec more as a kind of documentation to help people who want to reimplement the codec than as a guaranteed correct thing.
|
|
2021-06-25 07:54:31
|
Writing a spec is like writing 100 pages of code on paper, with some eyeballs to check if it's correct but not a large amount of them. Nobody can do that and have it completely perfect. It's likely to not even compile at all.
|
|
|
|
spider-mario
|
2021-06-25 09:05:30
|
yes, in fact we’ve had examples of that
|
|
|
|
raysar
|
2021-06-26 12:36:40
|
So i resume my gamma png problem from youtube ffmpeg video:
imageglass and xnviewMP displays png (converted from jxl) incorrectly, converted with imagemagick AND djxl
photoshop and nomacs displays png (converted from jxl) incorrectly converted with imagemagick BUT displays image correctly with djxl ...
xnviewMP displays jxl file correctly ...
imageglass and nomacs displays jxl incorrectly ...
webp conversion is good on all soft (photoshop don't support webp, what a joke) even when i convert it in png with imagemagick ...
|
|
2021-06-26 12:37:05
|
https://tenor.com/view/wtf-gif-14533740
|
|
|
|
_wb_
|
2021-06-26 05:18:00
|
Webp happens to work ok here because a lot of software just assumes webp to be sRGB
|
|
2021-06-26 05:18:05
|
Including dwebp
|
|
2021-06-26 05:18:44
|
Also cwebp just assumes the input is sRGB whatever you give it
|
|
|
fab
|
2021-06-26 12:08:19
|
jxl at 0.380 bpp
|
|
2021-06-26 12:08:26
|
|
|
2021-06-26 12:09:52
|
0.180 bpp medium
|
|
2021-06-26 12:11:14
|
the images look like the platelets in my bathroom
|
|
2021-06-26 01:07:17
|
for %i in (C:\Users\User\Documents\pna\1440p\*.png) do cjxl -q 54.14 -s 9 --epf=3 --use_new_heuristics --gaborish=0 %i %i.jxl
|
|
2021-06-26 01:07:50
|
the blocking is evident
|
|
2021-06-26 01:08:11
|
libjxl v0.3.7-169-g1f7445a win_x64 2021.06.26
|
|
|
|
_wb_
|
2021-06-26 01:35:27
|
I can imagine
|
|
2021-06-26 01:35:53
|
Gaborish should help to avoid blocking
|
|
2021-06-26 01:36:23
|
New heuristics are probably not so good
|
|
2021-06-26 01:37:00
|
q 54 is not very high quality
|
|
2021-06-26 01:37:45
|
I don't know if s9 (i.e. spending a lot of effort in optimizing for butteraugli) is a good idea at low quality
|
|
|
|
fab
|
2021-06-26 01:44:26
|
the fact is that webp2 at -q 55 -e 9 and avif at default quality -q 30 min -q 30 max are already doing good
|
|
2021-06-26 01:44:32
|
even if the image look like a puzzle
|
|
2021-06-26 01:44:47
|
with random jpeg artifacts
|
|
2021-06-26 01:45:25
|
i don't know how you call the zig zag like a block when is zoomed
|
|
2021-06-26 01:45:44
|
is the first page first image of your powerpoint Jon Sneyers JPEG XL
|
|
2021-06-26 01:46:00
|
cavif rs 1.3.0 is actually usable and great dssim
|
|
2021-06-26 01:46:20
|
do we need JPEG XL?
|
|
2021-06-26 01:46:48
|
is progression a valid reason? Were my aTU reason valid reason?
|
|
2021-06-26 01:47:31
|
Jpeg xl look like it was created today, no image optimization at all
|
|
2021-06-26 01:47:54
|
it choose a medium quality for resolution at applie same chroma at whole image pixels
|
|
|
|
_wb_
|
2021-06-26 01:53:06
|
I am not sure what you mean. Use default cjxl without any options if you want something safe and good. Do -q 80 or -q 70 if you want to go lower than that. I don't think it's a good idea to go much lower than that in an automated workflow where you don't want to manually inspect every encoded image to check that it is OK.
|
|
|
|
fab
|
2021-06-26 01:55:06
|
i haven't space
|
|
2021-06-26 01:55:30
|
and jpeg xl and jpeg images look tiring to me to see the same image during long time
|
|
2021-06-26 01:55:57
|
they have fidelity
|
|
2021-06-26 01:56:28
|
but still bigger blocks is a bigge bock + JPEG
|
|
|
|
Deleted User
|
|
Jyrki Alakuijala
yes, and likely more effective at highest levels than lower levels
|
|
2021-06-26 03:22:35
|
Ok, nice. But I think I will wait with reconsidering encode parameters until either libjxl supports dithering/more consistent noise=1 or Chrome+Firefox support JXL.
|
|
|
|
raysar
|
2021-06-26 05:13:55
|
I compile the last commit for windows 8f81c4c1, contain the last <@!532010383041363969> visual optimisation 🙂
for noob, cjxl.exe is the encoder 😄
https://1drv.ms/u/s!Aui4LBt66-MmkGDK0qLNLFT7mAdq?e=Vu5aze
|
|
|
|
Deleted User
|
2021-06-26 06:18:38
|
Why is every **e**ncoder called cjxl/cjpeg/cavif and not ejxl/ejpeg/eavif?
|
|
|
BlueSwordM
|
|
Why is every **e**ncoder called cjxl/cjpeg/cavif and not ejxl/ejpeg/eavif?
|
|
2021-06-26 06:21:03
|
EJPEG just looks wrong boiiii.
|
|
2021-06-26 06:21:35
|
EJXL could be the next generation JXL encoder: Enhanced JXL.
EAVIF just sounds wrong.
|
|
|
|
improver
|
2021-06-26 06:54:23
|
it's not encode/decode, but compress/decompress
|
|
|
Scope
|
2021-06-26 07:02:56
|
and coder/decoder
|
|
|
|
retr0id
|
2021-06-26 07:37:24
|
I really like how compact the encoding of the JPEG XL headers/metadata are
|
|
2021-06-26 07:39:29
|
crazy how much information can fit in just a handful of bytes
|
|
2021-06-26 07:41:21
|
on the other hand, it does make it more complex/expensive to check whether a given file is valid
|
|
|
|
_wb_
|
2021-06-26 08:17:47
|
yes it's pretty annoying if you just want to know the image dimensions for example
|
|
2021-06-26 08:18:08
|
we may have overdone it a bit just to save some extra bits
|
|
2021-06-26 08:18:27
|
then again it is quite cool to have nice jxl art in 30-40 bytes
|
|
|
Why is every **e**ncoder called cjxl/cjpeg/cavif and not ejxl/ejpeg/eavif?
|
|
2021-06-26 08:20:09
|
flif just did both with the same tool - first file argument makes it clear enough to know if you're encoding or decoding
|
|
|
|
Jyrki Alakuijala
|
|
Why is every **e**ncoder called cjxl/cjpeg/cavif and not ejxl/ejpeg/eavif?
|
|
2021-06-26 08:37:35
|
Perhaps because engineers like when the c and d are next to each other in alphabet...
|
|
2021-06-26 08:38:05
|
I suspect we copied the practice from webp rather than thought it over seriously
|
|
|
diskorduser
|
2021-06-26 08:41:08
|
isn't cjpeg older than webp?
|
|
|
|
Jyrki Alakuijala
|
2021-06-26 08:42:15
|
yes, there, too
|
|
2021-06-26 08:42:33
|
in practice we don't use cjpeg, but convert or mozjpeg 😛
|
|
|
|
improver
|
2021-06-26 08:53:23
|
encompressing/decompressing
|
|
|
|
spider-mario
|
2021-06-27 09:47:10
|
it’s cjpeg with mozjpeg too
|
|
2021-06-27 09:47:16
|
it reuses the same binary names
|
|
2021-06-27 09:48:34
|
but yes, convert tends to be more practical 😁
|
|
|
|
Jyrki Alakuijala
|
2021-06-27 09:56:33
|
I had forgotten that
|
|
2021-06-27 09:56:54
|
I wonder if it would be a good idea to integrate mozjpeg into convert as a default jpeg encoder
|
|
|
|
spider-mario
|
2021-06-27 10:05:32
|
from what I understand, it doesn’t really matter to imagemagick which libjpeg it links to
|
|
2021-06-27 10:05:35
|
it can be mozjpeg
|
|
2021-06-27 10:05:45
|
in which case it just uses mozjpeg transparently
|
|
2021-06-27 10:06:20
|
I believe it can even be changed dynamically, they are ABI-compatible
|
|
2021-06-27 10:06:36
|
which one is actually used will likely depend on the distribution
|
|
2021-06-27 10:06:45
|
maybe some use mozjpeg as the system-wide default libjpeg
|
|
|
spider-mario
I believe it can even be changed dynamically, they are ABI-compatible
|
|
2021-06-27 10:07:50
|
ah, yes: https://github.com/mozilla/mozjpeg
> MozJPEG is compatible with the libjpeg API and ABI. It is intended to be a drop-in replacement for libjpeg. MozJPEG is a strict superset of libjpeg-turbo's functionality. All MozJPEG's improvements can be disabled at run time, and in that case it behaves exactly like libjpeg-turbo.
|
|
|
|
improver
|
2021-06-27 10:41:40
|
ye i replaced it systemwide and everything works
|
|
|
|
Jyrki Alakuijala
|
2021-06-27 11:18:59
|
floating 16x16/8x16/16x8 blocks gives now a 0.2 % improvement on bpp * pnorm -- but in my visual comparison there is a lot more ringing... looks like I need to find a better way to measure and control the ringing
|
|
2021-06-27 11:19:31
|
(not yet in a PR)
|
|
|
|
improver
|
2021-06-27 11:22:33
|
it makes ringing worse?
|
|
2021-06-27 11:22:46
|
or less bad?
|
|
|
|
fab
|
2021-06-27 11:24:49
|
fix the blocking
|
|
2021-06-27 11:25:20
|
i did 1920x1440 -q 54.14 -s 9 --epf=3 --use_new_heuristics --gaborish=0
|
|
2021-06-27 11:25:36
|
and image looked like bathroom floorings at 0.180 bpp
|
|
2021-06-27 11:26:01
|
jxl bigger blocks like make even more straining of the eye and more blocking when you watch the image for a long time
|
|
2021-06-27 11:26:13
|
jon said use d 1 for visual transparencvy
|
|
2021-06-27 11:26:19
|
he don't advertise jxl
|
|
2021-06-27 11:26:25
|
he said works for visually lossles
|
|
2021-06-27 11:27:01
|
though will it improve on final 0.4.0 from169 encode with libjxl v0.3.7-169-g1f7445a win_x64 2021.06.26 and do -s 9 -d 1
|
|
2021-06-27 11:27:19
|
will have better generation loss than current modes?
|
|
2021-06-27 11:27:59
|
what i have upgrading jpeg xl other than less ringing and a bit less noticeable blocking and only less significative improvements?
|
|
2021-06-27 11:28:09
|
and decoding speed?
|
|
2021-06-27 11:28:33
|
images looks always good for the face, especially female face
|
|
2021-06-27 11:29:22
|
anime are starting to look decent you can do same command with g1f7445a but new heuristics and the blocking i think there isn't
|
|
2021-06-27 11:29:52
|
full hd images now weight 90 kb every single image with visually lossless
|
|
2021-06-27 11:30:45
|
though cavif rs, explicit images, storing more than 1000 4k frames, storing 2k screenshots of a mobile
|
|
2021-06-27 11:30:56
|
so new phones 2400x1080
|
|
2021-06-27 11:31:22
|
too early for use jpeg xl for that, jpeg xl is good for normal use, but i expect more
|
|
2021-06-27 11:33:10
|
memory is cheap now you can buy 128 gb sd card for mobile at 19,99 euros
|
|
2021-06-27 11:33:38
|
but still compression is desiderable for web
|
|
|
|
Jyrki Alakuijala
|
2021-06-27 01:02:30
|
I'm not yet working on new heuristics
|
|
2021-06-27 01:03:15
|
using larger transforms where possible will improve on tiling and geometry interpolation, but adds ringing
|
|
2021-06-27 01:03:23
|
I just need to be able to make better compromises
|
|
|
fab
what i have upgrading jpeg xl other than less ringing and a bit less noticeable blocking and only less significative improvements?
|
|
2021-06-27 06:11:33
|
There have been very few quality improvements in 2021 compared to previous years. This is because we are doing the 'engineering transformation' now. It means security fuzzing, memory use reduction, coding speed improvements, fixing broken features, doing integration.
|
|
2021-06-27 06:12:46
|
I believe we have reached a situation where the engineering quality is not a huge blocker for integrations and we can shift some of the focus back to quality/density focus again.
|
|
2021-06-27 06:13:57
|
I certainly wish we can have a competitive d3, too. Occasionally even d4 looks okeyish. I personally prefer the d1-d1.5 even if I'm on pay-per-gigabyte mobile.
|
|
|
|
fab
|
2021-06-27 06:15:00
|
i have two usb 128 gb usb
|
|
|
|
Jyrki Alakuijala
|
2021-06-27 06:15:01
|
d1 FullHD image transfers in about 100 ms on average mobile, whereas a d4 image takes 25 ms on average mobile bandwidth. The additional quality matters for me so I'm willing to wait 75 ms for it.
|
|
|
|
fab
|
2021-06-27 06:15:05
|
i don't care about smartphone
|
|
|
|
Jyrki Alakuijala
|
2021-06-27 06:15:24
|
Makes sense -- there are different use cases
|
|
2021-06-27 06:15:36
|
I'd like to build a working d3
|
|
|
|
fab
|
2021-06-27 06:15:45
|
grammarly said smartphone don't exist in english, like smart isn't a word in english
|
|
|
|
Jyrki Alakuijala
|
2021-06-27 06:15:47
|
what happens if you just use jxl:d3 and nothing else
|
|
|
|
fab
|
2021-06-27 06:16:04
|
i installed grammarly now but i find it creates a bad english
|
|
2021-06-27 06:16:17
|
and the popup doesn't work in discord and facebook
|
|
2021-06-27 06:16:29
|
i couldn't find a way to make it work with windows 7
|
|
|
|
Jyrki Alakuijala
|
2021-06-27 06:16:43
|
I feel you write with more clarity than you have written sometime in the past
|
|
2021-06-27 06:17:02
|
well done
|
|
|
|
BlueSwordM
|
2021-06-27 06:17:31
|
Yeah, his English has improved a lot since the beginning of 2021.
Back in 2020 to the beginning of 2021, his grammar and writing had improved even more relatively speaking 😄
|
|
|
|
fab
|
2021-06-27 06:17:32
|
this was first post i did in italian in public
|
|
2021-06-27 06:17:34
|
https://discord.com/channels/794206087879852103/806898911091753051/858773002333978666
|
|
|
|
Jyrki Alakuijala
|
2021-06-27 06:17:39
|
I'm not good at writing English either, sometimes I write such things that the next day I'm ashamed
|
|
|
|
fab
|
2021-06-27 06:19:37
|
14 years old now write better than i did
|
|
2021-06-27 06:19:48
|
7 years ago was
|
|
|
|
Jyrki Alakuijala
|
2021-06-27 06:26:23
|
do you usually get better results using 'new heuristics'?
|
|
|
|
fab
|
2021-06-27 06:32:24
|
no
|
|
2021-06-27 06:33:26
|
only -s 9 -d 1 --use_new_heuristics with libjxl v0.3.7-169-g1f7445a win_x64 but i don't care about generation loss, and anyway i assume if the photo don't look in this way the source isn't good so i do lossless in that case
|
|
2021-06-27 06:33:58
|
that i tried with phone screenshots hyronically not 2400x1080
|
|
|
|
Jyrki Alakuijala
|
2021-06-27 07:27:33
|
next 'improvement' or change on ac strategy...
|
|
2021-06-27 07:27:40
|
before:
|
|
2021-06-27 07:28:01
|
after:
|
|
2021-06-27 07:28:10
|
d3:epf0
|
|
2021-06-27 07:31:06
|
overall not a big difference, 0.2 % or so on bpp * pnorm
|
|
2021-06-27 07:31:22
|
sometimes worse again, but looks like less often worse than better
|
|
2021-06-27 08:45:52
|
again for eager minds to try out: https://github.com/libjxl/libjxl/pull/231
|
|
2021-06-27 08:46:41
|
I believe our 16X16 DCT is slightly 'broken' by its quantization table being less effective by default than those of 16X8, 8X8s and 32X16
|
|
2021-06-27 08:47:06
|
I believe that because of it this PR is not as effective as it otherwise would be
|
|
2021-06-27 08:47:40
|
32X32 quant table is great, too
|
|
2021-06-27 08:48:04
|
I think when we repeat this experiment to larger transforms we will see more interesting results
|
|
2021-06-27 08:55:03
|
(or more interesting relative to the opportunity -- the opportunity is lower there, but function would be more correct/ideal to balance 16x32 vs 32x32, something is off in 8x16 vs. 16x16, and it is not in 8x16)
|
|
2021-06-27 08:55:33
|
(I can only blame myself, I optimized each default quantization matrix)
|
|
2021-06-27 08:56:47
|
(I will probably come up with two more quality improvements after this during the next month)
|
|
|
|
fab
|
2021-06-28 06:37:48
|
i think this should improve -d 2.8 -I 1.5 --epf=0
|
|
2021-06-28 06:38:02
|
but i have not tried
|
|
2021-06-28 06:39:19
|
scope could you send the build you tested with if you have a windows 64 version? <@!111445179587624960>
|
|
|
|
_wb_
|
|
Jyrki Alakuijala
I believe our 16X16 DCT is slightly 'broken' by its quantization table being less effective by default than those of 16X8, 8X8s and 32X16
|
|
2021-06-28 06:41:16
|
what's the signaling cost of using non-default quant tables? IIRC we have a way to signal parametrized tables that should be cheap to signal, and a way to signal arbitrary tables which uses Modular (basically here it would be a 3-channel 16x16 image with the quantization constants)
|
|
|
|
Jyrki Alakuijala
|
2021-06-28 06:50:40
|
I suspect flatter tables might be better for anime/graphics
|
|
2021-06-28 06:51:19
|
(in addition to suspecting that I didn't do the greatest ever job in defining the default 16x16 quant table for vardct)
|
|
2021-06-28 09:37:03
|
photographs (and most real-life signals) have frequency content amplitudes related to 1/f
|
|
2021-06-28 09:37:51
|
drawings with a thin black pen have a different (flatter) frequency composition
|
|
2021-06-28 09:38:06
|
intuitively flatter quantization matrices should work better -- didn't try yet
|
|
2021-06-28 10:28:45
|
I have a personal theory about how the worst quantization errors happen in DCT and I'm going to try it out, I'll add some new minimization goals and bias the quantization to reduce those, too ... let's see what happens
|
|
2021-06-28 10:29:14
|
I anticipate another ~0.1 % error reduction with 5 % reduction in rinigning 😛
|
|
|
Master Of Zen
|
2021-06-28 12:08:34
|
Highway fails on tests if you compile it with -Ofast
|
|
|
|
Jyrki Alakuijala
|
2021-06-28 12:44:14
|
you can only go -O55mph, not faster
|
|
2021-06-28 12:52:13
|
file an issue on libjxl or highway repos, or both
|
|
|
|
fab
|
2021-06-28 04:19:14
|
someone should make a web extension in firefox
|
|
2021-06-28 04:19:23
|
that use cjxl as deblocker
|
|
2021-06-28 04:19:44
|
even if the file size is always the same and the speed of loading isn't super fast
|
|
2021-06-28 04:20:26
|
do anyone in this server has the competence to write this?
|
|
|
|
retr0id
|
2021-06-28 04:21:34
|
what would the extension actually do?
|
|
2021-06-28 04:22:23
|
but that gives me an interesting idea - compile libjxl to wasm, stuff it in a webextension, and add support for jxl to current/old firefox releases
|
|
2021-06-28 04:23:10
|
the "compile to wasm" part is already a solved problem <https://github.com/libjxl/libjxl/blob/main/doc/building_wasm.md>
|
|
|
|
BlueSwordM
|
|
retr0id
but that gives me an interesting idea - compile libjxl to wasm, stuff it in a webextension, and add support for jxl to current/old firefox releases
|
|
2021-06-28 04:23:31
|
That is not a good idea for performance...
|
|
|
|
retr0id
|
2021-06-28 04:23:58
|
is it really *that* bad?
|
|
2021-06-28 04:24:24
|
wasm overhead isn't typically that big
|
|
|
|
fab
|
|
BlueSwordM
That is not a good idea for performance...
|
|
2021-06-28 04:25:33
|
25 MPX in a i3 330m with 4 threads
|
|
2021-06-28 04:25:41
|
knusperli is way slower
|
|
2021-06-28 04:25:48
|
at least x10 slower than that
|
|
2021-06-28 04:25:55
|
to do realtime
|
|
|
|
retr0id
|
|
fab
that use cjxl as deblocker
|
|
2021-06-28 04:26:05
|
what do you mean by this though
|
|
|
|
fab
|
2021-06-28 04:26:06
|
i do not know if knusperli is done realtime or encoding
|
|
|
|
BlueSwordM
|
|
retr0id
is it really *that* bad?
|
|
2021-06-28 04:26:27
|
Yes. Try out any encoder in current wasm and you'll just see performance drop hard vs the normal program.
|
|
|
|
fab
|
2021-06-28 04:26:36
|
https://discord.com/channels/794206087879852103/840831132009365514/859094618666958868
|
|
2021-06-28 04:27:10
|
if you want blurred images you just use webp
|
|
2021-06-28 04:27:16
|
jxl d 1 is good
|
|
2021-06-28 04:27:24
|
on visually lossless
|
|
|
|
retr0id
|
|
BlueSwordM
Yes. Try out any encoder in current wasm and you'll just see performance drop hard vs the normal program.
|
|
2021-06-28 04:27:31
|
well, media encoders are typically SIMD-accelerated, etc., and I don't think that level of optimisation has been applied to libjxl yet (I might be wrong though?), so I'm not sure it'd be that much differece
|
|
|
|
fab
|
2021-06-28 04:27:42
|
but a deblocked image look better
|
|
2021-06-28 04:27:47
|
at least to me
|
|
|
|
BlueSwordM
|
|
retr0id
well, media encoders are typically SIMD-accelerated, etc., and I don't think that level of optimisation has been applied to libjxl yet (I might be wrong though?), so I'm not sure it'd be that much differece
|
|
2021-06-28 04:27:49
|
Uh, cjxl and djxl have a massive amount of SIMD though.
|
|
|
|
_wb_
|
|
retr0id
well, media encoders are typically SIMD-accelerated, etc., and I don't think that level of optimisation has been applied to libjxl yet (I might be wrong though?), so I'm not sure it'd be that much differece
|
|
2021-06-28 04:27:51
|
you are wrong 🙂
|
|
|
|
retr0id
|
2021-06-28 04:28:02
|
ah, fair enough 🙂
|
|
|
|
fab
|
2021-06-28 04:28:06
|
i do not like d 2 jpeg xl
|
|
|
|
retr0id
|
2021-06-28 04:28:09
|
well, at least wasm has SIMD support now
|
|
|
|
_wb_
|
2021-06-28 04:28:14
|
yes
|
|
2021-06-28 04:28:32
|
wasm with SIMD is not _that_ much slower than native
|
|
2021-06-28 04:28:39
|
still 3x or so maybe
|
|
|
|
fab
|
2021-06-28 04:28:46
|
i have no intention to download pngs or do -d 2.8 -I 1.5 --epf=0
|
|
2021-06-28 04:28:56
|
or d 3 epf 0 as jyrki did
|
|
2021-06-28 04:28:59
|
or normal d 3
|
|
|
|
_wb_
|
2021-06-28 04:29:20
|
main problem with wasm is it won't really work on first load, iirc
|
|
2021-06-28 04:29:32
|
if you want to use service workers
|
|
|
|
fab
|
2021-06-28 04:29:58
|
use microsoft webview
|
|
|
|
retr0id
|
|
_wb_
if you want to use service workers
|
|
2021-06-28 04:33:16
|
is that some kinda security feature, where it requires some level of user interaction before it can be done?
|
|
|
|
improver
|
2021-06-28 04:34:41
|
no it's like having threads
|
|
|
|
retr0id
|
2021-06-28 04:35:00
|
no, I mean the "won't really work on first load" limitation
|
|
|
|
improver
|
2021-06-28 04:35:17
|
oh. yeah i wonder why
|
|
2021-06-28 04:35:26
|
im not really much into webdev
|
|
|
|
retr0id
|
2021-06-28 04:36:45
|
I did some stuff with web workers (js, not wasm) a while back, and I don't remember any issues. But that was before webworkers were being used for crypto mining, or to perform microarchitectural sidechannel attacks...
|
|
|
|
fab
|
2021-06-28 04:41:06
|
knusperli has 500 kb jpeg at least
|
|
2021-06-28 04:41:30
|
i don't know if it can avoid encoding to jpg or to png
|
|
2021-06-28 04:41:46
|
but i think is like an encoder
|
|
2021-06-28 04:42:11
|
that the person who invented knusperli know better
|
|
|
|
Master Of Zen
|
|
Jyrki Alakuijala
file an issue on libjxl or highway repos, or both
|
|
2021-06-28 04:51:39
|
highway self test
|
|
|
|
fab
|
2021-06-28 04:55:22
|
benchmark on many instagram images 209 MB (219.650.693 byte) vs 194 MB (203.706.505 byte)
|
|
2021-06-28 04:55:28
|
so 14 mb difference
|
|
2021-06-28 04:55:42
|
only 6% reduction in this way
|
|
2021-06-28 04:55:50
|
but quality is better than original
|
|
2021-06-28 04:56:30
|
some files probably are bigger i didn't checked
|
|
2021-06-28 04:58:19
|
there is evident ringing in the encoded images
|
|
|
|
Deleted User
|
2021-06-28 05:52:47
|
Is it possible to combine layers of different bit depth in one JXL? Like R5G6B5 or R10G10B10A2. Or wouldn't this have any performance/size impact anyway?
|
|
|
|
_wb_
|
|
Is it possible to combine layers of different bit depth in one JXL? Like R5G6B5 or R10G10B10A2. Or wouldn't this have any performance/size impact anyway?
|
|
2021-06-28 06:24:49
|
No, bitdepth is a per-image thing, not per-layer.
|
|
2021-06-28 06:25:18
|
In XYB it doesn't make a difference though
|
|
2021-06-28 06:26:14
|
And in Modular you can take the highest bitdepth as the image bitdepth and then use channel palette to have an effectively lower bitdepth in some layers
|
|
2021-06-28 06:26:27
|
Doesn't need to be an integer bitdepth either then
|
|
2021-06-28 06:27:07
|
(as in, the number of shades doesn't need to be a power of two)
|
|
|
|
Jyrki Alakuijala
|
|
fab
that the person who invented knusperli know better
|
|
2021-06-28 09:02:38
|
I invented knusperli and can talk about its design if you like. Ruud implemented it, pruned down the concept to be easier to be made streamable, and made additional design decisions about it.
|
|
2021-06-28 09:34:34
|
(Eugene has further improved the concept for DC dequantization, not implemented in knusperli, but in some version of brunsli-related code)
|
|
|
|
Deleted User
|
2021-06-29 12:25:01
|
you invented quite much <:BlobYay:806132268186861619>
|
|
|
|
Jyrki Alakuijala
|
2021-06-29 12:26:48
|
I was a random idea generator with lots of smart people around me 😄
|
|
|
|
Deleted User
|
|
|
Jyrki Alakuijala
|
2021-06-29 12:27:57
|
is someone using VarDCT with cheetah or falcon speeds (or faster)?
|
|
2021-06-29 01:02:15
|
something looks to be wrong or inefficient with cheetah speed (https://github.com/libjxl/libjxl/pull/240)
|
|
|
|
fab
|
2021-06-29 05:55:22
|
how use butteruagli
|
|
2021-06-29 05:55:38
|
https://discord.com/channels/794206087879852103/840831132009365514/859476503275634728
|
|
2021-06-29 05:56:06
|
like i want to know if that image is advisable to encode at -d 0.901 -s 9
|
|
2021-06-29 07:39:07
|
|
|
|
sivertba
|
2021-06-30 10:47:22
|
Hi! Does JPEG XL support multi component transforms the way that JPEG2000 does?
|
|
|
|
_wb_
|
2021-06-30 10:49:04
|
Not in the same way, I think
|
|
2021-06-30 10:49:14
|
Not sure what exactly j2k has there
|
|
2021-06-30 10:50:12
|
We have custom XYB matrices and for lossless YCoCg and a series of other reversible color transforms
|
|
2021-06-30 10:51:00
|
There's also chroma from luma that can be used as local color transforms
|
|
|
|
fab
|
2021-07-01 11:29:16
|
do you have https://github.com/libjxl/libjxl/commit/653358dfff0342d0907d4a76653d23b3829d0836
|
|
|
Petr
|
2021-07-01 12:03:51
|
<@!794205442175402004>, is it still true that the spec has less than 100 pages? https://docs.google.com/presentation/d/1LlmUR0Uoh4dgT3DjanLjhlXrk_5W2nJBDqDAMbhe8v8/edit#slide=id.g821b9c186b_0_34
|
|
|
|
_wb_
|
2021-07-01 12:11:24
|
Informative Annex M (encoder) is not really part of the spec, it's just to help implementing an encoder but specs only specify what a decoder does
|
|
2021-07-01 12:11:43
|
that Annex starts on page 98
|
|
2021-07-01 12:11:54
|
so the decoder spec is 97 pages
|
|
2021-07-01 12:15:09
|
also the first 10 or so pages are notational conventions and high-level overviews and stuff, the actual real spec starts with Annex A on page 15
|
|
2021-07-01 12:15:29
|
so yes, it's really less than 100 pages
|
|
2021-07-01 12:15:55
|
it might be denser than other specs though, I dunno
|
|
|
|
Petr
|
2021-07-01 12:17:13
|
Tnx, <@456226577798135808> and <@!794205442175402004>. The page count measure is vague anyway because of the information density, yes…
|
|
|
|
_wb_
|
2021-07-01 12:17:59
|
it gives a rough ballpark indication, something like lines of code of a decoder implementation
|
|
2021-07-01 12:20:13
|
lines of code is not very reliable - things like speed optimizations using specialized code paths for common special cases and platform-dependent stuff like hand-written asm can make things look more complicated than they are, and dense coding styles can make things look simpler than they are
|
|
2021-07-01 12:21:06
|
spec page count is perhaps more reliable because there's only so much you can do to fit more stuff on a page
|
|
2021-07-01 02:29:54
|
No, but I don't imagine they would use wildly different font sizes or margins and end up being significantly different. But of course there can be differences in things like notes and examples (not strictly necessary) and how verbose the language is.
|
|
|
|
Jyrki Alakuijala
|
2021-07-01 03:17:00
|
a miniature ringing optimization just merged: https://github.com/libjxl/libjxl/pull/262
|
|
2021-07-01 03:31:11
|
we need 700 such optimizations to remove ringing altogether 😛
|
|
|
monad
|
2021-07-01 03:33:02
|
At least it's countable.
|
|
|
|
Jyrki Alakuijala
|
2021-07-01 04:23:46
|
my approach now is to reduce the surface area of ringing, and eventually then look into throwing more bits at the remaining smaller area
|
|
2021-07-01 04:24:40
|
it feels like it might work out pretty well
|
|
|
|
cmov
|
2021-07-03 01:34:22
|
Is it possible to configure djxl to dump headers and frameheaders ?
|
|
|
|
_wb_
|
2021-07-03 01:44:34
|
you need to recompile for that
|
|
2021-07-03 01:45:30
|
https://github.com/libjxl/libjxl/blob/main/lib/jxl/fields.h#L189
|
|
2021-07-03 01:45:49
|
change that line to make it return true
|
|
|
|
cmov
|
2021-07-03 01:50:28
|
Thanks !
|
|
|
|
Jyrki Alakuijala
|
2021-07-03 03:08:25
|
next ringing reduction attempt is coming
|
|
2021-07-03 03:08:37
|
here at ridiculous d32:epf3
|
|
2021-07-03 03:08:43
|
before
|
|
2021-07-03 03:09:30
|
before
|
|
2021-07-03 03:10:03
|
after
|
|
2021-07-03 03:10:47
|
it is less impressive at normal distances, but there is a small improvement there too, plus a general fidelity improvement
|
|
2021-07-03 03:10:56
|
of course all of these are subtle things...
|
|
|
|
fab
|
2021-07-03 03:11:43
|
this amazing
|
|
|
|
Jyrki Alakuijala
|
2021-07-03 03:12:03
|
here d4:epf3
|
|
2021-07-03 03:12:17
|
before
|
|
|
|
fab
|
2021-07-03 03:13:15
|
not my style of drawin
|
|
2021-07-03 03:13:29
|
but good
|
|
2021-07-03 03:13:53
|
image looks different
|
|
|
|
Jyrki Alakuijala
|
2021-07-03 03:14:14
|
after:
|
|
2021-07-03 03:14:41
|
(there was some latency in discord so I first posted before twice)
|
|
2021-07-03 03:15:26
|
the nice thing is that this is not an improvement where there is a huge compromise photos vs. drawings, but photos improve more than drawings 🙂
|
|
|
|
fab
|
2021-07-03 03:15:55
|
probably i won't care about something better than
|
|
2021-07-03 03:15:56
|
for %i in (C:\Users\User\Documents\imf4*.png) do cjxl -d 4.38 -s 4 --use_new_heuristics --faster_decoding=1 -I 1.4
%i %i.jxl
|
|
2021-07-03 03:16:04
|
and libjxl v0.3.7-202-gc8b0bf3 win_x64 2021.07.03
|
|
2021-07-03 03:16:20
|
but i see the improvement
|
|
|
|
Jyrki Alakuijala
|
2021-07-03 03:16:36
|
complex textures get more fidelity, as there is some root-mean-square-minimization guidance for integral transforms instead of the previous L1 optimization
|
|
|
|
fab
|
2021-07-03 03:16:38
|
totally different
|
|
|
|
Jyrki Alakuijala
|
2021-07-03 03:16:51
|
rms fits dct's average errors better, but L1 is more for optimizing the worst case
|
|
2021-07-03 03:17:07
|
now I go for a balance between the two instead of L1 in before
|
|
2021-07-03 03:17:48
|
again, it is not a definite answer to solving ringing, but it is another 1 % of the solution, 99 more steps needed 🙂
|
|
2021-07-03 03:24:23
|
dct is a rotation, so Euclidian (rms/L2) thinking works through a rotation better than L1
|
|
2021-07-03 03:25:21
|
if someone wants to try, it is in https://github.com/libjxl/libjxl/pull/273
|
|
|
|
diskorduser
|
|
fab
for %i in (C:\Users\User\Documents\imf4*.png) do cjxl -d 4.38 -s 4 --use_new_heuristics --faster_decoding=1 -I 1.4
%i %i.jxl
|
|
2021-07-03 03:28:04
|
Is it required to use "new heuristics" to enable this improvements?
|
|
|
|
fab
|
|
diskorduser
Is it required to use "new heuristics" to enable this improvements?
|
|
2021-07-03 03:31:52
|
no
|
|
2021-07-03 03:32:17
|
this options with a different encoder probably will produce the worst image in the world
|
|
2021-07-03 03:32:45
|
although you can try with same encoder less distance or more distance but probably won't produce more fidelity
|
|
|
|
improver
|
|
diskorduser
Is it required to use "new heuristics" to enable this improvements?
|
|
2021-07-03 04:29:06
|
"new heuristics" is something what is incomplete and was recommended against but you kno fabian
|
|
|
|
fab
|
|
improver
"new heuristics" is something what is incomplete and was recommended against but you kno fabian
|
|
2021-07-03 04:30:58
|
for screenshot i think maybe i will rewatch the screenshots and delete them. but for photo and not complicated texture with that option it looks good as avif
|
|
2021-07-03 04:31:09
|
-I 1.4 really add blur and sharpening
|
|
2021-07-03 04:31:31
|
though i won't change distance
|
|
2021-07-03 04:32:15
|
Lee isn't commenting
|
|
2021-07-03 04:32:52
|
i think because they are low bitrate improvements that you can't even notice without going to high -I and he isn't interested
|
|
|
|
Jyrki Alakuijala
|
2021-07-03 04:40:47
|
I don't use optimize (or try to improve) new heuristics yet
|
|
2021-07-03 04:41:08
|
new heuristics is more a way to calculate things once instead of calculating similar things many times in a bit different way
|
|
2021-07-03 04:41:21
|
'new heuristics' approach can be made faster eventually
|
|
|
|
raysar
|
|
Jyrki Alakuijala
if someone wants to try, it is in https://github.com/libjxl/libjxl/pull/273
|
|
2021-07-03 04:41:29
|
Yes ! 😍
|
|
|
|
Jyrki Alakuijala
|
2021-07-03 04:41:50
|
faster means better quality, too, because some of the speed gain can be changed to more computation, leading to better quality
|
|
2021-07-03 04:42:45
|
good news: the PR 273 is merged, so testing is possible from the head
|
|
2021-07-03 04:43:03
|
of course I don't make changes unless I'm convinced that it is not harmful
|
|
2021-07-03 04:43:26
|
but I always appreciate feedback on the quality changes -- I don't have the same focus in material that people here have
|
|
2021-07-03 04:44:01
|
I get huge help for prioritizing on what to do next from seeing the material that people use and the remaining artefacts with it
|
|
2021-07-03 04:45:14
|
for making PR 273 I tried at least 15 different approaches, which were far better in butteraugli sense (one was about 1 %) better, but they were not better in the ringing sense
|
|
2021-07-03 04:45:29
|
in between I use 'nelder mead' optimization to find the best solution from each heuristic
|
|
2021-07-03 04:45:53
|
then I tune the results to have roughly the same balance of integral transform statistics
|
|
2021-07-03 04:46:09
|
... and then stare the results before and after at different filterings and distances
|
|
|
fab
for screenshot i think maybe i will rewatch the screenshots and delete them. but for photo and not complicated texture with that option it looks good as avif
|
|
2021-07-03 05:04:49
|
it is nowhere near as good as AVIF in the low quality or graphics (without textures), but it is likely reducing the gap
|
|
2021-07-03 05:13:46
|
next up, I'll reflect the more optimal heuristic for selecting 16x8 vs 8x16 vs 16x16 to 32x16, 16x32, vs 32x32 -- this should help a lot (2-3 %) for the d8+, but be a ~0.1 % change in the high quality
|
|
2021-07-03 05:14:02
|
if things are behaving logically, it should be another strictly better in all dimensions change
|
|
|
|
lithium
|
|
Jyrki Alakuijala
if things are behaving logically, it should be another strictly better in all dimensions change
|
|
2021-07-03 05:40:34
|
Thank you for your work 🙂
A little curious, all dimensions change this means next improve will have more affect in cjxl d0.5~1.0 quality?
|
|
|
|
Jyrki Alakuijala
|
2021-07-03 05:47:49
|
the 273 improves d0.5 to d1.0 range (and elsewhere, too, like the d32 shown in this chat)
|
|
2021-07-03 05:48:03
|
significantly
|
|
2021-07-03 05:48:06
|
next improvement will likely be very very small in that range
|
|
2021-07-03 05:48:24
|
I still see some problems with blue colors and ringing, possibly also with red
|
|
2021-07-03 05:48:44
|
but things are improving across the board
|
|
|
|
improver
|
2021-07-03 05:49:52
|
I did some testing in <#803645746661425173> for 273, and yes it's better
|
|
|
|
Jyrki Alakuijala
|
2021-07-03 05:50:08
|
thank you!!
|
|
|
|
lithium
|
|
Jyrki Alakuijala
I still see some problems with blue colors and ringing, possibly also with red
|
|
2021-07-03 05:50:16
|
I understand, Thank you very much 🙂
|
|
|
|
Jyrki Alakuijala
|
2021-07-03 05:50:30
|
neknekk, that lets me sleep well tonight
|
|
2021-07-03 05:51:05
|
Lee, thank you for keeping the focus on the uncompromised quality -- your feedback is very highly motivating for me, even when it took several months for me to act on it
|
|
2021-07-03 05:52:13
|
we just needed to go into the productionizing/security/integration/hdr/... mode to get jpeg xl into Chrome, and downprioritize quality
|
|
2021-07-03 05:52:23
|
now it is time for some quality again... 🙂
|
|
|
|
improver
|
2021-07-03 05:53:25
|
isn't hdr already done for chrome?
|
|
2021-07-03 05:53:39
|
oh that's done yeah
|
|
2021-07-03 05:53:40
|
misread
|
|
2021-07-03 05:54:13
|
kinda curious when progressive loading will happen (or it did and i didn't notice?)
|
|
|
|
Cool Doggo
|
2021-07-03 07:18:38
|
<:what:683451746789490710>
|
|
2021-07-03 07:19:23
|
what does the -l mean
|
|
|
|
fab
|
2021-07-03 07:28:46
|
i think use -d 3.805 -s 7
|
|
2021-07-03 07:28:53
|
with this new encoder
|
|
2021-07-03 07:29:07
|
parameters are getting simpler every encoder
|
|
2021-07-03 07:31:10
|
i have not tried yet
|
|
|
|
diskorduser
|
2021-07-03 07:32:27
|
-I F, --iterations=F
[modular encoding] fraction of pixels used to learn MA trees (default=0.5, try 0 for no MA and fast decode)
|
|
|
|
fab
|
2021-07-03 07:34:21
|
-q 70.461 -s 9 --epf=2 -I 0.991 -p --use_new_heuristics
|
|
2021-07-03 07:34:59
|
|
|
2021-07-03 07:35:16
|
encode using those two options and post here
|
|
2021-07-03 07:35:35
|
tell bpp file sizes all
|
|
2021-07-03 07:36:48
|
i would do target 52105
|
|
2021-07-03 07:37:06
|
try also with that
|
|
2021-07-03 07:40:46
|
or try
|
|
2021-07-03 07:40:46
|
-q 55.761 -s 9 --epf=2 -I 0.5 -p --use_new_heuristics --faster_decoding=2
|
|
2021-07-03 07:41:02
|
try to compress
|
|
|
|
diskorduser
|
2021-07-03 07:41:50
|
<:NotLikeThis:805132742819053610>
|
|
2021-07-03 07:44:22
|
Why are you using -I 0.5 when it's already a default value.
|
|
2021-07-03 07:45:33
|
TF
|
|
|
|
fab
|
2021-07-03 07:57:00
|
https://discord.com/channels/794206087879852103/794206170445119489/860968333029539841 click on right click and do spelling
|
|
2021-07-03 07:59:02
|
-I 0.505 -s 6 --faster_decoding=4 --epf=1 -q 78
|
|
2021-07-03 07:59:22
|
i won't do any of these
|
|
2021-07-03 08:01:09
|
-I 0.718 -q 71.75 -s 9 --use_new_heuristics --faster_decoding=3
|
|
2021-07-03 08:02:51
|
i'm not doing deblocking to images
|
|
2021-07-03 08:02:59
|
this is just like webdev website did
|
|
2021-07-03 08:04:46
|
.....
|
|
2021-07-03 08:05:01
|
what about doing -q 57.817 -s 6 --epf=3
|
|
2021-07-03 08:05:08
|
what you think?
|
|
2021-07-03 08:06:41
|
before i did -d 4.38 so about -q 52.5
|
|
2021-07-03 08:06:46
|
https://docs.google.com/spreadsheets/d/1bTeraUXIl-nGM8c53IdURxmJbabX9eXqPZwVSynoH9U/edit#gid=196105105
|
|
2021-07-03 08:09:06
|
ok now
|
|
2021-07-03 08:18:42
|
-q 77.617 -s 8 -I 0.782 --use_new_heuristics
|
|
2021-07-03 08:20:29
|
-q 86.561 -s 7
|
|
|
|
Jyrki Alakuijala
|
|
improver
isn't hdr already done for chrome?
|
|
2021-07-03 09:17:53
|
yes, in theory everything is ready -- but then there is one android manufacturer whose phone has different hdr behaviour than others and weird banding emerges, etc.
|
|
2021-07-03 09:18:02
|
real life engineering is not mathematics
|
|
|
|
improver
|
2021-07-03 09:21:21
|
well, yeah, I wasn't thinking, when it's "done" it's only base feature in evaluation mode and will very probably need more touchups for specific cases like these. engineering processes...
|
|
2021-07-03 09:22:41
|
I just meant in a sense of main thing being already done and main focus being able to directed somewhere else, while evaluation can be done by other people
|
|
|
|
raysar
|
2021-07-03 11:56:07
|
The last windows binary: commit d10abdcc with new visual update from <@!532010383041363969> 😍
https://1drv.ms/u/s!Aui4LBt66-MmkRYe_rNcBCy2LKX0?e=Xb5XtV
|
|
|
|
fab
|
2021-07-04 06:37:43
|
i'm trying for %i in (C:\Users\User\Documents\imf5\*.png) do cjxl -q 97.6 -I 0.468 --faster_decoding=4 --epf=1 -p -s 7 --use_new_heuristics %i %i.jxl
|
|
2021-07-04 06:38:05
|
the highest settings for jxl, at this setting i see no artifacts
|
|
2021-07-04 06:44:22
|
The real settings are
|
|
2021-07-04 06:44:23
|
for %i in (C:\Users\User\Documents\imf5\*.png) do cjxl -q 97.6 --epf=1 --faster_decoding=4 -p -s 7 --use_new_heuristics %i %i.jxl
|
|
2021-07-04 06:44:34
|
faster decoding 4 works and highly reduce file size
|
|
2021-07-04 06:44:38
|
in this case
|
|
2021-07-04 06:45:00
|
-I 0.468 don't work so it probably use -I 0.5
|
|
2021-07-04 06:46:52
|
|
|
2021-07-04 06:47:12
|
The image look good
|
|
2021-07-04 06:55:27
|
libjxl v0.3.7-204-gd10abdc win_x64 2021.07.04
|
|
|
|
Jyrki Alakuijala
|
2021-07-04 08:25:09
|
I'll get the next improvement ready today I believe
|
|
2021-07-04 08:25:31
|
it will make d8+ better, possibly a marginal improvement in high quality, too
|
|
2021-07-04 08:25:41
|
don't have any results yet, but the code compiles :------D
|
|
|
|
fab
|
2021-07-04 09:33:09
|
-q 88.321 -s 8 -epf=1 --gaborish=0 --dots=1 ---patches=1 --noise=1
|
|
2021-07-04 09:36:18
|
for %i in (C:\Users\User\Documents\imf5\*.png) do cjxl -q 88.321 -s 8 --epf=1 --gaborish=0 --dots=1 --patches=1 --noise=1 %i %i.jxl
|
|
2021-07-04 09:36:23
|
libjxl v0.3.7-204-gd10abdc win_x64 2021.07.04
|
|
2021-07-04 09:36:38
|
290 vs 132 kb
|
|
2021-07-04 09:38:02
|
|
|
2021-07-04 09:38:46
|
|
|
2021-07-04 09:38:51
|
|
|
|
|
Jyrki Alakuijala
|
2021-07-04 11:13:37
|
improved dct16x32, 32x16, 32x32 balancing gives a nice improvement at very high distances
|
|
2021-07-04 11:13:53
|
before:
|
|
2021-07-04 11:14:09
|
after:
|
|
2021-07-04 11:14:43
|
of course it is a bit irrelevant because neither is usable for anything 😄
|
|
2021-07-04 11:22:08
|
it looks like it works well with photographs, too, reduces ringing and improves contrast, but easier to see at d16 and higher
|
|
2021-07-04 11:22:21
|
there is improvement all the way down to distance 0.8, but it gets really subtle -- only very few areas are changed, and often in boring areas that already great (like the sky)
|
|
2021-07-04 11:23:57
|
once I get this algorithmic improvement merged, then there is naturally room for the next round of tuning the parameters, often it gives 25 % more than the algorithmic improvement alone
|
|
2021-07-04 11:27:19
|
Jon and Luca know it best
|
|
2021-07-04 11:27:52
|
I know about some plans, particularly those related to delta palettization and how context modeling/lz77 can support the delta palettization
|
|
2021-07-04 11:28:09
|
I'm quite excited about the potential of delta palettization (unlike everyone else on the planet)
|
|
2021-07-04 11:30:20
|
JXL lossless has its roots in FUIF, with Luca redesigning the context modeling so that it can be decoded faster
|
|
2021-07-04 11:31:12
|
in cwebp I calculate the colors, if less than 256, palette will be considered
|
|
2021-07-04 11:31:44
|
there, I don't encode all images all the way to the end, but I use a function called 'AnalyzeEntropy' that buckets a few candidate entropies
|
|
2021-07-04 11:32:18
|
then it decides the coding based on different combinations of the candidate entropies, and coding happens only once
|
|