|
fab
|
2022-02-16 03:05:54
|
|
|
2022-02-16 03:05:58
|
i'm destoying libjxl site
|
|
2022-02-16 03:13:49
|
https://github.com/libjxl/actions/runs/5217593854
|
|
2022-02-16 03:15:14
|
https://github.com/libjxl/libjxl/runs/5217593854
|
|
2022-02-16 03:21:09
|
how to find this
|
|
2022-02-16 03:21:10
|
When I want to download an artifact I use the following kind of URL: https://github.com/some_user/some_repo/suites/some_id/artifacts/some_id. This however always leads me to a .zip package even if the result is just a single file. In my case this additional layer is totally redundant and I'd like to skip it (it's especially annoying when I build a pdf that I want to be able to preview conveniently).
(How) can I setup the automated workflow to expose unpacked files?
|
|
2022-02-16 04:49:42
|
https://mega.nz/file/bUk02DQb#_YSa3JOZZGDdAVsAYmAPKiTtXSHC9Ntb1tkPcP4agAI
|
|
2022-02-16 04:50:02
|
45 images to test cjxl
|
|
2022-02-16 04:50:10
|
Already cutted ans also enamed
|
|
2022-02-16 04:50:35
|
and you can test also those thumbnails
|
|
2022-02-16 04:50:36
|
https://discord.com/channels/794206087879852103/794206170445119489/943498853074743306
|
|
2022-02-23 08:16:49
|
To me s 8 d 0.619 use new heuristics
|
|
2022-02-23 08:17:07
|
With new jyrki red greenness preservation
|
|
2022-02-23 08:17:12
|
Should be good
|
|
2022-02-23 08:17:21
|
And transparent
|
|
2022-02-23 08:18:06
|
JPEG XL is already at good stage and has good tradeoff
|
|
2022-02-25 10:10:42
|
how to do
|
|
2022-02-25 10:10:44
|
for %i in (C:\Users\Use\Videos\a\*.png) do cjxl -s 7 -d 0.319 --use_new_heuristics %i %i.jxl
|
|
2022-02-25 10:11:05
|
new heuistics crashes on my computee since a week
|
|
2022-02-25 10:11:10
|
and i have formatted
|
|
|
diskorduser
|
2022-02-25 02:58:15
|
Then don't use new heuristics.
|
|
|
Fox Wizard
|
2022-02-25 03:12:37
|
<:KekDog:884736660376535040>
|
|
|
_wb_
|
2022-02-25 03:51:58
|
Experimental stuff is meant for experimentation
|
|
|
|
fab
|
2022-02-25 04:28:28
|
|
|
2022-02-25 04:28:43
|
This i like
|
|
2022-02-25 04:28:48
|
Very good
|
|
2022-02-27 03:18:47
|
|
|
2022-02-27 03:18:56
|
how to solve that poblem
|
|
|
|
diskorduser
|
2022-02-27 04:40:20
|
By using cjxl
|
|
|
|
fab
|
2022-03-03 09:12:36
|
How to drag a photo on chApey demo
|
|
2022-03-03 09:12:43
|
Could you make a video
|
|
|
|
diskorduser
|
|
fab
How to drag a photo on chApey demo
|
|
2022-03-05 06:00:36
|
Is it related to jxl?
|
|
|
|
fab
|
2022-03-05 06:20:51
|
Yes
|
|
2022-03-05 06:22:03
|
https://chafey.github.io/libjxl-js/test/browser/index.html
|
|
2022-03-05 06:22:15
|
I want to encode one of my images
|
|
2022-03-05 06:23:25
|
How to inspect element?
|
|
|
|
chafey
|
2022-03-07 05:32:02
|
that app only works with images that are already encoded in jpeg-xl, it doesn't support transcoding from another format if that is what you are trying to do
|
|
|
|
_wb_
|
2022-03-09 08:17:43
|
<@!604964375924834314> does this spec update correspond to what it should be?
|
|
|
spider-mario
|
|
_wb_
<@!604964375924834314> does this spec update correspond to what it should be?
|
|
2022-03-09 08:27:43
|
both frame indices start from 1
|
|
2022-03-09 08:27:54
|
other than that, it looks correct to me
|
|
2022-03-09 08:28:11
|
<@!179701849576833024>, to you too?
|
|
|
|
_wb_
|
2022-03-09 08:29:44
|
ah right, it does ++idx
|
|
2022-03-09 08:30:02
|
oh and the invis idx gets reset at every vis frame, I should add that
|
|
2022-03-09 08:30:56
|
wait
|
|
2022-03-09 08:31:16
|
doesn't this mean the invis idx starts from 2 after a vis frame?
|
|
2022-03-09 08:32:54
|
why do we even need to distinguish visible and invisible frames?
|
|
2022-03-09 08:33:30
|
can't we just have a single frame_idx that just gets incremented at every frame? that's a lot easier to describe in the spec
|
|
2022-03-09 08:35:19
|
because this is a bit messy, currently the vis idx starts at 0 if you have invis frames before vis frames, etc
|
|
2022-03-09 08:35:47
|
as long as the seed is different for every frame, it should be fine, no?
|
|
|
|
spider-mario
|
2022-03-09 08:42:45
|
one concern was stability w.r.t. using or not using a patch frame
|
|
2022-03-09 08:42:57
|
for subsequent visible frames
|
|
|
|
_wb_
|
2022-03-09 08:43:32
|
Or LF frame for that matter, I see
|
|
2022-03-09 08:43:55
|
Makes sense, but as it is now, the counting is weird
|
|
2022-03-09 08:45:01
|
If you have invis invis vis vis invis vis, the counts will be
0,1
0,2
1,1
2,2
2,3
3,1
|
|
2022-03-09 08:45:40
|
Which is not something I can elegantly describe in words
|
|
|
|
veluca
|
2022-03-09 08:49:40
|
Well, with a single frame count, then seeking won't work with the frame index box
|
|
2022-03-09 08:49:56
|
(because it doesn't know about invisible frames)
|
|
|
|
_wb_
|
2022-03-09 08:50:15
|
Right, that's a very good reason to have two counters
|
|
2022-03-09 08:51:42
|
But can we reset invis_idx to 0 instead of 1? That seems to make more sense to me
|
|
|
|
veluca
|
2022-03-09 08:52:01
|
<@604964375924834314>
|
|
2022-03-09 08:52:08
|
I have no preference myself :P
|
|
|
|
_wb_
|
2022-03-09 08:52:47
|
Then seeking with frame index box can just init both to zero
|
|
|
|
spider-mario
|
2022-03-09 08:53:02
|
shouldnโt it go from (1, 1) to (2, 1)?
|
|
2022-03-09 08:53:08
|
rather than (2, 2)
|
|
|
|
_wb_
|
2022-03-09 08:53:26
|
Otherwise it has to init invis_idx to 1 for the frames after the first visible frame
|
|
2022-03-09 08:54:23
|
No because invis_idx is 1 after the first vis frame, and then gets ++'ed at the next invis
|
|
2022-03-09 08:55:33
|
Also: what if the frame index box doesn't contain all visible frames?
|
|
2022-03-09 08:56:01
|
Ah you still know the visible frame index from the box, so no issue there
|
|
|
|
spider-mario
|
|
_wb_
No because invis_idx is 1 after the first vis frame, and then gets ++'ed at the next invis
|
|
2022-03-09 08:58:33
|
not sure I follow, the `vis` frame that increments `vis_idx` from 1 to 2 should also reset `invis_idx` to 1
|
|
2022-03-09 08:58:38
|
or am I missing something?
|
|
2022-03-09 08:59:46
|
```
0,1 invis (++invis_idx)
0,2 invis (++invis_idx)
1,1 vis (++vis_idx, invis_idx = 1)
2,1 vis (++vis_idx, invis_idx = 1)
2,2 invis (++invis_idx)
3,1 vis (++vis_idx, invis_idx = 1)
```
|
|
|
|
_wb_
|
2022-03-09 09:01:28
|
Yes, so invis_idx starts from 1 in the beginning but then starts from 2 after the first vis frame
|
|
|
|
spider-mario
|
2022-03-09 09:01:49
|
ah, I see what you mean
|
|
2022-03-09 09:02:16
|
maybe we could instead init invis_idx to 1 instead of 0?
|
|
2022-03-09 09:02:22
|
so that the first one is 0,2 instead of 0,1
|
|
|
|
_wb_
|
2022-03-09 09:02:32
|
I would prefer if it was
0,1
0,2
1,0
2,0
2,1
3,0
|
|
2022-03-09 09:02:39
|
That or init both to 1
|
|
2022-03-09 09:03:48
|
Or do the ++ _after_ adding the noise
|
|
2022-03-09 09:09:25
|
No, doing ++ afterwards would make it
0,0
0,1
0,0
1,0
2,0
2,0
which is probably not what we want
|
|
2022-03-09 09:12:47
|
if we just reset invis_idx to 0 at a vis frame, then we can put it in the spec as:
vis_idx is the number of visible frames encountered so far (including the current frame, if it is visible)
invis_idx is the number of invisible frames encountered since the last visible frame (including the current frame, if it is invisible)
|
|
2022-03-09 09:20:26
|
|
|
2022-03-09 09:21:14
|
does that make sense?
|
|
2022-03-09 09:21:58
|
i'm sorry if this means the conformance images need to be generated again ๐
|
|
|
|
spider-mario
|
2022-03-09 10:20:16
|
I think I like it, thanks
|
|
2022-03-09 10:20:46
|
Iโll take a bit of time to digest it and assimilate it more fully and then make the change
|
|
2022-03-09 11:34:29
|
also, it could be a good idea to reflect https://github.com/libjxl/libjxl/pull/942 in the specification too
|
|
2022-03-09 11:34:50
|
my interpretation of the first edition is that it was somewhat ambiguous in this regard, allowing us to resolve the ambiguity in this direction
|
|
2022-03-09 11:35:00
|
but so we should probably now make it clear that this is how we resolved it
|
|
|
|
_wb_
|
2022-03-09 02:03:54
|
Feel free to make a spec pull request to clarify this stuff, I agree that the first edition is not clear enough
|
|
|
|
spider-mario
|
2022-03-09 03:07:30
|
(do I have access to the spec repo?)
|
|
|
|
_wb_
|
2022-03-09 03:30:05
|
You do now
|
|
|
|
spider-mario
|
2022-03-09 03:50:02
|
indeed, thanks
|
|
2022-03-09 03:50:16
|
```
# apt install latexm{k,l}
```
|
|
|
Jyrki Alakuijala
|
2022-03-09 04:24:44
|
there is a small quality affecting PR again, https://github.com/libjxl/libjxl/pull/1218
|
|
2022-03-09 04:25:04
|
this an previous -- if there is any guidance on them, I'd be glad and get courage to make more of them
|
|
2022-03-09 04:25:36
|
anything from 'not harmful' to 'looks slightly better' to 'please roll them back' etc. is valued and useful ๐ ... particularly if with images
|
|
|
|
fab
|
2022-03-09 04:30:35
|
On s 5 d 0.705 most getting an improvement
|
|
2022-03-09 04:31:53
|
So 0.960 bpp imoroved
|
|
2022-03-09 04:47:18
|
|
|
2022-03-09 04:47:20
|
for %i in (C:\Users\Use\Desktop\tests\*.jpg) do cjxl -s 5 -d 0.705 %i %i.jxl
|
|
2022-03-09 04:47:26
|
for %i in (C:\Users\Use\Desktop\tests\*.jpg) do cjxl -s 7 -d 0.649 --photon_noise=ISO732 --dots=0 --epf=0 --gaborish=1 %i %i.jxl
|
|
2022-03-09 04:49:54
|
|
|
2022-03-09 04:50:37
|
amazing quality
|
|
2022-03-09 09:03:06
|
s 8 d 0.558 I0.6
|
|
2022-03-09 09:03:19
|
less than that i don't see the diff
|
|
2022-03-09 09:03:26
|
like distance one
|
|
|
|
_wb_
|
2022-03-11 12:16:44
|
anyone else seeing improvements or regressions after the above change?
|
|
|
|
necros
|
2022-03-12 11:23:56
|
how to view artifacts if possible at all - https://github.com/libjxl/libjxl/actions/workflows/release.yaml ?
|
|
2022-03-12 02:48:45
|
what`s cjxl_ng purpose?
|
|
|
|
_wb_
|
2022-03-12 03:46:18
|
cjxl/djxl predate the library api, they are calling stuff directly
|
|
2022-03-12 03:46:38
|
cjxl_ng/djxl_ng will eventually replace them, they are rewritten to use the api
|
|
2022-03-12 03:48:06
|
so there won't be any potential discrepancy between what cjxl/djxl do and what applications can do through the api, and also so distros can actually ship small cjxl/djxl binaries that link to libjxl instead of shipping basically three copies of libjxl
|
|
|
|
Jyrki Alakuijala
|
2022-03-12 09:31:13
|
it may seem like a lot of activity for little gain
|
|
2022-03-12 09:31:48
|
but having a complete and stable C API that will have ABI stability, too, is necessary for something like libjxl
|
|
|
|
necros
|
2022-03-12 11:53:42
|
<@!794205442175402004>so as of now it`s no difference if we use cjxl or cjxl_ng in terms of performance right?
|
|
|
|
_wb_
|
2022-03-13 12:00:48
|
it's basically the same code, just called in different ways. I'd stick with cjxl/djxl for now though, the _ng ones probably still have issues
|
|
|
|
necros
|
2022-03-13 01:57:10
|
it also requires to have brotli dlls
|
|
|
Traneptora
|
2022-03-13 07:45:28
|
I'm looking at the conformance sample `bench_oriented_brg`
|
|
2022-03-13 07:45:49
|
and I'm struggling to find where in `libjxl` I can set it to output RGB instead
|
|
2022-03-13 07:46:08
|
since I'm getting BRG output instead of RGB
|
|
|
|
_wb_
|
2022-03-13 07:46:36
|
The brg is done with the icc profile
|
|
2022-03-13 07:47:16
|
So the pixels are actually rgb, except that the color profile makes the red primary blue, etc
|
|
|
|
Traneptora
|
2022-03-13 07:47:31
|
Is there a way to get the decoder to color-convert based on ICC profile
|
|
2022-03-13 07:48:31
|
for example, what if I have an unmanaged, simple viewer that doesn't understand ICC
|
|
|
|
_wb_
|
2022-03-13 07:49:06
|
Yes, but you do need to bring your own cms because we don't want to force a dependency there
|
|
|
|
Traneptora
|
|
|
_wb_
|
2022-03-13 07:49:25
|
Things should work with both lcms2 and skcms
|
|
2022-03-13 07:49:43
|
To do the icc color conversion
|
|
|
|
Traneptora
|
2022-03-13 07:50:25
|
the issue at hand is that the decoder is laying packed BRG into the pixel buffer I provide
|
|
2022-03-13 07:50:30
|
instead of packed RGB
|
|
2022-03-13 07:50:43
|
even in the event of no color management, this is incorrect
|
|
|
|
_wb_
|
2022-03-13 07:51:07
|
No it does packed RGB and it gives you an ICC profile that will cause the data to look right
|
|
2022-03-13 07:51:24
|
Without the icc profile it will look very wrong (like brg)
|
|
2022-03-13 07:51:57
|
This is just a convenient way to verify that the icc profile is not being ignored
|
|
2022-03-13 07:55:16
|
We don't have a high-level decode api yet that will do the conversion for you (partially because we don't know what to convert _to_, we don't want to make it too easy to just get SDR sRGB and have many applications that will clip wide gamut or hdr just because they were too lazy to wire up the actual color management)
|
|
|
|
Traneptora
|
2022-03-13 07:57:25
|
I don't see a function in the libjxl decoder api to retrieve the ICC Profile data
|
|
2022-03-13 07:58:13
|
nvm, I see it, it's JxlDecoderGetColorAsICCProfile
|
|
|
|
_wb_
|
2022-03-13 08:04:48
|
Yes. Every decode application should always call that function, since it is the only way to know how to interpret the buffer you get as a result.
|
|
2022-03-13 08:05:30
|
It will always give you an icc profile that represents the correct color space, also when the jxl is using enum colorspaces
|
|
2022-03-13 08:06:34
|
(so it synthesizes an appropriate icc profile if the jxl doesn't have an explicit one)
|
|
|
|
Traneptora
|
2022-03-13 08:27:42
|
does jxl support named ICCPs, like PNG?
|
|
|
|
_wb_
|
2022-03-13 08:29:01
|
How do you mean?
|
|
2022-03-13 08:29:42
|
I think icc has a name field, yes (but that's a feature of icc, not png/jxl)
|
|
|
|
Traneptora
|
2022-03-13 08:42:17
|
ugh, ffmpeg's PNG encoder ignores ICCP side-data
|
|
2022-03-13 08:44:25
|
I'm trying to figure out why my ICCP reader isn't working, and that's apparently why
|
|
|
|
_wb_
|
2022-03-13 08:44:32
|
That's not good, it just cannot write non-sRGB png files then?
|
|
|
|
Traneptora
|
2022-03-13 08:44:59
|
PNG supports some limited headers, similar to how you can have non-sRGB jpegxl without ICCP
|
|
|
|
_wb_
|
2022-03-13 08:45:30
|
Well it has the sRGB chunk and it has chunks for gAMA and I guess primaries
|
|
|
|
Traneptora
|
2022-03-13 08:45:38
|
^ it supports those
|
|
2022-03-13 08:45:58
|
oh, good news
|
|
2022-03-13 08:46:00
|
> [2022-03-13_04:40:39] <thebombzen> it looks like pngenc.c isn't writing ICCP data. is this intentional or is it "patches welcome" territory?
> [2022-03-13_04:42:47] <Lynne> that's "a patch was already posted 1.5 days ago" territory
> [2022-03-13_04:42:51] <Lynne> https://ffmpeg.org/pipermail/ffmpeg-devel/2022-March/293898.html
|
|
|
|
_wb_
|
2022-03-13 08:46:33
|
But e.g. display P3 cannot be represented with the png chunks, since it uses the srgb transfer curve, not a pure gamma curve
|
|
2022-03-13 08:46:59
|
So in PNG you kind of need icc profiles for most cases that are not sRGB
|
|
|
|
Traneptora
|
2022-03-13 08:48:03
|
looks like haasn sent a patch though
|
|
2022-03-13 08:48:05
|
1.5 days ago
|
|
2022-03-13 08:48:08
|
that'll help
|
|
|
w
|
2022-03-16 01:19:06
|
how many lines are there per spline segment?
|
|
2022-03-16 01:19:51
|
or is it in the spec for the number of lines?
|
|
|
monad
|
2022-03-16 01:58:10
|
Last I tested it, splines could have `image_pixels/2` points, if that's what you're looking for.
|
|
|
|
w
|
2022-03-16 02:16:01
|
i mean the individual straight line segments for rendering the curve between two spline points
|
|
|
|
_wb_
|
2022-03-16 06:11:27
|
There's now a limit on how many pixels end up getting redrawn because of splines
|
|
|
novomesk
|
2022-03-17 11:28:39
|
The jxlinfo program can be built under examples but it is never installed.
I think this is useful utility and I would like it is part of tools and to be installed.
I do not have problem to build it myself when it is not installed, the suggestion is just for convenience reason. I think the jxlinfo could be useful for others too.
|
|
|
|
Traneptora
|
2022-03-19 03:57:43
|
either this, or its features could be wrapped into djxl
|
|
2022-03-19 03:57:47
|
like `djxl --info`
|
|
|
p0nce
|
2022-03-19 10:20:06
|
Do you have to pay to see the spec?
|
|
|
|
_wb_
|
2022-03-20 12:05:15
|
the committee draft of the 2nd edition will be publicly available
|
|
2022-03-20 12:05:39
|
ISO puts its docs behind a paywall, sadly
|
|
|
|
Traneptora
|
2022-03-22 08:36:09
|
<@!794205442175402004> how does one get 4096 extra channels as advertised? max `num_extra_channels` is only 256 for level 10
|
|
|
|
_wb_
|
2022-03-22 09:52:10
|
I guess we could define a higher level
|
|
2022-03-22 09:53:00
|
So far I haven't seen a use case that requires more than 120 channels
|
|
|
lonjil
|
2022-03-22 10:25:46
|
what use case was that?
|
|
|
|
Traneptora
|
2022-03-23 03:54:50
|
hey lonjil
|
|
|
|
_wb_
|
|
lonjil
what use case was that?
|
|
2022-03-23 06:23:06
|
Wait, I misremembered, it was even 200, not 120 channels: https://github.com/libjxl/libjxl/issues/1245
|
|
2022-03-23 06:23:37
|
Hyperspectral satellite imagery
|
|
2022-03-23 06:24:13
|
Though usually it's more like a dozen or so bands
|
|
|
|
lonjil
|
2022-03-23 08:51:06
|
:o
|
|
|
Traneptora
hey lonjil
|
|
2022-03-23 08:51:16
|
hihi
|
|
|
Kenny / Mountain Nomad
|
|
_wb_
Wait, I misremembered, it was even 200, not 120 channels: https://github.com/libjxl/libjxl/issues/1245
|
|
2022-03-23 09:28:42
|
Probably bonza for astronomical and bio sensing imagery too.
|
|
|
190n
|
|
_wb_
Wait, I misremembered, it was even 200, not 120 channels: https://github.com/libjxl/libjxl/issues/1245
|
|
2022-03-24 03:14:54
|
your cloudinary blog post says jxl can do up to 4099 channels. am i guessing correctly that that is rgba (special case i guess) + 4095 (12-bit unsigned int) extra?
|
|
|
|
_wb_
|
2022-03-24 06:18:04
|
It's rgb + 4096 extra
|
|
|
|
190n
|
2022-03-24 06:20:01
|
interesting
|
|
2022-03-24 06:20:23
|
is the number actually stored in 12 bits? not sure how you'd efficiently represent the range [0, 4096]
|
|
|
|
_wb_
|
2022-03-24 06:22:43
|
If it's 0 then it's coded as 00
If it's 1 (e.g. only alpha) then it's coded as 01
If it's 2..17 then it's 10 plus 4 bits
If it's 1..4096 then it's 11 plus 12 bits
|
|
2022-03-24 06:23:46
|
So in the common cases it's 2 or 6 bits, only if you have 18 or more extra channels it uses 14 bits total
|
|
|
|
190n
|
2022-03-24 06:24:05
|
ooh that makes sense ty
|
|
|
|
_wb_
|
2022-03-24 06:24:31
|
Jxl headers are trying to be concise :)
|
|
|
|
Deleted User
|
|
|
Traneptora
|
2022-03-30 01:44:20
|
are the level5 and level10 restrictions on the size header the same for the image size and the intrinsic size?
|
|
|
|
_wb_
|
2022-03-30 02:03:17
|
Intrinsic size is not currently in the level spec - it's only a recommended viewing dimension, the decoder doesn't care about it
|
|
2022-03-30 02:04:38
|
Note that the restrictions are also for frame size. Frames can be larger than the image so this is not implied.
|
|
|
|
Traneptora
|
2022-03-30 02:55:04
|
I see
|
|
|
Maiki3
|
2022-03-31 07:25:16
|
I wonder if apps like Netflix / Hulu will implement JXL support on Roku devices. I have a 50" TV on my desk and I'm only a few feet away from the TV, and because I'm sitting that close, the thumbnail images in these apps look **really** JPEG'd. JXL would nearly completely resolve those JPEG artifacts at this viewing distance. Not only that but even at 6 feet away, I can see a **lot** of jpeg artifacts.
|
|
2022-03-31 07:26:53
|
I definitely understand that 3 and 6 feet are not the typical viewing distances for a 50" TV, however, it seems like it wouldn't be that big of an issue to just implement JXL on these apps and devices and begin delivering JXL format. 2, maybe 3 days of work for the average programmer?
|
|
|
|
w
|
2022-03-31 07:27:16
|
those services are probably going to do avif, if anything
|
|
|
|
Maiki3
|
2022-03-31 07:27:30
|
I'm down with that too. ๐
|
|
2022-03-31 07:27:48
|
Either of these 2 formats are suitable alternatives.
|
|
2022-03-31 07:29:54
|
Also, these apps could deliver HDR versions of JXL/AVIF, right? Seems like this is something they should be doing since HDR is pretty much the standard now.
|
|
|
|
diskorduser
|
2022-03-31 09:12:57
|
HDR thumbnails?
|
|
|
improver
|
2022-03-31 09:16:13
|
true, quite unlikely
|
|
2022-03-31 09:16:38
|
though some of them could look cool ngl
|
|
|
|
Traneptora
|
2022-03-31 06:23:36
|
how does Modular mode work anyway? VarDCT is DCT-based with fourier coefficients, simple enough to understand if you understand fourier transforms
|
|
2022-03-31 06:23:40
|
but what is modular?
|
|
2022-03-31 06:23:49
|
what mathematical tool does it leverage?
|
|
|
BlueSwordM
|
|
Traneptora
what mathematical tool does it leverage?
|
|
2022-03-31 06:57:42
|
It uses a modified Haar transform last time I checked.
|
|
|
|
Traneptora
|
2022-03-31 06:58:09
|
ah okay
|
|
|
|
veluca
|
2022-03-31 07:59:08
|
well, *can* use
|
|
|
|
_wb_
|
2022-03-31 09:00:27
|
It is called modular because its transforms are like lego bricks, you can combine them however you want
|
|
2022-03-31 09:00:53
|
The modified haar transform (squeeze) is one of the transforms
|
|
2022-03-31 09:01:13
|
A generalized palette is another
|
|
2022-03-31 09:01:23
|
And RCTs are another
|
|
2022-03-31 09:03:29
|
Besides transforms, the main thing in modular is its meta-adaptive context model (MA trees) which can be used to tune the context modeling to the image contents
|
|
2022-03-31 09:04:25
|
It has lz77 + (ANS or Huffman) as entropy coder, like everything in jxl
|
|
2022-03-31 09:05:14
|
The ctx model can have a predictor, multiplier and offset per context, not just different histograms
|
|
2022-03-31 09:05:48
|
Histograms can be shared between similar contexts thanks to context clustering
|
|
2022-03-31 09:05:56
|
And that's about it
|
|
|
|
Traneptora
|
2022-03-31 10:27:37
|
quick double check, `ceil(log2(x+1))` for integer `x` is the same as `floor(log2(x))+1`, is it?
|
|
2022-03-31 10:27:53
|
positive* integer `x`, I mean.
|
|
|
|
Hello71
|
2022-03-31 11:20:37
|
that can't be right. f(0)=0, g(0)=-inf
|
|
|
|
Traneptora
|
2022-03-31 11:43:03
|
positive* integer `x`
|
|
2022-03-31 11:43:07
|
zero is not positive
|
|
|
|
veluca
|
2022-04-01 01:17:11
|
ought to be yes
|
|
|
lithium
|
2022-04-04 09:25:59
|
About non-photo content improvement I have some question,
look like Jon have some good progress on varDCT + Modular patches method(separation).
A little curious, varDCT + Modular patches method(separation)
or auto switch varDCT + Modular delta palette method,
if compare lossy quality and compression rate(density),
which method is better for "really non-photographic" non-photo?
> https://github.com/libjxl/libjxl/issues/1188
|
|
|
|
Traneptora
|
2022-04-04 08:24:32
|
Is there a public committee draft of part2 of the spec, for the container format?
|
|
2022-04-04 08:32:34
|
pinging <@!179701849576833024> here cause Jon is on vacation
|
|
|
|
veluca
|
2022-04-04 08:58:40
|
not as far as I know
|
|
|
|
Traneptora
|
2022-04-05 04:34:56
|
I'm trying to wrap a JXL file in a container for testing purposes
|
|
2022-04-05 04:36:46
|
I'm thinking that if I can just `cat header.dat input.jxl >test.jxl` this should work, provided that `header.dat` equals this:
|
|
2022-04-05 04:36:53
|
```
0000000c4a584c200d0a87aa00000014667479706a786c20000000006a786c20000000006a786c63
```
|
|
2022-04-05 04:37:03
|
```
$ hexdump -C header.dat
00000000 00 00 00 0c 4a 58 4c 20 0d 0a 87 aa 00 00 00 14 |....JXL ........|
00000010 66 74 79 70 6a 78 6c 20 00 00 00 00 6a 78 6c 20 |ftypjxl ....jxl |
00000020 00 00 00 00 6a 78 6c 63 |....jxlc|
00000028
```
|
|
2022-04-05 04:37:12
|
but I'm missing something here, since everything's rejecting it
|
|
|
|
_wb_
|
2022-04-05 05:56:18
|
Yes, that should work
|
|
2022-04-05 05:57:40
|
For level 5 codestreams at least
|
|
|
|
fab
|
2022-04-05 07:38:48
|
facebook now has a sgttange atio
|
|
2022-04-05 07:39:19
|
860 kb
|
|
2022-04-05 07:39:23
|
fo a facebook image absud
|
|
2022-04-05 07:39:42
|
most ae 100 kb now
|
|
2022-04-05 07:39:55
|
o 188 kb
|
|
|
|
diskorduser
|
2022-04-05 09:19:37
|
What is this
|
|
|
Nova Aurora
|
|
diskorduser
What is this
|
|
2022-04-05 09:28:38
|
An album cover, I don't know why, but that is what it is
|
|
|
|
Jyrki Alakuijala
|
|
lithium
About non-photo content improvement I have some question,
look like Jon have some good progress on varDCT + Modular patches method(separation).
A little curious, varDCT + Modular patches method(separation)
or auto switch varDCT + Modular delta palette method,
if compare lossy quality and compression rate(density),
which method is better for "really non-photographic" non-photo?
> https://github.com/libjxl/libjxl/issues/1188
|
|
2022-04-05 04:08:32
|
I think the delta palette + VarDCT will eventually be the strongest combo. Today delta palette is very slow (both encoding and decoding) and rigid (only one quality)
|
|
|
|
lithium
|
|
Jyrki Alakuijala
I think the delta palette + VarDCT will eventually be the strongest combo. Today delta palette is very slow (both encoding and decoding) and rigid (only one quality)
|
|
2022-04-05 04:52:24
|
I understand, Thank you for your reply. ๐
delta palette also can apply XYB color transform and other libjxl features(--patches, --epf, --noise, --dots)?
|
|
|
WoofinaS
|
2022-04-08 01:54:27
|
Sort of off topic, but was good generation loss a consideration when designing jxl or was it a byproduct of other design decisions?
|
|
|
|
_wb_
|
2022-04-08 03:03:56
|
Mostly the latter I think, but some of the design decisions that are good for fidelity (like avoiding chroma subsampling as much as possible) are also good for generation loss
|
|
|
|
Deleted User
|
2022-04-08 03:28:48
|
What's the current status, is it actually still (or again) good for a low generation loss?
|
|
|
|
WoofinaS
|
2022-04-08 03:42:23
|
Thanks <:koronedorime:813367458894446612>
|
|
|
|
monad
|
2022-04-08 03:52:20
|
Make sure you get the encoder settings right. https://discord.com/channels/794206087879852103/803645746661425173/898948542821965924
|
|
|
|
WoofinaS
|
2022-04-08 06:56:25
|
That video exactly was actually partly why I was asking lol
|
|
|
Sage
|
|
What's the current status, is it actually still (or again) good for a low generation loss?
|
|
2022-04-11 02:14:53
|
I do know there's an old test showing it's amazing for generation loss
|
|
2022-04-11 02:15:16
|
it *should* apply to the current encoders I think but I could be wrong
|
|
|
eddie.zato
|
2022-04-11 08:56:23
|
`-q` random between 87 and 97
|
|
2022-04-11 09:00:19
|
The encoders were built today just before the test from the latest git sources.
|
|
|
|
_wb_
|
2022-04-11 10:15:09
|
Decoding to 16-bit png before re-encoding should help, and disabling epf too
|
|
2022-04-11 10:16:18
|
Cross-block filters like gaborish and epf are good to avoid blockiness but the downside is that they can make errors propagate.
|
|
2022-04-11 10:17:33
|
The big advantage of the simplicity of good old jpeg is that errors are contained in 8x8 blocks, the only thing that can cause errors to spread is chroma subsampling.
|
|
|
Pashi
|
2022-04-11 10:00:48
|
mozjpeg is niiiice
|
|
|
|
_wb_
|
2022-04-13 04:29:32
|
so I'm trying to add .pam output support to djxl
|
|
2022-04-13 04:29:45
|
and I thought I was doing things wrong
|
|
2022-04-13 04:29:58
|
but I think it's ImageMagick that is doing things wrong
|
|
2022-04-13 04:31:47
|
8-bit and 16-bit pam works fine, but at other bitdepths it looks like imagemagick has a buggy implementation of pam
|
|
|
The_Decryptor
|
2022-04-15 11:01:58
|
Oh cool, trying to get more info on https://github.com/libjxl/libjxl/issues/1282 so I compiled my own builds in case it was a specific issue with the github produced ones
|
|
2022-04-15 11:02:14
|
Locally built release builds have the same problem as the github produced builds
|
|
2022-04-15 11:02:26
|
But debug builds don't, they produce an output file normally
|
|
|
|
_wb_
|
2022-04-15 11:20:26
|
Lovely
|
|
2022-04-15 11:20:42
|
That will be fun to debug then
|
|
2022-04-15 11:20:49
|
What compiler is this?
|
|
|
|
The_Decryptor
|
2022-04-15 11:43:22
|
It's MSVC (19.31.31106.2)
|
|
|
|
veluca
|
2022-04-15 12:01:58
|
does it happen with clang?
|
|
|
|
The_Decryptor
|
2022-04-15 12:03:38
|
heh, literally just managed to get it to compile with clang, no it works fine then
|
|
|
|
veluca
|
2022-04-15 12:09:57
|
ah, perfect, MSVC optimization pass that is either buggy or finds UB
|
|
2022-04-15 12:10:03
|
love it when that happens
|
|
2022-04-15 12:10:52
|
can you try in scalar only mode? (https://github.com/libjxl/libjxl/blob/main/.github/workflows/build_test.yml#L49 -- i.e. pass -DHWY_COMPILE_ONLY_SCALAR)
|
|
|
|
The_Decryptor
|
2022-04-15 12:39:08
|
Ok, the result was so slow that I was worried I'd accidentally built a debug build, but yes that's worked
|
|
|
|
veluca
|
2022-04-15 12:56:50
|
yeah without SIMD it's *slow*
|
|
2022-04-15 12:57:59
|
and how about SSE only? `-DHWY_DISABLED_TARGETS="HWY_AVX2|HWY_AVX3"`
|
|
2022-04-15 12:58:28
|
wouldn't be the first (or second, or third) time a compiler has some bugs in AVX codegen
|
|
|
|
The_Decryptor
|
2022-04-15 01:07:53
|
Yep, that fixes it
|
|
2022-04-15 01:08:07
|
Nice and fast, and doesn't crash, best of both worlds :p
|
|
|
|
veluca
|
2022-04-15 01:41:03
|
lovely
|
|
2022-04-15 01:41:19
|
I think this is a msvc bug then
|
|
|
|
_wb_
|
2022-04-15 05:18:16
|
Can msvc bugs be filed somewhere easily or does that require jumping through microsoft hoops?
|
|
|
|
veluca
|
2022-04-15 06:54:53
|
no clue
|
|
|
Jim
|
2022-04-17 11:20:04
|
https://tenor.com/view/push-prank-joke-swimming-pool-swimming-gif-11954362
|
|
|
|
lithium
|
2022-04-18 06:56:07
|
delta palette is good for really non-photographic non-photo content,
A little curious, if non-photo mix photo or photo-like content image,
(youtube main page screenshot and PR466 example)
delta palette will spend more bit and reduce compression rate(density) for this situation?
> https://user-images.githubusercontent.com/15010068/129902950-7c0dc54d-aab4-4a80-bd66-eeed2d776e72.png
|
|
|
|
_wb_
|
2022-04-18 07:15:37
|
Composite images like such screenshots are probably best encoded using vardct for the photo parts, modular patches for the text, and modular for the rest.
|
|
|
|
lithium
|
|
_wb_
Composite images like such screenshots are probably best encoded using vardct for the photo parts, modular patches for the text, and modular for the rest.
|
|
2022-04-18 09:57:30
|
Thank you for your reply ๐
Look like combine VarDCT, Modular delta palette, Modular patches and
mix those feature in same image is a flexible method,
similar libjxl PR466, but I guess need find good method to fix border issue?
But in previous discuss, I guess Jyrki Alakuijala prefer use heuristic switch different standalone method?
(switch VarDCT and Modular delta palette)
I don't know which method is better,
A little curious, libjxl team plan implement which method?
> Jyrki Alakuijala
> Detecting and using different approaches is a dirty trick that tries to circumvent unnecessary deficiencies
> -- the system should always just work
> When detecting and using different approaches for compression density, then it is ok
> It is not equally ok as a method to suppress visible artefacts
|
|
2022-04-19 03:30:48
|
> _wb_ โ 2022/03/31
> guess what I'm trying to do... it will take time to get these heuristics right and do it in an effective and safe way
> https://cdn.discordapp.com/attachments/804324493420920833/959064048824119357/station.png.jxl.png
> https://discord.com/channels/794206087879852103/804324493420920833/959064050149503106
Look like I miss this improve,
this heuristics can fix PR466 border issue?
I think this method is a high fidelity and flexible method.
|
|
|
gnat
|
|
eddie.zato
`-q` random between 87 and 97
|
|
2022-04-19 06:49:26
|
webp not lookin so hot
|
|
|
Yari-nyan
|
2022-04-19 07:50:08
|
digital mold
|
|
|
|
_wb_
|
2022-04-20 07:31:38
|
<@456226577798135808> I want to add dithering to the integer output paths in the libjxl decode api, it does make a huge difference indeed for some images
|
|
2022-04-20 07:32:31
|
brightness bumped up a bit to more easily see it, but you also see it in the originals on a sufficiently bright screen
|
|
2022-04-20 07:33:19
|
same default d1 jxl file, current uint8 decoder output on the left, dithered uint8 output (using 8x8 ordered dither) on the right
|
|
2022-04-20 07:34:25
|
this is zoomed in and brightened, at 1:1 resolution I cannot see artifacts compared to the original when looking at the dithered image, but in the non-dithered one I do see that banding
|
|
2022-04-20 07:36:17
|
ironically, adding dithering to the integer output paths will not fix things in Chrome, since Chrome is using float output, then doing color management (which doesn't apply dithering) and ultimately has a non-dithered uint8 buffer in display space.
|
|
2022-04-20 07:38:04
|
to fix that, we'll need to add color management to the libjxl api so we can do the convert from float to uint ourselves and make sure it gets properly dithered, since relying on viewing applications / browsers to do it is not going to work...
|
|
|
|
Deleted User
|
|
_wb_
<@456226577798135808> I want to add dithering to the integer output paths in the libjxl decode api, it does make a huge difference indeed for some images
|
|
2022-04-20 11:02:32
|
already for 1.0? ๐ฎ
|
|
|
|
improver
|
2022-04-20 12:03:10
|
yep this is quite a difference
|
|
|
|
_wb_
|
|
already for 1.0? ๐ฎ
|
|
2022-04-20 12:11:39
|
if it's up to me, yes. I don't think it's a good idea to release a 1.0 that produces output with banding, and relying on viewers/browsers to properly do dithering is not a good idea โ I think just about none of them do that.
|
|
|
|
Deleted User
|
2022-04-20 12:34:06
|
please flex your Cloudinary muscles to convince Google! <:PeepoDiamondSword:805394101340078092>
|
|
|
_wb_
ironically, adding dithering to the integer output paths will not fix things in Chrome, since Chrome is using float output, then doing color management (which doesn't apply dithering) and ultimately has a non-dithered uint8 buffer in display space.
|
|
2022-04-20 12:37:43
|
Firefox at least uses uint8 directly. So no additional work there.
Though I think that applications that grab 32 bit float should be capable of dithering themselves.
|
|
|
|
WoofinaS
|
2022-04-20 02:44:53
|
Is it currently even possible to get a HBD image from djxl? <:AstolfoThink:682487737974259753>
|
|
|
|
Deleted User
|
2022-04-20 02:48:16
|
yes, you can override the output bit depth.
|
|
|
|
WoofinaS
|
2022-04-20 02:54:30
|
Never notice that before, I must be blind <:cheems:889916596200566864>
|
|
|
|
fab
|
2022-04-20 03:05:00
|
what if i have a ten bit display
|
|
2022-04-20 03:05:11
|
how libjxl will eact in cheom bwosee
|
|
|
|
_wb_
|
2022-04-20 03:11:42
|
afaik, chrome either uses 8-bit uint buffers in display space (for SDR images), or it uses 16-bit half-float buffers (for HDR images)
|
|
|
โฉโฉโฉ๏ฝ๏ฝ๏ฝ๏ฝ
|
2022-04-20 04:13:20
|
Anyone know how to decode multiple jxl? like image01-99.jxl to output01-99.png
|
|
2022-04-20 04:14:10
|
based on >> djxl input.jxl output.png
|
|
|
|
_wb_
|
2022-04-20 04:18:16
|
`for i in image*.jxl; do djxl $i $(basename $i .jxl).png; done`
|
|
2022-04-20 04:18:29
|
or something like that
|
|
|
|
โฉโฉโฉ๏ฝ๏ฝ๏ฝ๏ฝ
|
|
|
diskorduser
|
2022-04-20 04:32:25
|
If you have fd binary, it's shorter to type.
fd -e jxl -x djxl {} {.}.png
|
|
|
|
โฉโฉโฉ๏ฝ๏ฝ๏ฝ๏ฝ
|
2022-04-20 05:22:29
|
got this simple worked. win11 cmd syntax is a bit weird. It doesnt recognize "image*.jxl" but need some parenthsis
|
|
2022-04-20 05:22:33
|
FOR %i IN (image*.jxl); DO djxl %i %i.png
|
|
2022-04-20 05:22:37
|
this works
|
|
|
|
Hello71
|
2022-04-20 09:18:32
|
that seems right if you're stuck on the terrible windows cmd.exe
|
|
|
_wb_
`for i in image*.jxl; do djxl $i $(basename $i .jxl).png; done`
|
|
2022-04-20 09:20:45
|
better quote everything in case of whitespace, and parameter expansion is slightly faster than invoking basename (although negligible compared to djxl in this case): `for i in *.jxl; do djxl "$i" "${i%.jxl}.png"; done`
|
|
|
Orum
|
2022-04-20 11:09:08
|
would it be considered a bug if lossless `-e 3` makes jxls that are over 4x as large as `-e 2`?
|
|
2022-04-20 11:10:51
|
seems to be *very* specific to `-e 3` and only for certain types of content
|
|
|
|
veluca
|
2022-04-20 11:13:31
|
let me guess, stuff that's very much not photographic?
|
|
|
|
Orum
|
2022-04-20 11:14:27
|
bingo
|
|
|
|
_wb_
|
2022-04-21 05:05:19
|
I don't think we can really guarantee that more effort always means smaller files, but we could try to be more like that, I guess
|
|
2022-04-21 05:08:13
|
As it is now, e2 does clampedgradient with a fixed MA tree, which is fast and works reasonably well on both photo and nonphoto.
E3 does weighedpredictor with a fixed MA tree (something similar to the original lossless pik), which is slower than e2 because it's a more complicated predictor, and it works better on photo but worse on nonphoto.
|
|
|
|
veluca
|
2022-04-21 06:19:30
|
I think the best we can reasonably do is a quick heuristic at e3 to pick between whatever e2 does and whatever e3 does, probably looking at histograms for some small random patch or something like that
|
|
|
|
Maiki3
|
|
_wb_
<@456226577798135808> I want to add dithering to the integer output paths in the libjxl decode api, it does make a huge difference indeed for some images
|
|
2022-04-22 10:13:15
|
dithering is god mode activated.
|
|
2022-04-22 10:15:41
|
I determined that, I really like these settings when downconverting my phone camera's images from JPG to JXL:
``Distance: 2``, ``Speed: 7``, ``Fast Decoding: 3``, ``Photon Noise: 1000``
|
|
2022-04-22 10:16:36
|
results in a pretty significant filesize reduction, without a huge hit to quality, and the photon noise approximate... it's probably closer to 800, but w/e I'm not sweating it.
|
|
2022-04-22 10:17:18
|
I determined that Fast Decoding 4 is the point at which the quality nose dives in a bad way. so, I don't see the point in going higher than 3.
|
|
2022-04-23 06:06:27
|
This is kind of interesting. I compressed a PNG screenshot with these settings:
```Distance: 0.1, Speed: 9, Fast Decode: 5```
and
```Distance: 0.1, Speed: 9, Fast Decode 0```
|
|
2022-04-23 06:06:47
|
The Fast Decode 5 is 695KB
The Fast Decode 0 is 705KB
|
|
|
|
_wb_
|
2022-04-23 06:40:51
|
Could be that patches are a bit counterproductive for density in that image
|
|
2022-04-23 06:41:42
|
What do the metrics say about the resulting images?
|
|
|
|
Maiki3
|
2022-04-23 06:46:59
|
what do I use for that? jxlinfo.exe or benchmark_xl.exe?
|
|
|
|
_wb_
|
2022-04-23 06:48:12
|
benchmark_xl, or decode the jxl files and use butteraugli or ssimulacra <original> <decoded>
|
|
|
|
Maiki3
|
2022-04-23 06:51:15
|
```
X:\ProgramFiles\JpegXL>benchmark_xl.exe --input "2022-04-20, 23;32;04, Wednesday - KSP_x64_(JXL_d0,1_s9_fd0).jxl" --print_more_stats
benchmark_xl [v0.3.6 | SIMD supported: SSE4,Scalar]
4 cores, 1 tasks, 0 threads, 4 inner threads
Failed to load image 2022-04-20, 23;32;04, Wednesday - KSP_x64_(JXL_d0,1_s9_fd0).jxl
C:\projects\jpeg-xl\lib/jxl/codec_in_out.h:162: JXL_CHECK: metadata.m.bit_depth.bits_per_sample != 0
```
|
|
2022-04-23 06:51:28
|
๐คท
|
|
|
|
_wb_
|
2022-04-23 06:54:39
|
benchmark_xl takes png input and you would do something like --codec=jxl:d0.1
|
|
2022-04-23 06:56:52
|
--codec=jxl:9:d0.1:faster_decoding=0,jxl:9:d0.1:faster_decoding=4
|
|
|
|
Maiki3
|
2022-04-23 07:27:13
|
```
X:\ProgramFiles\JpegXL>benchmark_xl.exe --input "2022-04-20, 23;32;04, Wednesday - KSP_x64.png" --codec=jxl:9:d0.1:faster_decoding=0,jxl:9:d0.1:faster_decoding=4
benchmark_xl [v0.3.6 | SIMD supported: SSE4,Scalar]
4 cores, 2 tasks, 2 threads, 0 inner threads
2022-04-20, 23;32;04, Wednesday - KSP_x64.png
Compr Input Compr Compr Compr Decomp Butteraugli
Method Pixels Size BPP # MP/s MP/s Distance Error p norm BPP*pnorm Errors
--------------------------------------------------------------------------------------------------------------------------------------------------
jxl:9:d0.1:faster_decoding=0 2429025 781753 2.57470548883 1 0.020 5.492 0.38012248 0.09831484939 0.2531317823478697 0
jxl:9:d0.1:faster_decoding=4 2429025 756226 2.49063224957 1 0.017 7.581 0.20821159 0.06589137108 0.1641111737684148 0
Aggregate: 2429025 768884 2.53231998839 --- 0.019 6.453 0.28132882 0.08048664624 0.2038179430746954 0
Allocations: 7229 (max bytes in use: 1.290927E+09)
```
|
|
|
|
_wb_
|
2022-04-23 07:33:38
|
Interesting, looks like faster decoding=4 is better in every way for that image and distance target
|
|
|
|
Maiki3
|
2022-04-23 07:35:57
|
|
|
2022-04-23 07:36:04
|
There's the image in question lol. Truly, a work of art.
|
|
|
|
_wb_
|
2022-04-23 07:38:09
|
Makes me wonder what causes the difference - probably not patches on that image
|
|
|
|
Maiki3
|
2022-04-23 07:43:07
|
To be fair, the need to encode a distance: 0.1 of that image is pretty much non existent.... so, at higher distance values, the faster decoding ends up being a detriment to the quality and filesize
|
|
2022-04-23 07:43:48
|
... which falls more in line with the faster decoding's intended consequences
|
|
|
|
_wb_
|
2022-04-23 09:23:21
|
Yes, in practice, I think you either want lossless or d0.5 to d3
|
|
|
|
Traneptora
|
2022-04-23 07:16:09
|
I'm finding that effort=3 is producing smaller files than effort=7 for synthetic content
|
|
2022-04-23 07:16:13
|
this seems a little bit odd to me
|
|
|
|
_wb_
|
2022-04-23 07:29:35
|
For lossless or lossy?
|
|
|
|
Traneptora
|
2022-04-23 07:29:49
|
lossy
|
|
2022-04-23 07:29:54
|
haven't tested lossless, tbh
|
|
|
|
_wb_
|
2022-04-23 07:30:43
|
For lossy, higher effort doesn't mean smaller files, it means better quality/bpp curve and more consistent quality
|
|
2022-04-23 07:31:53
|
Lossy e3 giving a smaller file for synthetic content probably means it produces a file that is too low quality
|
|
|
|
Traneptora
|
2022-04-23 07:41:59
|
interesting
|
|
|
_wb_
Lossy e3 giving a smaller file for synthetic content probably means it produces a file that is too low quality
|
|
2022-04-23 07:42:14
|
but wouldn't targetting butteraugli distance make it so the quality is roughly consistent
|
|
2022-04-23 07:42:33
|
at least that was my impression of how butteraugli distance worked
|
|
2022-04-23 07:42:40
|
or is it only consistent at a specific effort setting
|
|
|
|
monad
|
2022-04-23 07:58:17
|
Higher effort can generally translate to more accurately hitting the target distance.
|
|
|
|
_wb_
|
2022-04-23 08:07:22
|
the lower the effort, the more the "targetting" is basically just corpus-wide heuristic tuning
|
|
2022-04-23 08:07:48
|
only at higher effort is it more image content dependent tuning
|
|
|
|
Yari-nyan
|
2022-04-23 08:26:37
|
i've had JPEG XL output larger than GIF animations, somehow, with high effort
|
|
|
|
monad
|
2022-04-23 08:31:39
|
Because lossless is complicated. JXL has a lot of tools, but it's very challenging to compete with every other algorithm on all kinds of content in a practical way.
|
|
|
|
Yari-nyan
|
2022-04-23 08:42:08
|
i've heard "JPEG XL always beats PNG" before
|
|
2022-04-23 08:42:17
|
not entirely accurate
|
|
|
|
_wb_
|
2022-04-23 09:30:27
|
Corpus-wide, yes. On every single image, probably not. Maybe with an exhaustive encoder, it could get closer to that, but I think there will always be "png art" that happens to compress exceptionally well with png.
|
|
|
|
Maiki3
|
2022-04-24 03:36:24
|
I suggest we add a feature to CJXL that encodes your image in every possible quality setting, and then gives you only the best version lol. (sarcasm)
|
|
|
yurume
|
2022-04-24 03:50:44
|
`-e inf`
|
|
|
|
monad
|
2022-04-24 05:24:55
|
Even better, use AI to pick the best parameters so you only need one encode.
|
|
|
|
Orum
|
2022-04-24 08:41:09
|
yeah, overall jxl is quite good for lossless, but there are some weird outliers
|
|
|
|
lonjil
|
2022-04-24 09:04:06
|
Run a full exhaustive compression on a whole tonne of files, record how well (or unwell) each choice of parameters and strategies do for each image, use data to train an AI.
|
|
|
|
yurume
|
|
_wb_
For lossy, higher effort doesn't mean smaller files, it means better quality/bpp curve and more consistent quality
|
|
2022-04-24 04:27:45
|
honestly speaking this aspect is not well communicated to cjxl users right now, it took a while for me to realize this
|
|
|
|
_wb_
|
2022-04-24 05:08:11
|
Yes, it's a somewhat tricky and subtle point though. Maybe too much for cjxl --help, though it could go in the man page...
|
|
|
|
Maiki3
|
2022-04-25 05:21:18
|
1. Has an auto-detect ISO Value feature been considered... so that it can just be enabled and the user doesn't have to worry about testing a variety of different ISO levels until they figure out which one to use?
2. Has a feature that detects patches of noise and adds it back after those areas get heavily compressed been considered? I could see this being useful for things like, Streaming service large background images that are 1080p or bigger (i.e. netflix, hulu, disney+, etc), where they typically obliterate the quality of the background image just so that they can save a few bits on bandwidth... and if you're sitting closer than 6 feet to your TV, it becomes painfully obvious how much they compressed the image.
I feel like these 2 features alone, if enabled by default, would be pretty game changing since most people who compress images don't know what they're doing, and this would make all images compressed with JXL by default appear higher quality.
Bonus: Enable dithering by default to help eliminate banding artifacts.
|
|
2022-04-25 05:31:12
|
(Although, to be fair, if point #2 is implemented it might eliminate the need for point #1)
|
|
|
|
WoofinaS
|
2022-04-25 04:25:06
|
This is just my two cents on the matter so take it with a gain of salt.
Like what \_wb\_ said, cjxl does not actually target your desired d and will In most cases overshoot it significantly. I've personally had cases where e7 gave me a resulting image with a max error of 1.5 when I requested 1 **at e7**. (This is kinda expected as I'll go over later).
The only efforts that seem to respect your target d is both e8 and e9. However there seems to be a internal offset that I think someone mentioned before, and at least the last time I did my benchmarks, you needed a target d of .8 to get a "true d" of 1.
If you normalize the true d of the encoded images, the slower presets are far far far more efficient then what then what cjxls "target d" will lead you to believe.
Last time I played with it as well, e9 only seemed to improve appon the 3norm and not max error.
|
|
2022-04-25 05:14:00
|
I personally disagree with Maiki3 suggestions of automatic ISO/"GrAIn SnTHeSiS" level.
The first requirement would be a competent denosing Algo.
Nlmeans wouldn't cut it alone on top of already being far slower then even e7.
It would also have to figure out the correct strength to denosie at which would probably take several attempts without a nice estimation heuristic.
The reason we are able to bet away without denosing with av1/avif is due to how destructive the current encoders are with noise.
|
|
2022-04-25 05:14:47
|
I also don't agree with ordered dithering being default because of transcoding
|
|
|
|
_wb_
|
|
WoofinaS
I also don't agree with ordered dithering being default because of transcoding
|
|
2022-04-25 05:23:06
|
I don't see the problem with dithering and transcoding. Dithering is a way to get more accurate quantized output - if you want to do transcoding it's best to use non-quantized output, but if that's not an option, then dithered u8 should still be better than non-dithered u8...
|
|
|
|
WoofinaS
|
2022-04-25 06:01:11
|
I might just be miss remember or this was a edge case but I remember dithering bloating jpegs significantly at the same "q". You do have a point tho <:EmmyThinking:603759119517876260>
|
|
|
|
_wb_
|
2022-04-25 06:09:00
|
Dithering would increase png size at slow gradients, but that's basically because more information is actually preserved...
|
|
|
|
WoofinaS
|
2022-04-25 06:12:05
|
Indeed, however jpeg is horrible at retaining it.
Imo the detail preserved is not worth the extra bloat.
|
|
2022-04-25 06:12:13
|
That's up for debate tho
|
|
2022-04-25 06:14:46
|
In a perfect world we could just output to 16bit and assume the image viewer or jpeg encoder would do error diffusion/order dithering <:fubukipain:853236652553535518>
|
|
|
|
_wb_
|
2022-04-25 06:29:14
|
Sure, but the only 'viewer' I know that does proper dithering of > 8-bit images is Photoshop
|
|
|
|
WoofinaS
|
2022-04-25 06:30:59
|
Yes, I was making a joke about the dilemma we are in <:doge:585899476607172643>
|
|
|
|
fab
|
2022-04-25 07:13:08
|
https://www.reddit.com/r/linux/comments/uasx1n/ffmpeg_now_supports_jpeg_xl_should_be_available/?sort=new
|
|
2022-04-25 07:13:14
|
i commented
|
|
|
|
Hello71
|
|
_wb_
Sure, but the only 'viewer' I know that does proper dithering of > 8-bit images is Photoshop
|
|
2022-04-25 08:58:30
|
kind of ironic that video players, like video codecs, are ahead of still images
|
|
|
|
improver
|
2022-04-25 08:59:57
|
ikr
|
|
2022-04-25 09:01:31
|
when i wanted to test whether 10bit on wayland actually works i ended up using mpv for opening image because i don't think image viewers i know support that proper yet
|
|
|
|
Hello71
|
2022-04-25 09:21:44
|
about animated jxl, is there a standard way to add audio to jxl animation? e.g. for mjpeg -> jxl lossless conversion. i know there has been some discussion on this topic before, but i'm wondering what exactly are the steps necessary to carry it out
|
|
|
|
improver
|
2022-04-25 09:35:03
|
i hope you're joking, not even gif/apng/webp or even avif have that
|
|
|
|
Hello71
|
2022-04-25 10:15:36
|
webp is already a video format, and ffmpeg seems to be able to put png in mp4, mkv, and avi just fine
|
|
2022-04-25 10:16:13
|
and mjp2k is already a thing
|
|
2022-04-25 10:16:57
|
and avif is also already a video format
|
|
2022-04-25 10:17:31
|
so out of your four examples, two are irrelevant and one is a counterexample?
|
|
|
|
improver
|
2022-04-25 10:29:06
|
aint mjpeg relying on some outside container for sound
|
|
2022-04-25 10:30:21
|
webp isnt video format, other than reusing same building blocks as another video format
|
|
2022-04-25 10:30:49
|
but there is no standard way of putting audio into webp
|
|
2022-04-25 10:32:11
|
im not sure how exactly mjp2k is done but im pretty sure that its not part of what exact jp2k format is either
|
|
2022-04-25 10:34:01
|
avif reusing same building blocks as video format doesn't also allow putting audio there...
|
|
2022-04-25 10:37:30
|
i mean yea you could but the result would go in another container format not 'avif'
|
|
2022-04-25 10:37:46
|
or would be nonstandard
|
|
2022-04-25 10:39:21
|
afaik one maybe could stuff distinct jxl images into mp4 or mkv but that wouldn't use jxl's way of doing animation
|
|
2022-04-25 10:40:01
|
and that would be no longer .jxl
|
|
2022-04-25 10:40:30
|
and containing audio is way outside of jxl's goals imo
|
|
2022-04-25 10:40:57
|
so yes your question still sounds extremely odd one to me
|
|
|
|
_wb_
|
2022-04-25 10:41:37
|
Leaving it to an outside container makes most sense to me.
|
|
|
|
improver
|
2022-04-25 10:49:48
|
i think im just too sleepy at this point to interpret things in flexible ways
|
|
|
|
Traneptora
|
|
Hello71
about animated jxl, is there a standard way to add audio to jxl animation? e.g. for mjpeg -> jxl lossless conversion. i know there has been some discussion on this topic before, but i'm wondering what exactly are the steps necessary to carry it out
|
|
2022-04-26 12:50:46
|
use ffv1 inside matroska
|
|
2022-04-26 12:51:05
|
I'm mostly kidding here
|
|
2022-04-26 12:51:19
|
but no, you'd have to leave the frames separately
|
|
2022-04-26 12:51:43
|
you can always do something like `mpv foo-%02d.jxl --audio-file=audio.opus`
|
|
2022-04-26 02:30:51
|
What's the proper way to capitalize Jpeg XL?
|
|
2022-04-26 02:31:00
|
I'm not sure if we're going with "Jpeg XL" or "JPEG XL"
|
|
|
|
_wb_
|
2022-04-26 02:56:58
|
JPEG XL
|
|
2022-04-26 02:57:32
|
with a space, not JPEGXL or JPEG-XL
|
|
2022-04-26 02:58:18
|
more informally, I think both JXL and jxl are fine
|
|
|
damian101
|
2022-04-26 03:09:20
|
How do I set things like primaries and transfer characteristic for JPEG-XL images?
|
|
|
|
_wb_
|
2022-04-26 03:09:32
|
when encoding?
|
|
|
|
damian101
|
|
_wb_
when encoding?
|
|
2022-04-26 03:09:40
|
ideally, yes
|
|
2022-04-26 03:09:49
|
source files don't have the tags
|
|
|
OkyDooky
|
2022-04-26 03:10:26
|
Even better with the non breaking space like this "ย ". C2 A0 in UTF-8.
(<@794205442175402004>)
|
|
|
|
_wb_
|
2022-04-26 03:10:52
|
JxlEncoderSetColorEncoding or JxlEncoderSetICCProfile
|
|
2022-04-26 03:11:48
|
if you don't do it, it will assume the input is sRGB
|
|
2022-04-26 03:12:07
|
(with sRGB transfer curve if you give it as uint, or with linear transfer curve if you give it as float)
|
|
|
|
damian101
|
|
_wb_
JxlEncoderSetColorEncoding or JxlEncoderSetICCProfile
|
|
2022-04-26 03:12:47
|
I don't understand, I only used cjxl yet ๐
|
|
|
|
_wb_
|
|
Even better with the non breaking space like this "ย ". C2 A0 in UTF-8.
(<@794205442175402004>)
|
|
2022-04-26 03:12:51
|
agreed
|
|
|
I don't understand, I only used cjxl yet ๐
|
|
2022-04-26 03:13:11
|
ah, when using cjxl it will take the info from the png input file
|
|
|
|
damian101
|
|
|
_wb_
|
2022-04-26 03:13:26
|
if the input is ppm, it will assume sRGB
|
|
|
|
damian101
|
2022-04-26 03:13:33
|
most encoders allow overriding those flags with commands
|
|
|
|
_wb_
|
2022-04-26 03:13:36
|
you can manually override that with some weird syntax
|
|
|
|
damian101
|
|
most encoders allow overriding those flags with commands
|
|
2022-04-26 03:13:53
|
well, at least in the video world
|
|
2022-04-26 03:18:32
|
I have a bunch of untagged HDR PNGs that use PQ transfer curve and DCI-P3 primaries
|
|
|
|
_wb_
|
2022-04-26 03:18:32
|
`cjxl foo.ppm --dec-hints=color_space=RGB_D65_SRG_Rel_SRG`
|
|
2022-04-26 03:18:56
|
if they have an icc profile that describes that, it should work like that
|
|
2022-04-26 03:19:57
|
if not, then you can use `cjxl foo.ppm --dec-hints=color_space=RGB_DCI_DCI_Rel_PeQ`
|
|
2022-04-26 03:20:32
|
the syntax for specifying colorspaces on the command line is a bit awkward but it should work
|
|
2022-04-26 03:20:56
|
first thing is RGB (color) or Gra (grayscale)
|
|
2022-04-26 03:21:35
|
second thing is white point, which can be D65, EER or DCI (or custom but I dunno how to then specify it)
|
|
2022-04-26 03:22:09
|
third thing are primaries which can be SRG (sRGB primaries), 202 (rec2020/2100 primaries) or DCI (P3 primaries)
|
|
2022-04-26 03:22:51
|
fourth thing is render intent, which can be Per (perceptual), Rel (relative), Sat (saturation) or Abs (absolute)
|
|
2022-04-26 03:24:01
|
fifth thing is transfer function, which can be SRG (sRGB transfer function), Lin (linear), 709, PeQ (PQ), HLG, or DCI (it can also be some fixed gamma but I don't think that can be specified at the command line)
|
|
|
|
damian101
|
2022-04-26 03:24:13
|
damn, thanks
|
|
|
_wb_
fourth thing is render intent, which can be Per (perceptual), Rel (relative), Sat (saturation) or Abs (absolute)
|
|
2022-04-26 03:24:24
|
what is render intent?
|
|
|
|
_wb_
|
2022-04-26 03:25:10
|
it's basically saying what the color management should do when it has to convert a wide gamut space to a smaller gamut space
|
|
|
|
damian101
|
2022-04-26 03:26:10
|
I see... normally it just clips in my experience
|
|
2022-04-26 03:26:23
|
I guess that would be absolute?
|
|
|
|
_wb_
|
2022-04-26 03:26:30
|
yes, I think so
|
|
2022-04-26 03:26:44
|
Rel would be stretching instead of clipping, I guess
|
|
|
|
damian101
|
2022-04-26 03:26:58
|
but that would shift the colors
|
|
|
|
_wb_
|
2022-04-26 03:27:01
|
Sat would be attempting to preserve saturation
|
|
|
|
damian101
|
2022-04-26 03:27:08
|
interesting...
|
|
|
|
_wb_
|
2022-04-26 03:28:09
|
well if the display space cannot represent the image space, you have to do _something_ that is incorrect, and render intent lets you pick your poison
|
|
|
|
damian101
|
2022-04-26 03:28:53
|
yeah...
|
|
2022-04-26 03:29:39
|
there seem to be quite a number of good ressources on that topic
|
|
|
|
Traneptora
|
2022-04-26 04:28:45
|
what's our timeline look like for libjxl 1.0? i.e. what's blocking it
|
|
|
|
_wb_
|
2022-04-26 05:08:54
|
Finishing up the final stages of the decode pipeline (orientation, interleaving, color management, pixel format conversion with dithering), finishing up djxl_ng and cjxl_ng
|
|
2022-04-26 05:09:44
|
And then some amount of time for just doing fuzzing and security fixes before we call it 1.0
|
|
|
|
Deleted User
|
2022-04-26 05:18:08
|
That's quite some work for the next 4 days. ;P
|
|
|
|
damian101
|
2022-04-26 09:38:48
|
best way to do jxl batch encoding on Linux?
|
|
|
|
w
|
2022-04-26 10:10:16
|
imo there is no best way
|
|
|
|
_wb_
|
2022-04-26 10:11:16
|
Probably best is to use one core per image, since encode doesn't parallelize that well
|
|
|
|
w
|
2022-04-26 10:11:53
|
oh yeah I noticed doing -e 9 -E 3 -I 1 only uses 1 core
|
|
2022-04-26 10:14:06
|
I also found that -j too often crashes but I didn't save any of the jpgs
|
|
|
|
Orum
|
2022-04-26 10:16:57
|
I wouldn't say that
|
|
2022-04-26 10:17:17
|
it does depend a lot on the effort used though (and possibly resolution?)
|
|
|
Eugene Vert
|
|
best way to do jxl batch encoding on Linux?
|
|
2022-04-26 10:17:26
|
Using GNU Parallel:
```bash
parallel -j 2 cjxl '{}' $OPTS ./out/'{.}.jxl' ::: *.jpg
parallel -j 2 cjxl '{}' $OPTS ./out/'{.}.jxl' ::: *.png
```
Using fd:
```bash
fd -d 1 -e png -e jpg --threads 2 -x cjxl '{}' $OPTS ./out/'{.}.jxl'
```
Using find¶llel:
```bash
find . -maxdepth 1 \( -iname '*.jpg' -o -iname '*.png' \) -print0 | parallel -0 -j 2 cjxl '{}' $OPTS ./out/'{.}.jxl'
```
All of them will encode png and jpg images from current directory to ./out/ dir using 2 encoders in parallel ( "-j 2"|"--threads 2")
|
|
|
|
Orum
|
2022-04-26 10:17:52
|
if you're not memory constrained parallel/xargs with 1 process per virtual core is probably fine though
|
|
|
|
Traneptora
|
2022-04-27 02:16:29
|
don't forget `--num_threads 0`
|
|
|
|
damian101
|
|
_wb_
Rel would be stretching instead of clipping, I guess
|
|
2022-04-27 09:25:48
|
Relative and absolute both simply clip, but absolute adjusts for a potentially different white point.
Relative seems to be the default behaviour in most applications.
|
|
|
|
_wb_
|
2022-04-27 10:33:49
|
Ah, I see
|
|
2022-04-27 10:34:31
|
I always forget what the different intents do
|
|
|
|
Hello71
|
|
_wb_
Probably best is to use one core per image, since encode doesn't parallelize that well
|
|
2022-04-27 01:44:46
|
didn't you say something about memory bandwidth being the limiting factor? if you run more cjxls at the same time shouldn't it be worse for the cache
|
|
2022-04-27 01:45:01
|
ah, wait, that was <@179701849576833024>
|
|
|
|
veluca
|
2022-04-27 02:05:58
|
Memory bandwidth will certainly bite you with parallel - but I think that's fine, it's not going to go faster in other ways
|
|
|
|
Yari-nyan
|
2022-04-27 02:11:50
|
what's the best way to test progressive decoding of a jpeg xl image with progressive encoding enabled? also why is it (significantly) larger than with it disabled?
|
|
|
|
_wb_
|
2022-04-27 02:46:36
|
For lossy, it should not be significantly larger
|
|
|
|
Yari-nyan
|
2022-04-27 02:48:26
|
good to know
|
|
|
|
_wb_
|
2022-04-27 02:48:32
|
For lossless it is often larger because some of the lossless coding tools cannot be combined well with progressive. E.g. having different RCTs and palettes per group is fine for non-progressive, but for progressive that would lead to weird artifacts in the previews.
|
|
2022-04-27 02:49:19
|
For testing progressive, you can use djxl -s {2,4,8}
|
|
2022-04-27 02:50:08
|
Another option is decode_progressive in the examples folder
|
|
|
|
Yari-nyan
|
|
|
Traneptora
|
2022-04-27 06:36:04
|
is there any reason VarDCT isn't one of the options for modular patches?
|
|
2022-04-27 06:36:18
|
or is that mostly because you could just do a separate Frame as VarDCT
|
|
|
|
_wb_
|
2022-04-27 06:52:40
|
Nothing stops you from doing a patch frame with vardct
|
|
2022-04-27 06:54:02
|
In fact in cases like a screenshot where most of the area is nonphoto and only a few avatars are photographic, it would make sense to have a modular main frame with vardct patches
|
|
|
Justin
|
2022-04-28 12:34:15
|
Aw, man. I don't have any resources to fix it, unfortunately. It's open-source however..
|
|
|
|
Traneptora
|
2022-04-28 09:38:22
|
If `uses_original_profile = false` then does that mean the data is XYB encoded?
|
|
2022-04-28 09:38:27
|
just double checking
|
|
2022-04-28 09:38:32
|
for VarDCT at least
|
|
2022-04-28 09:38:59
|
I'm just wondering if there's ever really a reason to use `JXL_COLOR_PROFILE_TARGET_DATA`
|
|
|
|
_wb_
|
2022-04-28 09:46:00
|
yes, it always means it is XYB encoded, also in case of modular
|
|
2022-04-28 09:46:33
|
TARGET_DATA is always what you should use to know what colorspace you are actually getting pixels in
|
|
|
|
Traneptora
|
2022-04-28 09:46:50
|
well if I'm linking to `libjxl` then I'm not actually getting XYB pixels, am I?
|
|
|
|
_wb_
|
2022-04-28 09:46:54
|
there is no real reason to use the other one
|
|
|
|
Traneptora
|
2022-04-28 09:47:19
|
if I use `target_data`, then I'm getting pixels in XYB, am I not?
|
|
|
|
_wb_
|
2022-04-28 09:47:34
|
no, it will convert XYB to RGB, but not necessarily to the same one that is in the ICC color profile
|
|
|
|
Traneptora
|
|
|
_wb_
|
2022-04-28 09:48:37
|
if the image is in an enum space, you'll get pixels in that space, but if it's an arbitrary ICC color profile, you will get pixels in sRGB
|
|