|
Nova Aurora
|
|
diskorduser
time to spam its sub-reddit for jxl support
|
|
2021-03-19 03:03:02
|
and github issue tracker
|
|
|
fab
|
2021-03-19 03:03:54
|
how to make a capture with obs
|
|
2021-03-19 03:04:06
|
obs studio using jxl 0.3.4
|
|
2021-03-19 03:04:21
|
and new heuristics
|
|
2021-03-19 03:04:31
|
83.2 s 6 or q 60 s 9
|
|
2021-03-19 03:04:54
|
or for %i in (C:\Users\User\Documents\LD3*.jpg) do cjxl "%i" "%i.jxl" -m -q 49.9 -s 6 -I 1 -C 2 -P 4 --palette=132 --num_threads=2
|
|
|
|
Nova Aurora
|
2021-03-19 03:05:02
|
I don't know how to use jxl in obs
|
|
|
diskorduser
|
|
fab
it opens even RAW
|
|
2021-03-19 03:06:08
|
dng?
|
|
|
|
fab
|
2021-03-19 03:06:24
|
i don't know, i just read description
|
|
|
|
veluca
|
|
Nova Aurora
This needs JXL support: https://github.com/facebook/fresco
|
|
2021-03-19 03:09:06
|
Fresco supports Android 2.3 (Gingerbread) and later.
not bad...
|
|
|
|
diskorduser
|
2021-03-19 03:11:36
|
https://github.com/facebook/fresco/issues/2474
|
|
|
Scope
|
2021-03-19 03:13:46
|
<:Thonk:805904896879493180> https://frescolib.org/docs/customizing-image-formats.html
|
|
|
|
fab
|
2021-03-19 04:45:41
|
what palette 132 does in this command
|
|
2021-03-19 04:45:42
|
or for %i in (C:\Users\User\Documents\LD3*.jpg) do cjxl "%i" "%i.jxl" -m -q 49.9 -s 6 -I 1 -C 2 -P 4 --palette=132 --num_threads=2
|
|
|
_wb_
|
2021-03-19 04:47:41
|
it will do nothing in that command — if modular is doing lossy, it's not going to try palette
|
|
2021-03-19 04:50:19
|
if you would do lossless modular (-q 100), the --palette=132 means that it will check if the image uses 132 colors or less, and if so, it will use a palette instead of encoding it as independent color planes. This is tried both at the global level (for the whole image) and in every group (every 256x256 sub-image), and in case of RGBA images, it is tried first for RGBA colors, and if that fails, it is tried for RGB colors (for a palette + separate alpha encoding).
|
|
2021-03-19 04:51:31
|
so it is the maximum palette size that the encoder will use, and the encoder only uses it in a lossless way (only makes a palette if the image can actually be represented exactly that way)
|
|
|
|
fab
|
2021-03-19 05:01:35
|
ok
|
|
2021-03-19 05:01:42
|
so i can remove palette 132
|
|
|
|
_wb_
|
2021-03-19 05:06:39
|
I also doubt that the -C 2 -P 4 is doing much useful there, but I don't know
|
|
|
|
Deleted User
|
2021-03-19 05:09:23
|
I guess it depends on the image. Those settings may be helpful on some images and actually harmful on others.
|
|
|
|
fab
|
2021-03-19 05:11:22
|
for %i in (C:\Users\User\Documents\png\*.png) do cjxl "%i" "%i.jxl" -m --palette=1043 --lossy-palette
|
|
2021-03-19 05:11:25
|
is this good
|
|
2021-03-19 05:11:27
|
ziemek
|
|
|
|
diskorduser
|
2021-03-19 05:14:15
|
I think gnu parallel can be installed on windows.
|
|
|
|
fab
|
2021-03-19 05:14:15
|
lossy palette is slow
|
|
|
|
_wb_
|
2021-03-19 05:19:38
|
Lossy palette is currently best used with --palette=0
|
|
|
|
Deleted User
|
|
fab
is this good
|
|
2021-03-19 05:23:53
|
I don't know. I'd have to see the images that you're trying to encode. Some settings can be turned off to simplify encoding (or not to break the image; believe me, you don't want synthetic noise on mixed photo+text screenshots) and some can be turned on to better suite them to the image set.
|
|
|
|
fab
|
2021-03-19 05:30:40
|
-q 60.4 -s 3 -P 2 -C 1
|
|
2021-03-19 05:32:07
|
for now i'm doing a lossy palette encoding so is slow
|
|
|
|
diskorduser
|
2021-03-20 07:14:17
|
exiv2 doesn't recognize jxl images. Should I ask them to support jxl?
|
|
|
Crixis
|
|
diskorduser
exiv2 doesn't recognize jxl images. Should I ask them to support jxl?
|
|
2021-03-20 07:16:46
|
Yup
|
|
|
|
_wb_
|
2021-03-20 07:26:27
|
It might be a bit early, given that technically the file format (the container format which is the glue between the image codestream and the metadata) has not officially been finalized yet.
|
|
2021-03-20 07:29:10
|
But if someone wants to support it: it's just ISOBMFF, with the exif either in an `Exif` box that starts with a tiff header offset (should be just 4 zero bytes followed by the tiff header of exif), or in a `Exfc` box which contains a Brotli stream which decodes to an exif payload.
|
|
2021-03-20 07:29:46
|
XMP is similarly in an `xml ` box or Brotli-compressed in a `xmlc` box
|
|
|
Pieter
|
2021-03-20 07:30:52
|
What's XMP?
|
|
|
|
_wb_
|
2021-03-20 07:31:02
|
Monday we have a jxl adhoc group meeting about it, goal is to go to FDIS with part 2 (file format) at the JPEG meeting in April.
|
|
|
Pieter
What's XMP?
|
|
2021-03-20 07:31:31
|
https://en.m.wikipedia.org/wiki/Extensible_Metadata_Platform
|
|
|
|
diskorduser
|
2021-03-20 07:59:34
|
I have opened a GitHub issue. Should I close it now? [exiv2]
|
|
|
|
_wb_
|
2021-03-20 08:32:31
|
No, doesn't hurt to have it
|
|
2021-03-20 09:26:30
|
|
|
2021-03-20 09:26:43
|
|
|
|
|
diskorduser
|
2021-03-20 09:45:55
|
https://github.com/Exiv2/exiv2/issues/1503#issuecomment-803271582
|
|
2021-03-20 10:55:18
|
Is compression = encryption ? <:Thonk:805904896879493180>
|
|
|
spider-mario
|
2021-03-20 11:04:06
|
speaking in my personal capacity (as usual), that sounds like a not-so-subtle straw man to me
|
|
2021-03-20 11:05:42
|
he is essentially implying that using brotli would create legal insoluble challenges
|
|
2021-03-20 11:12:34
|
I certainly hope that it wouldn’t
|
|
|
|
_wb_
|
2021-03-20 01:18:42
|
No, compression is not the same thing as encryption, lol. Otherwise we wouldn't need https, just doing content-encoding deflate (or brotli) would be enough 😂
|
|
2021-03-20 01:19:16
|
Also, we are planning to make the compression of metadata optional.
|
|
|
|
Deleted User
|
2021-03-20 03:32:22
|
Most of you probably know that image well (Jon in general 😉), but there it is, taken as-is from Wikipedia.
|
|
2021-03-20 03:32:49
|
Encoded successfully as .jxl at `-q 30`...
|
|
2021-03-20 03:33:20
|
...but re-encoding that thing to JPG during JXL decoding? No way.
|
|
2021-03-20 03:34:58
|
<@&803357352664891472> what should be decoder's behavior when asked to decode alpha-enabled JXL image and re-encode it to a format without alpha support (e.g. JPG)?
|
|
|
|
spider-mario
|
2021-03-20 03:36:43
|
by decoder, you mean djxl specifically, right?
|
|
|
|
Deleted User
|
|
spider-mario
by decoder, you mean djxl specifically, right?
|
|
2021-03-20 03:37:09
|
<:YEP:808828808127971399>
|
|
2021-03-20 03:39:38
|
Because other decoders that use libjxl can specify their own behavior, I guess (strip alpha, mix RGB+alpha with background color specified in PNG header or via argument, encode RGB and alpha to 2 separate files, throw an error etc.)
|
|
|
|
_wb_
|
2021-03-20 03:41:07
|
What does djxl do right now? Fail or just warn and give you the rgb without alpha?
|
|
2021-03-20 03:42:01
|
I don't have a strong opinion on what djxl should do
|
|
|
|
Deleted User
|
|
_wb_
What does djxl do right now? Fail or just warn and give you the rgb without alpha?
|
|
2021-03-20 03:42:01
|
Complete failure.
```PS C:\Users\zieme\Downloads> .\jpeg-xl-f2aeba7e-mingw64\djxl -j .\PNG_transparency_demonstration_1.jxl .\PNG_transparency_demonstration_1.jpg
Read 24659 compressed bytes [v0.3.4 | SIMD supported: SSE4,Scalar]
Decoded to pixels.
Failed to write decoded image.```
|
|
2021-03-20 03:43:09
|
Maybe it should mix RGB+alpha with white background, just like Windows Photo Viewer, MS Paint and other alpha non-supporting-but-understanding software do?
|
|
2021-03-20 03:44:26
|
They do understand alpha and properly mix it with default (white) background, but they can't view alpha and MS Paint strips alpha from such mixed images while saving a file.
|
|
|
|
_wb_
|
2021-03-20 03:45:22
|
Not sure if silently removing alpha is good, I guess it depends a lot on the use case
|
|
2021-03-20 03:46:37
|
We should give a nicer error (or warning) in any case, I think you need a non-release build to see why it failed to write the result, which is not very user friendly...
|
|
|
|
Deleted User
|
2021-03-20 03:49:30
|
Maybe a warning while using `-j` or `--jpeg-quality`?
```WARNING: this image has alpha channel which isn't supported by JPEG.
Alpha channel will be mixed into RGB data.```
|
|
2021-03-20 03:54:07
|
I tried making this text with that "formal" spirit so you can directly copy-paste this string if you decide to make warning default behavior
|
|
2021-03-20 03:55:28
|
Or maybe error scenario?
```ERROR: this image has alpha channel which isn't supported by JPEG.
Use --mix_alpha in order to mix alpha channel into RGB data.```
|
|
2021-03-20 03:55:59
|
That'd require a brand-new switch, `--mix_alpha`. It could be used with any image format, including those that do support alpha if user wants to throw it out for whatever reason.
|
|
|
|
_wb_
|
2021-03-20 03:56:22
|
It currently does give an error, but you don't see it in a release build
|
|
2021-03-20 03:58:45
|
We should avoid adding new functionality to cjxl/djxl for now, first we need to rewrite those tools to use libjxl. Anything we add now is likely to make it more work to rewrite later.
|
|
|
|
Deleted User
|
|
_wb_
We should avoid adding new functionality to cjxl/djxl for now, first we need to rewrite those tools to use libjxl. Anything we add now is likely to make it more work to rewrite later.
|
|
2021-03-20 04:06:48
|
> first we need to rewrite those tools to use libjxl
That's a good point. I suspect it'd actually be easier to solve alpha-in-JPG problem after the rewrite, because the `libjxl`'s decoder would just spit out pixel data and `djxl` would only have to deal with writing that to a file, am I right?
|
|
|
|
_wb_
|
|
> first we need to rewrite those tools to use libjxl
That's a good point. I suspect it'd actually be easier to solve alpha-in-JPG problem after the rewrite, because the `libjxl`'s decoder would just spit out pixel data and `djxl` would only have to deal with writing that to a file, am I right?
|
|
2021-03-20 04:24:01
|
That's already kind of how it is now, but now we use the internal image data representation and call the encoder/decoder with internal functions, instead of using the api. That's because cjxl/djxl existed before the libjxl api existed.
|
|
2021-03-20 04:25:51
|
But it means that cjxl/djxl now have a copy of libjxl in the binary, which is wasteful. They could be just small binaries that dynamically link with libjxl.
|
|
|
|
Deleted User
|
2021-03-20 05:55:29
|
From <#805007255061790730>:
Why does JPEG XL look like LSD in fully transparent areas of an image?
|
|
2021-03-20 05:55:30
|
https://discord.com/channels/794206087879852103/805007255061790730/822890261369716736
|
|
|
|
_wb_
|
2021-03-21 10:13:00
|
(answered there)
|
|
2021-03-21 10:15:10
|
<@179701849576833024> is bringing nice decode speedups, which is good for phones where it does actually matter
|
|
2021-03-21 10:15:15
|
|
|
2021-03-21 10:16:11
|
This brings us to 60-80% of libjpeg-turbo for single-core decoding on ARM
|
|
2021-03-21 10:23:48
|
Not sure what speed latest dav1d gets on ARM, something like 30-40% of libjpeg-turbo? (do you have numbers on that, <@179701849576833024> ?)
|
|
|
|
veluca
|
|
_wb_
This brings us to 60-80% of libjpeg-turbo for single-core decoding on ARM
|
|
2021-03-21 11:02:48
|
With a few footnotes, ie. Without filters :P
|
|
|
_wb_
Not sure what speed latest dav1d gets on ARM, something like 30-40% of libjpeg-turbo? (do you have numbers on that, <@179701849576833024> ?)
|
|
2021-03-21 11:03:20
|
I think around 33% is the most accurate figure I have, but I will be measuring more
|
|
|
Jim
|
2021-03-21 11:07:19
|
https://tenor.com/view/clap-clapping-applause-applaud-cheerleader-gif-17331667
|
|
|
|
_wb_
|
|
veluca
With a few footnotes, ie. Without filters :P
|
|
2021-03-21 11:19:11
|
https://c.tenor.com/Smyb95lMu_IAAAAM/we-dont-need-all-the-details-adam-driver.gif
|
|
|
|
veluca
|
2021-03-21 11:20:33
|
:D
|
|
2021-03-21 11:21:04
|
This is in part thanks to an encoding option that creates files that are faster to decode
|
|
|
|
_wb_
|
2021-03-21 11:23:45
|
`cjxl --decode_speed roadrunner`
https://c.tenor.com/AuUT6KdytZ4AAAAM/road-runner-running.gif
|
|
2021-03-21 11:24:44
|
We need to come up with cartoon characters and actually call the option that way
|
|
2021-03-21 11:26:25
|
Which one is faster, speedy Gonzales or Road Runner?
https://c.tenor.com/lMMpAi146ZsAAAAM/jerry-run.gif
|
|
|
|
spider-mario
|
2021-03-21 11:30:22
|
maybe “hedgehog” should be the fastest setting
|
|
2021-03-21 11:30:25
|
|
|
2021-03-21 11:34:28
|
and `--all_systems_full_power` the slowest (enables exhaustive search for every feature)
|
|
2021-03-21 11:34:30
|
https://youtu.be/MXnI1Ul_THI
|
|
|
|
_wb_
|
2021-03-21 11:35:53
|
Real animals for encode speed, cartoon characters for decode speed?
|
|
2021-03-21 11:39:05
|
`asterix, roadrunner, sonic` ?
|
|
2021-03-21 11:40:41
|
Obelix being the default
|
|
2021-03-21 11:48:17
|
https://www.thetoptens.com/fastest-cartoon-characters/
|
|
2021-03-21 11:54:54
|
tom, jerry, bugsbunny, speedygonzales, roadrunner, sonic
|
|
2021-03-21 11:55:00
|
Default being jerry
|
|
2021-03-21 11:56:48
|
(tom would be a future encode setting for "i don't care much about decode speed")
|
|
2021-03-21 12:06:13
|
We may want to have 3 different kinds of speed/effort scales:
- cjxl encode effort (more effort means encoding takes longer and may give better quality and/or density)
- cjxl (anticipated) decode effort (more effort means decoding is expected to take longer, e.g. because relatively slow filters are used)
- djxl decode accuracy (allowing to sacrifice some accuracy for more decode speed, e.g. if you don't care about off-by-ones in the decoded pixel values)
|
|
2021-03-21 12:16:15
|
For that last one, maybe we could use a completely different analogy, maybe `--accuracy atomic, molecular, cellular` or something like that
|
|
2021-03-21 12:29:12
|
Maybe we should deprecate -s, --speed and call it -e, --encode_effort instead. Scale from 1 to 11 where more means more effort (and currently only 3 to 9 are in use). Can use animal names falcon, cheetah, hare, wombat, squirrel, kitten, tortoise instead.
|
|
|
|
spider-mario
|
2021-03-21 12:29:19
|
I think I might favor “precision” over “accuracy” but not sure
|
|
2021-03-21 12:30:58
|
(based on this)
|
|
|
|
_wb_
|
2021-03-21 12:32:17
|
And then have -d, --decode_effort which is also a scale from 1 to 11 where more means more effort (and currently only 4 to 8 are in use). Can use cartoon character names sonic, roadrunner, gonzales, bugs, jerry instead.
|
|
|
spider-mario
(based on this)
|
|
2021-03-21 12:35:14
|
I suppose faster decode settings will do a bit of both? But yes, probably more a kind of precision loss than accuracy loss.
|
|
2021-03-21 12:40:42
|
Atomic Jerry squirrel would be the default
|
|
2021-03-21 12:41:45
|
But Cellular Sonic Wombat would make sense for many use cases
|
|
2021-03-21 12:42:23
|
Or Molecular Bugs Kitten, maybe
|
|
2021-03-21 01:00:48
|
Though I guess decode speed will remain only a compile-time option, not a runtime one
|
|
|
|
Scope
|
2021-03-21 01:17:05
|
|
|
2021-03-21 01:27:49
|
And `-e, --encode_effort` is a good idea, a more usual and logical name
|
|
|
|
jjido
|
2021-03-21 05:56:29
|
The "Features" section is quite different between English and Italian Wikipedia articles. The references are distinct too.
Which one is better?
|
|
2021-03-21 05:57:56
|
I am translating to French.
|
|
|
Petr
|
|
jjido
The "Features" section is quite different between English and Italian Wikipedia articles. The references are distinct too.
Which one is better?
|
|
2021-03-21 06:19:21
|
The best one is Czech. 🙂 Now seriously: The Czech article has more items in the proposed support than the English one. And the Features section should be the best in the English one since it was written/checked by Jon (JXL author).
|
|
|
|
_wb_
|
2021-03-21 06:26:19
|
The Features section in English is mostly based on the jxl white paper
|
|
2021-03-21 06:26:55
|
http://ds.jpeg.org/whitepapers/jpeg-xl-whitepaper.pdf
|
|
2021-03-21 06:27:24
|
There's probably other things in there that can be put in the wikipedia article
|
|
|
|
jjido
|
2021-03-21 06:33:06
|
I am using the English version
|
|
|
|
_wb_
|
2021-03-21 06:33:44
|
Would it make sense to have the codec architecture block diagram from the white paper in the wikipedia article?
|
|
|
|
Deleted User
|
|
Petr
The best one is Czech. 🙂 Now seriously: The Czech article has more items in the proposed support than the English one. And the Features section should be the best in the English one since it was written/checked by Jon (JXL author).
|
|
2021-03-21 06:35:51
|
You wrote in the Czech version: *JPEG XL has following properties*, which means to me "list as many features as possible", while in other languages (including Polish) it's *The **main** features are*, so features that Artoria2e5 (that wrote the original English bullet-point list) didn't consider that much important were omitted.
|
|
|
|
fab
|
2021-03-21 06:36:52
|
that because how the codec works i wrote i from english with google translate
|
|
2021-03-21 06:36:57
|
and not crixis and mannivu
|
|
2021-03-21 06:37:11
|
so i don't know if is perfect
|
|
2021-03-21 06:37:16
|
english probably is the best
|
|
2021-03-21 06:37:26
|
italian is marked as without linking
|
|
2021-03-21 06:38:03
|
features crixis wrote them
|
|
2021-03-21 06:38:13
|
https://web.archive.org/web/20190803230340/https://jpeg.org/items/20190803_press.html
|
|
2021-03-21 06:38:20
|
and used this link
|
|
2021-03-21 06:39:03
|
spanish is not in spanish but a translation of italian
|
|
2021-03-21 06:43:19
|
i hope there are not references in italian
|
|
2021-03-21 06:43:41
|
i think not
|
|
|
|
jjido
|
2021-03-21 07:17:41
|
By "Haar-like transform" do you mean wavelets? Do I need to mention Haar at all?
|
|
|
|
veluca
|
2021-03-21 07:22:16
|
tldr: replace two neighbouring pixels with (a+b)/2, a-b-magic_tendecy_parameter - so I *think* it can be considered a wavelet but I am not sure
|
|
2021-03-21 07:22:36
|
(magic_tendecy_parameter is not a linear function of anything though)
|
|
|
|
_wb_
|
2021-03-21 07:22:46
|
It's the most simple wavelet
|
|
|
|
veluca
|
2021-03-21 07:22:46
|
<@!794205442175402004> likely has a better idea 😛
|
|
|
|
jjido
|
2021-03-21 07:23:01
|
Thanks _wb_
|
|
|
|
_wb_
|
2021-03-21 07:23:07
|
Calling it a wavelet is a bit of overkill imo
|
|
|
|
veluca
|
2021-03-21 07:23:22
|
well, a haar-transform *is* a wavelet, so.. 😛
|
|
|
|
jjido
|
2021-03-21 07:23:38
|
I didn't find a good French equivalent of "Haar-like transform"
|
|
|
|
_wb_
|
2021-03-21 07:23:47
|
Yes but it's nothing like the DWT of j2k, for example
|
|
|
|
jjido
|
2021-03-21 07:23:59
|
wavelet is straightforward to say
|
|
|
|
_wb_
|
2021-03-21 07:24:11
|
I would call it "modified Haar transform"
|
|
2021-03-21 07:24:22
|
Or "modified Haar wavelet"
|
|
|
|
veluca
|
2021-03-21 07:24:27
|
haar is a DWT
|
|
|
|
_wb_
|
2021-03-21 07:26:41
|
Yes, I just wouldn't call it a wavelet without saying it's a Haar one, because that gives the impression it's a complicated one while it is only (a+b)/2
|
|
2021-03-21 07:31:48
|
The 'special' thing about it is the non-linear tendency term, which acts as a selective interpolation: in locally monotonic regions, it interpolates, while in nonmonotonic regions, it doesn't, which helps to avoid ringing/overshoot (at the cost of blockiness in 'busy' regions)
|
|
|
|
veluca
|
2021-03-21 07:32:53
|
I'm still a bit sad that we couldn't make that work in two dimensions 😄
|
|
|
|
_wb_
|
2021-03-21 07:35:42
|
Well at least you can alternate between dimensions, it's not like you first squeeze all the way vertically and then all the way horizontally
|
|
|
|
veluca
|
2021-03-21 07:36:38
|
sure, but at very low qualities you can see a bit of staircasing at edges with this, and a "native" 2d method would likely have managed to get rid of that
|
|
2021-03-21 07:36:40
|
oh well 😄
|
|
2021-03-21 07:38:23
|
would perhaps have been useful for anime/graphics, but I guess we can make something like that as an extension (providing an alternative upsampling method)
|
|
|
|
_wb_
|
2021-03-21 07:46:41
|
Yes, native 2d squeeze would be cool, put it on the list for "jxl 2" 😅
|
|
|
|
jjido
|
2021-03-21 08:09:46
|
"a pixel-by-pixel decorrelator without side information" is that same as "a context-free pixel-by-pixel decorrelator"?
|
|
2021-03-21 08:10:24
|
I want to use non contextual in French version
|
|
|
|
_wb_
|
2021-03-21 08:13:55
|
Hm, I don't really like the original English here, not sure what it means
|
|
2021-03-21 08:14:12
|
Vague abstract descriptions are confusing
|
|
2021-03-21 08:15:13
|
Is this about predictors in modular? About RCTs? About chroma from luma? (but that one does have signalled info)
|
|
|
|
jjido
|
2021-03-21 08:15:44
|
I can take it out
|
|
|
|
_wb_
|
2021-03-21 08:16:12
|
Context-free is in any case confusing because the word context is usually used in the context of context modeling
|
|
|
|
jjido
|
2021-03-21 08:17:19
|
I don't know another word for "side information" than "contexte"
|
|
|
|
_wb_
|
2021-03-21 08:19:10
|
Just drop the side information thing, it doesn't make much sense to begin with
|
|
2021-03-21 08:20:28
|
That sentence might even refer to something that is not even in the codec anymore, like HF prediction from LF
|
|
|
|
jjido
|
|
|
_wb_
|
2021-03-21 08:24:00
|
At some point we're going to have to write a book on jxl, before we forget all the stuff that's in it and why things are what they are 😅
|
|
|
|
Deleted User
|
|
_wb_
That sentence might even refer to something that is not even in the codec anymore, like HF prediction from LF
|
|
2021-03-21 09:05:24
|
> HF prediction from LF
Was it *really* part of the code? <:DogWhat:806133035786829875> When? WD? CD? Early DIS? And why was it scrapped? Because that'd sound like a good idea!
|
|
|
|
Jim
|
2021-03-21 09:23:46
|
Everything You Ever Wanted To Know About JXL But Were Afraid To Ask
|
|
|
|
jjido
|
2021-03-21 09:34:55
|
French translation: https://gist.github.com/jido/3ba153a435a9f55da2254448f820c3d3
|
|
|
|
veluca
|
|
> HF prediction from LF
Was it *really* part of the code? <:DogWhat:806133035786829875> When? WD? CD? Early DIS? And why was it scrapped? Because that'd sound like a good idea!
|
|
2021-03-21 11:07:10
|
there also was LF from DC 😄 I think at CD it was there, but I'm not certain...
|
|
2021-03-21 11:08:30
|
it does sound like a good idea, but it didn't work 😄 I suspect that if we were to redesign those today, they'd work better, but at the time I looked at the results and noticed they didn't really improve things
|
|
2021-03-21 11:08:46
|
and they were slow and a lot of code, so...
|
|
|
sivertba
|
2021-03-22 07:54:12
|
Dear smart ppl,
> Version 0.4: Full bitstream freeze (March 2021?)
> No more forwards-incompatible changes after this
> (decoder version 0.4 can decode bitstreams from future encoders)
Will there be a new release in the next couple of days covering this?
|
|
|
|
Deleted User
|
2021-03-22 07:55:23
|
Full bitstream freeze in March 2021 was just a rough estimate. I think <@794205442175402004> should change it to April.
|
|
2021-03-22 07:57:14
|
There are some notable things that'd break full bitstream freeze, e.g. raw (non-demosaiced Bayer matrix) camera images. The bistream is ready for that, but exact things and decoder support aren't specified yet. It's unusual input, so it'd definitely break Bayer non-supporting supporting decoder.
|
|
|
|
_wb_
|
2021-03-22 08:00:38
|
Well, we can have codestream bitstream freeze and consider camera raw metadata as a file format thing, same as 360 metadata.
|
|
2021-03-22 08:01:54
|
<@!604964375924834314> was working on blend modes, no idea how close that is to being complete
|
|
2021-03-22 08:02:30
|
not sure if there's anything else that is still blocking
|
|
2021-03-22 08:03:01
|
March 2021 is optimistic for 0.4, but the month is not over yet 🙂
|
|
|
|
Deleted User
|
2021-03-22 08:03:26
|
How would JPEG XL code weird mosaic patterns, e.g. X-Trans?
|
|
2021-03-22 08:06:16
|
And even with original Bayer matrix you could code it in multiple ways, e.g. interpolate to full-resolution image and code as usual with metadata which pixels were original and which ones were interpolated, or code each non-demosaiced separately (and even then you have to decide if you decouple greens or not – RG₁G₂B vs R(G₁+G₂)B(G₁-G₂), respectively).
|
|
|
|
spider-mario
|
|
How would JPEG XL code weird mosaic patterns, e.g. X-Trans?
|
|
2021-03-22 08:26:17
|
I suppose we could encode the pattern in some metadata like DNG does
|
|
|
Orum
|
2021-03-22 08:33:33
|
Does it need to support that kind of thing? Seems outside the scope of what it's intended for
|
|
|
|
_wb_
|
2021-03-22 09:31:28
|
It doesn't _need_ to support that, but it could. As long as it has some kind of RGB in the 'main' image and the rest in extra channels, naive decoders can just show a half-resolution or whatever image, and fancy decoders can look at the metadata in the file format and at the extra channel(s) and do whatever fancy debayering it wants to do
|
|
2021-03-22 09:36:44
|
We _could_ make a DNG replacement with better compression and a lossy option that way, with the advantage that the files would also display _something_ (not the full res image, but an ok half-res image) in any jxl-supporting software like browsers or file system explorers
|
|
2021-03-22 09:36:58
|
We could do the same for PSD/TIFF/XCF by the way
|
|
2021-03-22 09:37:28
|
The "JPEG reconstruction data" approach could be generalized to all of these formats
|
|
|
|
Orum
|
2021-03-22 09:37:41
|
I'd love a free alternative to DNG
|
|
|
|
_wb_
|
2021-03-22 09:40:18
|
the X-Trans pattern is indeed a bit annoying in that respect
|
|
2021-03-22 09:40:20
|
|
|
|
|
spider-mario
|
|
Orum
I'd love a free alternative to DNG
|
|
2021-03-22 09:41:57
|
in what ways would you say DNG is not sufficiently free?
|
|
|
|
Orum
|
2021-03-22 09:42:10
|
is the larger green pixel actually a single pixel, or a 2x2?
|
|
|
|
spider-mario
|
2021-03-22 09:42:16
|
2×2 AFAIK
|
|
|
|
_wb_
|
2021-03-22 09:42:18
|
I assume 2x2
|
|
|
|
Orum
|
|
spider-mario
in what ways would you say DNG is not sufficiently free?
|
|
2021-03-22 09:43:18
|
it's still patented, and the license can be revoked by Adobe
|
|
|
|
_wb_
|
2021-03-22 09:43:33
|
if it wasn't for that 2x2 green, you could still see it as R G1 G2 B where the layout just alternates between groups
|
|
2021-03-22 09:48:49
|
I suppose you can see it in 3x3 groups that each have 2 R, 2 B and 5 G pixels. Then encode avg(R), avg(B), center-G and have 3 extra channels with diffR, diffB, and a G channel with 2x2 pixels per 3x3 group.
|
|
2021-03-22 09:53:22
|
I'm all for replacing Adobe formats with open standards with a FOSS implementation. Interoperability should not be something between different Adobe products.
|
|
|
Lastrosade
|
2021-03-22 12:53:17
|
huh from matrix
|
|
|
Fox Wizard
|
2021-03-22 01:01:25
|
<:kekw:758892021191934033>
|
|
|
|
_wb_
|
2021-03-22 01:14:22
|
second spammer from the integration with matrix, is there anything I can do to stop them besides killing the integration with matrix?
|
|
|
|
Orum
|
2021-03-22 03:58:52
|
ban them on the other end?
|
|
|
BlueSwordM
|
2021-03-22 04:02:44
|
People.
|
|
2021-03-22 04:02:49
|
Excellent news.
|
|
2021-03-22 04:02:58
|
OpenManDriva(on the Cooker branch) Linux now has native JPEG-XL support.
|
|
|
|
_wb_
|
2021-03-22 04:07:26
|
https://tenor.com/view/nice-nooice-bling-key-and-peele-gif-4294979
|
|
|
|
BlueSwordM
|
2021-03-22 04:08:23
|
Now, we just need to convince the Debian folks to do that after libjxl 0.4 comes out...
|
|
|
|
Nova Aurora
|
|
BlueSwordM
Now, we just need to convince the Debian folks to do that after libjxl 0.4 comes out...
|
|
2021-03-22 04:11:32
|
If you get that in fedora 35, you might see it in RHEL in your lifetime
|
|
|
|
Fox Wizard
|
2021-03-22 04:13:20
|
<:FedoraTip:788619108491984926>
|
|
|
|
Nova Aurora
|
2021-03-22 04:15:06
|
Fedora 34 is a pretty exciting release, there getting in all their changes to test before the next RHEL release
|
|
|
|
BlueSwordM
|
|
Nova Aurora
Fedora 34 is a pretty exciting release, there getting in all their changes to test before the next RHEL release
|
|
2021-03-22 04:19:54
|
Actually, I think a better idea would be to ask the Fedora folks *now* to integrate JPEG-XL. <:megapog:816773962884972565>
|
|
|
|
Nova Aurora
|
|
BlueSwordM
Actually, I think a better idea would be to ask the Fedora folks *now* to integrate JPEG-XL. <:megapog:816773962884972565>
|
|
2021-03-22 04:24:50
|
https://bugzilla.redhat.com/show_bug.cgi?id=1922638 Doesn't seem like anyone's doing anything
|
|
|
|
BlueSwordM
|
2021-03-22 04:38:15
|
Well, let's give that a bump. The more OSes support JXL natively, the more likely browsers will implement JXL support, and after, the ball will start steamrolling.
|
|
|
|
diskorduser
|
2021-03-22 04:58:43
|
I need jpeg xl on arch linux repos. 😫
|
|
2021-03-22 04:59:16
|
I have even tried asking them on package request reddit thread.
|
|
|
190n
|
2021-03-22 04:59:23
|
it's in the aur if you don't mind compiling
|
|
|
|
diskorduser
|
|
190n
it's in the aur if you don't mind compiling
|
|
2021-03-22 04:59:44
|
yeah. It's in archlinux china repo too
|
|
2021-03-22 05:00:25
|
I have asked chinese repo maintainers to include it hehe
|
|
|
Jyrki Alakuijala
|
2021-03-22 06:10:48
|
the best camera matrix would be mostly yellow and green pixels with some blue pixels, red pixels are not needed
|
|
2021-03-22 06:11:53
|
possibly even better if white pixels, cyan pixels and blue pixels
|
|
|
Nova Aurora
https://bugzilla.redhat.com/show_bug.cgi?id=1922638 Doesn't seem like anyone's doing anything
|
|
2021-03-22 06:22:30
|
that would cause/force us to improve on our security incident reporting
|
|
2021-03-22 06:22:42
|
but it is time for that in any case very soon
|
|
|
|
_wb_
|
|
Jyrki Alakuijala
the best camera matrix would be mostly yellow and green pixels with some blue pixels, red pixels are not needed
|
|
2021-03-22 06:24:59
|
New Bayer pattern
|
|
|
|
spider-mario
|
2021-03-22 07:36:06
|
<@!263309374775230465> that’s roughly the distribution of cones in a human retina
|
|
2021-03-22 07:36:23
|
(but the choice of red for the L cones is a simplification)
|
|
|
|
_wb_
|
2021-03-22 07:42:37
|
real peaks are more like yellowish green, green and blue
|
|
|
|
spider-mario
|
2021-03-22 07:47:27
|
true, and actually I will revise my statement to “the choice of all colors to represent cones is a simplification”
|
|
2021-03-22 07:48:30
|
they are sensitive to a whole range of frequencies with peaks that just happen to correspond to wavelengths that would look yellow/green/blue under typical illumination
|
|
2021-03-22 07:52:17
|
in “Colour Reproduction in Electronic Imaging Systems”, they chose these colors:
|
|
2021-03-22 07:52:43
|
and I vaguely recall another source which used yet another set of arbitrary colors (and insisted on their arbitrary character)
|
|
|
|
fab
|
2021-03-22 08:33:48
|
palette speed 6 -q 100
-q 87.1 -s 8
|
|
2021-03-22 08:34:15
|
can a double parameter improve quality of the compression? does it make sense?
|
|
2021-03-22 08:34:34
|
first i need to check if speed 6 is enabled
|
|
|
|
BlueSwordM
|
|
fab
can a double parameter improve quality of the compression? does it make sense?
|
|
2021-03-22 08:34:39
|
No.
|
|
|
|
fab
|
2021-03-22 08:36:30
|
so this isn't compression to you?
|
|
|
|
BlueSwordM
|
|
fab
so this isn't compression to you?
|
|
2021-03-22 08:37:03
|
No, it's just that only one parameter of each will be saved.
|
|
|
|
fab
|
2021-03-22 08:38:46
|
what it means one parameter
|
|
|
|
BlueSwordM
|
|
fab
what it means one parameter
|
|
2021-03-22 08:40:07
|
Only do `-s 8` or `-s 6`
|
|
2021-03-22 08:40:11
|
Not both at the same time.
|
|
|
|
fab
|
2021-03-22 08:42:17
|
does compression need to be applied in every image?
|
|
2021-03-22 08:42:42
|
do you need to have more than 22% compression?
|
|
|
|
_wb_
|
2021-03-22 08:43:33
|
you ask very philosophical questions
|
|
|
Scientia
|
2021-03-23 01:05:48
|
I'd say yes compression should be applied to every image except in some real time or other special cases
|
|
2021-03-23 01:06:07
|
The 22% thing is totally dependent on your application
|
|
|
Troc
|
2021-03-23 01:21:08
|
Is there an Android jxl viewer yet?
|
|
|
|
190n
|
2021-03-23 01:26:13
|
djxl in termux <:galaxybrain:821831336372338729>
|
|
|
|
Troc
|
2021-03-23 01:33:02
|
Can Gimp open JXL?
|
|
|
|
Scientia
|
2021-03-23 01:37:17
|
With a plugin probably
|
|
2021-03-23 01:37:29
|
I don't know how to build the plugins though
|
|
2021-03-23 01:37:43
|
I think the source for them is in the jxl repo
|
|
|
|
diskorduser
|
|
Troc
Can Gimp open JXL?
|
|
2021-03-23 03:38:53
|
`
libjpeg-xl /usr/lib/gimp/2.0/plug-ins/file-jxl/file-jxl` Plugin is there but I've gimp 2.99 so idk.
|
|
2021-03-23 03:46:48
|
It opens with plugin. 🙂
|
|
|
|
Petr
|
2021-03-23 06:52:42
|
Yes, this is a minor bug which should be fixed in the next version.
|
|
|
|
fab
|
2021-03-23 07:23:31
|
modular is crashing on my pc
|
|
2021-03-23 07:23:42
|
but my pc is old and is a laptop
|
|
2021-03-23 07:24:02
|
for %i in (C:\Users\User\Documents\ims\*.png) do cjxl "%i" "%i.jxl" -m -q 81.7 -P 11 --num_threads=2
|
|
2021-03-23 07:24:28
|
i can't use jpeg xl without this command orum gave me
|
|
2021-03-23 07:24:38
|
i don't even know what shells support it
|
|
|
|
_wb_
|
2021-03-23 09:11:13
|
I have just made a silly merge request
|
|
|
|
spider-mario
|
2021-03-23 09:19:47
|
3279?
|
|
2021-03-23 09:20:02
|
fancy
|
|
|
|
_wb_
|
2021-03-23 09:34:27
|
does that work on Windows?
|
|
|
|
veluca
|
2021-03-23 09:55:49
|
IIRC yes as long as you just use the most basic escape codes
|
|
|
|
spider-mario
|
2021-03-23 09:59:15
|
doesn’t look like it, sadly
|
|
|
|
_wb_
|
2021-03-23 10:00:03
|
Sigh
|
|
2021-03-23 10:01:20
|
It worked in DOS, why did they have to break it
|
|
2021-03-23 10:03:45
|
I wanted to do this
|
|
2021-03-23 10:04:41
|
but we'll do a more boring single-line thing instead, it's more portable and accessible...
|
|
2021-03-23 10:07:55
|
|
|
|
|
Scope
|
2021-03-23 10:11:20
|
Yes, color output even only in Windows works in some places and breaks in others
|
|
|
|
Lastrosade
|
2021-03-23 10:11:52
|
Hey, I'm compiling jpegxl with ENABLE_EXAMPLES and ENABLE_PLUGINS but I have no idea where the products are
|
|
|
|
veluca
|
2021-03-23 10:12:11
|
examples should be in build/examples I believe
|
|
|
|
Lastrosade
|
2021-03-23 10:12:33
|
|
|
2021-03-23 10:12:39
|
there is no build
|
|
|
|
veluca
|
2021-03-23 10:12:46
|
how are you building?
|
|
|
|
Lastrosade
|
2021-03-23 10:13:14
|
through msys2
|
|
|
|
veluca
|
2021-03-23 10:13:23
|
with what command?
|
|
|
|
Lastrosade
|
2021-03-23 10:13:46
|
its a script https://github.com/m-ab-s/media-autobuild_suite
|
|
|
|
veluca
|
2021-03-23 10:14:01
|
ah... I don't know what it does for jxl, let me check
|
|
2021-03-23 10:14:50
|
mh, ok, they don't have a separate build dir
|
|
2021-03-23 10:14:55
|
so just in examples/?
|
|
|
|
Scope
|
2021-03-23 10:14:55
|
m-ab-s removes the builds directory after compilation
|
|
|
|
veluca
|
2021-03-23 10:15:20
|
I'll leave this to somebody who actually knows what they're talking about 😛
|
|
|
|
Lastrosade
|
2021-03-23 10:16:05
|
I am extra confused as the script does not even mention the build dir
|
|
|
|
Scope
|
2021-03-23 10:20:47
|
I think it is possible to terminate the scripts at the end of compilation, but before deleting/moving files (like Alt+F4 or close the console)
|
|
|
|
Lastrosade
|
2021-03-23 10:23:50
|
Man I hate computers
|
|
|
|
Petr
|
|
Scope
I think it is possible to terminate the scripts at the end of compilation, but before deleting/moving files (like Alt+F4 or close the console)
|
|
2021-03-23 10:23:51
|
That's like scratching one's right ear with one's left leg. 🙂 (Just a joke. I don't know myself how to improve it.)
|
|
|
|
Scope
|
2021-03-23 10:24:53
|
Yes, but it usually works if there is no time to understand how all the scripts work and change them
|
|
|
|
Lastrosade
|
2021-03-23 10:25:36
|
my 'solution'
```sh
echo "DO IT---"
sleep 20
```
|
|
|
|
spider-mario
|
2021-03-23 10:30:52
|
building with msys2 directly is also an option
|
|
2021-03-23 10:30:58
|
(that’s what I do)
|
|
|
|
Lastrosade
|
2021-03-23 10:31:10
|
ah but I am lazy
|
|
|
|
Troc
|
2021-03-23 10:35:59
|
Which plugin do I use?
|
|
|
|
Scope
|
2021-03-23 10:38:31
|
If I remember correctly, deleting files in m-ab-s happens after all compilations are complete, including ffmpeg, so `sleep` is not so necessary (although maybe not)
I mean script termination can be done while compiling ffmpeg or something else after Jpeg XL
|
|
|
|
Lastrosade
|
2021-03-23 10:38:57
|
I did the sleep so that I have the time to stop the script
|
|
2021-03-23 10:39:24
|
Now I can't find the gimp plugin
|
|
2021-03-23 10:39:45
|
I only get this in in the build-64bit/plugins dir
|
|
|
|
Troc
|
2021-03-23 10:41:37
|
Please link me the DLL.
|
|
|
|
spider-mario
|
2021-03-23 11:06:15
|
`-DJPEGXL_ENABLE_PLUGINS` needs to be passed to CMake
|
|
2021-03-23 11:06:19
|
the default is `No`
|
|
2021-03-23 11:06:36
|
the m-ab-s script probably doesn’t do that
|
|
|
|
Lastrosade
|
2021-03-23 11:06:53
|
Yes I added this
|
|
|
|
spider-mario
|
2021-03-23 11:07:00
|
also with mingw-w64-($arch)-gimp installed
|
|
|
|
Lastrosade
|
2021-03-23 11:07:12
|
ah
|
|
2021-03-23 11:21:59
|
Well I'll come back to this later
|
|
|
lithium
|
2021-03-23 02:42:14
|
A little curious, On march 31 we will get jpeg xl 0.3.5 or 0.4?
|
|
|
|
Deleted User
|
|
lithium
A little curious, On march 31 we will get jpeg xl 0.3.5 or 0.4?
|
|
2021-03-23 02:43:22
|
Probably 0.3.5, not everything is frozen yet (unless <@&803357352664891472>s have a pleasant surprise for us, but that's unlikely).
|
|
2021-03-23 02:44:10
|
libjxl 1.0 will come on April 1st, I'm sure ;)
|
|
|
|
lithium
|
|
Probably 0.3.5, not everything is frozen yet (unless <@&803357352664891472>s have a pleasant surprise for us, but that's unlikely).
|
|
2021-03-23 02:49:40
|
Thank you, I very look forward jpeg xl 0.3.5 🙂
|
|
|
|
Deleted User
|
2021-03-23 02:52:03
|
0.4 was meant to be a full bitstream freeze (so a non-updated decoder could decode files from an up-to-date encoder).
|
|
|
|
BlueSwordM
|
2021-03-23 02:55:47
|
Honestly, let them take time.
|
|
2021-03-23 02:56:02
|
I don't care if the 0.4 release in done in April or May or June.
|
|
2021-03-23 02:56:06
|
Let them take time. 😛
|
|
|
|
veluca
|
2021-03-23 03:16:30
|
Interesting tiny JXL image 😄
|
|
|
|
Scope
|
2021-03-23 03:25:32
|
143 870 (PNG)
|
|
|
|
_wb_
|
2021-03-23 03:28:07
|
https://discord.com/channels/794206087879852103/806898911091753051/823611569367547934
|
|
2021-03-23 03:28:20
|
he actually did it
|
|
2021-03-23 03:29:12
|
```
if c > 0
if y > 0
if N > 0
if NW-N > -1
if N-NE > 0
- Set 0
- Set 255
if N-NE > 0
- Set 255
- Set 0
if NW-N > 0
if N-NE > -1
- Set 255
- Set 0
if N-NE > -1
- Set 0
- Set 255
if x > 511
if x > 512
- Set 0
- Set 255
- Set 0
if N > 200
- Set 0
if W > 200
- Set 0
- Average1 + 1
```
|
|
2021-03-23 03:30:07
|
that's the MA tree description
|
|
2021-03-23 03:30:13
|
for the above image
|
|
2021-03-23 03:30:48
|
`c` is the channel (0 being red, 1 and 2 being green and blue), `y` is the row number
|
|
2021-03-23 03:31:04
|
`N` is value of pixel above (north)
|
|
2021-03-23 03:31:12
|
etc
|
|
|
|
Deleted User
|
|
_wb_
that's the MA tree description
|
|
2021-03-23 03:34:22
|
btw, what does MA stand for?
|
|
|
|
_wb_
|
2021-03-23 03:34:31
|
Meta-Adaptive
|
|
2021-03-23 03:35:05
|
the idea was first introduced in FLIF
|
|
2021-03-23 03:40:01
|
entropy coding can be
- non-adaptive: e.g. the old JPEG: same 'histogram' is used all the time
- adaptive: using a context model, different 'histograms' are used in different contexts, so the entropy coding 'adapts' to the context (but the context model itself is fixed)
- meta-adaptive: the context model _itself_ is not fixed, so you can adapt not just the histograms themselves but also the way they are chosen
|
|
|
|
Lastrosade
|
|
veluca
Interesting tiny JXL image 😄
|
|
2021-03-23 03:50:34
|
Very nice
|
|
|
|
Scope
|
2021-03-23 04:59:14
|
> * Bump JPEG XL version to 0.3.5.
> * Memory usage improvements.
> * New encode-time options for faster decoding at the cost of quality.
> * Faster decoding to 8-bit output with the C API.
> * GIMP plugin: avoid the sRGB conversion dialog for sRGB images, do not show
> a console window on Windows.
> * Various bug fixes.
> * Man pages for cjxl and djxl.
|
|
|
|
_wb_
|
2021-03-23 05:09:07
|
|
|
2021-03-23 05:13:07
|
```if c > 1
if N > 125
- Set 0
if W > 125
- Set 0
- AvgW+NW + 1
if y > 400
if N > 0
if WGH > 0
if N-NE > 0
- Set 0
- Set 128
if N-NE > 0
- Set 64
- Set 0
if NW-N > 0
if N-NE > -1
- Set 255
- Set 0
if N-NE > -1
- Set 0
- Set 255
if c > 0
if x > 0
if W > 253
- Set 0
if y > 100
if y > 270
- W + 1
if N > 252
- Set 0
- N + 3
- W + 1
- Set 0
if x > 511
- Set 200
- Set 0
```
|
|
2021-03-23 05:13:19
|
just playing with the example tree a bit
|
|
2021-03-23 05:13:44
|
now you can make small arty jxl files from a tree description yourself
|
|
2021-03-23 05:14:03
|
with tools/jxl_from_tree
|
|
|
|
Pieter
|
2021-03-23 05:19:18
|
What does "- Set 200\n- Set 0" mean?
|
|
|
|
_wb_
|
2021-03-23 05:22:53
|
Those last three lines mean: if x (the column number) is larger than 511, set the pixel value to 200, otherwise set it to 0
|
|
2021-03-23 05:24:21
|
This only applies to the Red channel though (it is in the else branch of c>0), and only for y below 400
|
|
|
|
Pieter
|
2021-03-23 05:25:59
|
Oh, I see. The two "subtrees" are the then and else branches.
|
|
|
|
_wb_
|
2021-03-23 05:26:33
|
Yes. Also the tool ignores whitespaces and probably I didn't indent correctly
|
|
|
|
Pieter
|
2021-03-23 05:28:35
|
Any way to write an actual histogram? That isn't just a single deterministic choice per branch?
|
|
|
|
_wb_
|
2021-03-23 05:34:06
|
Not with this tool atm. Could add that, but how to specify what the pixels should be then? Just let it pick at random according to the distribution of the histogram?
|
|
2021-03-23 05:34:23
|
(it would also lead to bigger files)
|
|
|
|
Pieter
|
2021-03-23 05:34:29
|
Yeah, that wouldn't be as interesting.
|
|
2021-03-23 05:35:20
|
Maybe it could be an advanced/debugging encoder mode, where you specify the tree, and it does a nearest-match encoding of the input pixels to the possibilities permitted by that tree.
|
|
2021-03-23 05:35:33
|
A lot more work, I imagine.
|
|
|
|
_wb_
|
2021-03-23 05:36:35
|
Could be fun, but yes, a lot more work
|
|
2021-03-23 05:37:06
|
Just playing with trees to see what they look like is kind of fun
|
|
|
|
Crixis
|
|
Scope
> * Bump JPEG XL version to 0.3.5.
> * Memory usage improvements.
> * New encode-time options for faster decoding at the cost of quality.
> * Faster decoding to 8-bit output with the C API.
> * GIMP plugin: avoid the sRGB conversion dialog for sRGB images, do not show
> a console window on Windows.
> * Various bug fixes.
> * Man pages for cjxl and djxl.
|
|
2021-03-23 05:39:41
|
any vardct change?
|
|
|
|
diskorduser
|
|
190n
djxl in termux <:galaxybrain:821831336372338729>
|
|
2021-03-23 05:54:37
|
Did you compile djxl in termux?
|
|
|
|
190n
|
2021-03-23 05:56:50
|
no but i probably could
|
|
|
|
diskorduser
|
|
|
veluca
|
2021-03-23 06:59:47
|
I do that every now and then, it's doable - even relatively fast if you have a good phone
|
|
|
|
lithium
|
2021-03-23 07:51:34
|
A little curious, probably jxl can like webp store some compress mode information in metadata?
example:
webp(Lossy), webp(Lossless)
jxl(VarDCT), jxl(LosslessTranscode), jxl(Modular)
|
|
|
|
_wb_
|
2021-03-23 08:03:11
|
Well the thing is, WebP is really two different codecs
|
|
2021-03-23 08:03:42
|
While in jxl it's more combined
|
|
2021-03-23 08:05:06
|
A losslessly recompressed jpeg is just another vardct image, one that happens to use only DCT8x8 and the YCbCr colorspace, but in principle you could have something that did not originate from a jpeg that also does that
|
|
2021-03-23 08:06:32
|
(though if there's a jpeg bitstream reconstruction data box in the container, then you know there's a jpeg to reconstruct - but the jxl could also contain non-jpeg frames or overlays, or an alpha channel)
|
|
2021-03-23 08:08:49
|
You can in principle have a multi-layer image where the bottom layer is a JPEG, which has been cut out to some shape by adding a Modular alpha channel, and the top layer adds a title which is Modular encoded and something else which is VarDCT encoded.
|
|
2021-03-23 08:09:12
|
Not that we have an encoder atm that does that, but it is possible.
|
|
|
|
veluca
|
|
_wb_
(though if there's a jpeg bitstream reconstruction data box in the container, then you know there's a jpeg to reconstruct - but the jxl could also contain non-jpeg frames or overlays, or an alpha channel)
|
|
2021-03-23 08:15:59
|
you could generate one such box without there ever having been an original JPEG though 😛
|
|
|
|
Scope
|
2021-03-23 08:30:41
|
Also <https://www.reddit.com/r/jpegxl/comments/mbksc7/jpeg_xl_reference_software_v035_released/>
|
|
2021-03-23 08:30:55
|
<https://ci.appveyor.com/project/EwoutH/jpeg-xl>
|
|
2021-03-23 08:32:38
|
Could also be added to the FAQ who wants Appveyor builds
|
|
2021-03-23 08:34:19
|
But 🤔
https://ci.appveyor.com/project/EwoutH/jpeg-xl/build/job/w3qgv80c868ydpbv
|
|
2021-03-23 08:36:11
|
|
|
|
Master Of Zen
|
2021-03-24 04:54:41
|
```
clang-11: error: clang frontend command failed due to signal (use -v to see invocation)
clang version 11.1.0
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
clang-11: note: diagnostic msg:
********************
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-11: note: diagnostic msg: /tmp/color_management_test-00ea57.cpp
clang-11: note: diagnostic msg: /tmp/color_management_test-00ea57.sh
clang-11: note: diagnostic msg:
********************
make[2]: *** [lib/CMakeFiles/color_management_test.dir/build.make:82: lib/CMakeFiles/color_management_test.dir/jxl/color_management_test.cc.o] Error 254
make[2]: Leaving directory '/home/zen/.cache/paru/clone/libjpeg-xl-git/src/build'
make[1]: *** [CMakeFiles/Makefile2:3396: lib/CMakeFiles/color_management_test.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....```
JPEG XL GIT
|
|
|
|
Pieter
|
|
NeRd
|
2021-03-24 06:02:11
|
Does anyone know why the Mac homebrew formula for JPEG-XL hasn't been building since v0.3.4? I tried to bump it to v0.3.5 just now, and I have no idea if I'm just doing something wrong because I don't know how homebrew formulas work. Here's the v0.3.5 PR attempt (https://github.com/Homebrew/homebrew-core/pull/73801), and here's some relevant errors according to a homebrew contributor who responded to the PR:
```
/tmp/jpeg-xl-20210324-62707-7huyw6/jpeg-xl-v0.3.5/lib/extras/codec_exr.cc:93:12: error: virtual function 'tellg' has a different return type ('uint64_t' (aka 'unsigned long long')) than the function it overrides (which has return type 'Imath_2_5::Int64' (aka 'unsigned long'))
uint64_t tellg() override { return pos_; }
~~~~~~~~ ^
/usr/local/Cellar/openexr/2.5.5/include/OpenEXR/ImfIO.h:117:19: note: overridden virtual function is here
virtual Int64 tellg () = 0;
~~~~~ ^
/tmp/jpeg-xl-20210324-62707-7huyw6/jpeg-xl-v0.3.5/lib/extras/codec_exr.cc:94:34: error: non-virtual member function marked 'override' hides virtual member function
void seekg(const uint64_t pos) override {
^
```
|
|
|
|
Deleted User
|
|
NeRd
Does anyone know why the Mac homebrew formula for JPEG-XL hasn't been building since v0.3.4? I tried to bump it to v0.3.5 just now, and I have no idea if I'm just doing something wrong because I don't know how homebrew formulas work. Here's the v0.3.5 PR attempt (https://github.com/Homebrew/homebrew-core/pull/73801), and here's some relevant errors according to a homebrew contributor who responded to the PR:
```
/tmp/jpeg-xl-20210324-62707-7huyw6/jpeg-xl-v0.3.5/lib/extras/codec_exr.cc:93:12: error: virtual function 'tellg' has a different return type ('uint64_t' (aka 'unsigned long long')) than the function it overrides (which has return type 'Imath_2_5::Int64' (aka 'unsigned long'))
uint64_t tellg() override { return pos_; }
~~~~~~~~ ^
/usr/local/Cellar/openexr/2.5.5/include/OpenEXR/ImfIO.h:117:19: note: overridden virtual function is here
virtual Int64 tellg () = 0;
~~~~~ ^
/tmp/jpeg-xl-20210324-62707-7huyw6/jpeg-xl-v0.3.5/lib/extras/codec_exr.cc:94:34: error: non-virtual member function marked 'override' hides virtual member function
void seekg(const uint64_t pos) override {
^
```
|
|
2021-03-24 06:06:10
|
I've heard that there were some problem with OpenEXR integration because they changed one of variable types that JPEG XL assumes to be used.
|
|
|
|
NeRd
|
|
I've heard that there were some problem with OpenEXR integration because they changed one of variable types that JPEG XL assumes to be used.
|
|
2021-03-24 06:11:16
|
Do you recon that this (https://gitlab.com/wg1/jpeg-xl/-/commit/f2aeba7e3d091314eaccb64748791e1f4e2cf0a6#0442ba75b1c9e65970a8c225708b9e10fee0631b) is the likely culprit?
|
|
|
|
Deleted User
|
|
NeRd
Do you recon that this (https://gitlab.com/wg1/jpeg-xl/-/commit/f2aeba7e3d091314eaccb64748791e1f4e2cf0a6#0442ba75b1c9e65970a8c225708b9e10fee0631b) is the likely culprit?
|
|
2021-03-24 06:34:12
|
That's supposed to *fix* OpenEXR bug (https://gitlab.com/wg1/jpeg-xl/-/issues/162)
|
|
|
|
_wb_
|
2021-03-24 06:47:16
|
Ah, right, I forgot about that. It fixes a problem with the latest openEXR, but introduces a problem with the non-latest openEXR on macOS
|
|
|
|
Petr
|
|
lithium
A little curious, probably jxl can like webp store some compress mode information in metadata?
example:
webp(Lossy), webp(Lossless)
jxl(VarDCT), jxl(LosslessTranscode), jxl(Modular)
|
|
2021-03-24 07:11:09
|
Great question IMHO!
|
|
|
_wb_
(though if there's a jpeg bitstream reconstruction data box in the container, then you know there's a jpeg to reconstruct - but the jxl could also contain non-jpeg frames or overlays, or an alpha channel)
|
|
2021-03-24 07:37:57
|
Technically it would be possible for jxlinfo to print "VarDCT" or "Modular" for every frame/channel, wouldn't it? I can imagine many users would find it useful.
|
|
|
|
_wb_
|
2021-03-24 07:49:41
|
That would be possible, yes.
|
|
2021-03-24 07:50:04
|
Note that Modular does not imply lossless though.
|
|
|
|
Petr
|
2021-03-24 07:58:38
|
I know…
|
|
2021-03-24 07:58:42
|
Just to conclude: Is it true that it's not possible to get the information about lossiness/losslessness from a modular frame itself?
|
|
|
|
_wb_
|
2021-03-24 08:04:00
|
You can guess that if there are no MA tree leaf nodes with a multiplier (which might mean something was quantized), the colorspace is RGB, and no palette transforms are done that uses delta entries, that it might be lossless, but that's more of a characterization of the current encoder than anything else.
|
|
2021-03-24 08:04:57
|
You could make an encoder that first pre-processes an image in the way lossy FLIF does it, and then there would be no way at all to tell whether it's lossy or lossless
|
|
|
|
Petr
|
2021-03-24 08:16:27
|
At least there are no DCT-like artifacts in modular, right? (Unless they were already on the encoder input.) 😜
|
|
|
|
Crixis
|
|
Petr
At least there are no DCT-like artifacts in modular, right? (Unless they were already on the encoder input.) 😜
|
|
2021-03-24 08:24:47
|
there are other type artifacts
|
|
|
Petr
At least there are no DCT-like artifacts in modular, right? (Unless they were already on the encoder input.) 😜
|
|
2021-03-24 08:28:55
|
Vardct d 6 vs same size modular
|
|
2021-03-24 08:29:36
|
original
|
|
|
|
Petr
|
2021-03-24 08:31:00
|
I see…
|
|
|
|
lithium
|
|
_wb_
Not that we have an encoder atm that does that, but it is possible.
|
|
2021-03-24 09:36:51
|
I understand, Thank you very much 🙂
|
|
|
|
diskorduser
|
2021-03-24 11:30:04
|
apng or image sequence -> animated jxl conversion. How?
|
|
|
|
spider-mario
|
|
diskorduser
apng or image sequence -> animated jxl conversion. How?
|
|
2021-03-24 11:32:28
|
cjxl supports apng
|
|
|
|
diskorduser
|
|
spider-mario
cjxl supports apng
|
|
2021-03-24 11:33:31
|
okay thanks!
|
|
|
|
Lastrosade
|
2021-03-24 11:41:08
|
but it doesn't support gif as far as I know
|
|
|
|
veluca
|
2021-03-24 11:41:19
|
it should...
|
|
|
|
_wb_
|
2021-03-24 11:43:30
|
It does
|
|
2021-03-24 11:43:56
|
Maybe for some gifs it says "meh, not gonna do that" though
|
|
2021-03-24 11:44:18
|
When they use that funky dispose mode
|
|
|
|
spider-mario
|
2021-03-24 11:44:49
|
you have perhaps not built with libgif installed
|
|
2021-03-24 11:44:52
|
I think we have made it optional
|
|
|
|
Lastrosade
|
2021-03-24 11:44:53
|
oh wait yes it does
|
|
2021-03-24 11:45:10
|
<:pog:600111651722756106>
|
|
2021-03-24 11:45:20
|
but is it good when lossy
|
|
|
|
spider-mario
|
2021-03-24 11:45:37
|
iirc, we default to lossless for gif input
|
|
|
|
_wb_
|
2021-03-24 11:46:53
|
Lossy should work though
|
|
|
|
Lastrosade
|
2021-03-24 11:52:00
|
Oh its avifenc that doesn't support gif
|
|
2021-03-24 11:52:09
|
it only takes y4m
|
|
2021-03-24 11:52:57
|
and since windows is funny with pipes, piping your gif into it requires the use of cmd AND you have to specify the framerate cause it doesn't read it from the y4m
|
|
|
|
fab
|
2021-03-24 11:55:39
|
which resolutions avifenc supports 100%?
|
|
2021-03-24 11:55:53
|
which resolutions cause avifenc to crash?
|
|
|
|
Jyrki Alakuijala
|
|
Crixis
Vardct d 6 vs same size modular
|
|
2021-03-24 11:56:57
|
I will make vardct d6 slightly better soon
|
|
|
|
lithium
|
2021-03-24 12:06:27
|
reverse the order of dct size selection to merge instead of split
This feature is implement in jpeg xl 0.3.5?
|
|
|
|
_wb_
|
2021-03-24 12:06:45
|
No
|
|
2021-03-24 12:07:20
|
Last few new versions have mostly focused on decode speed, memory reduction, and fixing bugs
|
|
2021-03-24 12:08:16
|
Those are the urgent things to do. Improving the encoder takes more time and is less urgent.
|
|
|
|
diskorduser
|
2021-03-24 12:08:54
|
The animated jxl larger than source gif. Is it normal? ( lossless 1.5 times)
|
|
2021-03-24 12:11:07
|
vardct jxl is 3x than source gif.
|
|
|
|
Lastrosade
|
2021-03-24 12:20:21
|
ok well, for now av1 seems to do better than jxl for animations which is not really surprising
|
|
|
|
NeRd
|
2021-03-24 01:02:49
|
Homebrew update: looks like the latest changes fixed the issues (https://github.com/Homebrew/homebrew-core/pull/73812 successfully built)!
|
|
|
|
Scope
|
2021-03-24 01:25:19
|
<@!794205442175402004> Works <https://www.reddit.com/r/jpegxl/comments/mc5foh/jpegxl_windows_x64_builds/>
I think this could be added to the FAQ, for Windows builds:
<https://ci.appveyor.com/project/EwoutH/jpeg-xl>
|
|
|
|
fab
|
2021-03-24 01:41:23
|
for %i in (C:\Users\User\Documents\jpg\*.jpg) do cjxl "%i" "%i.jxl" -j -d 2 -s 7 --faster_decoding=1 --num_threads=2
|
|
2021-03-24 01:41:26
|
it don't work
|
|
2021-03-24 01:41:33
|
why scope
|
|
2021-03-24 01:43:56
|
i need to convert into png
|
|
|
|
Scope
|
2021-03-24 01:46:37
|
Maybe remove `-j` and `-s 7`
|
|
|
|
fab
|
2021-03-24 01:47:44
|
with png it worked
|
|
2021-03-24 01:47:46
|
yes i tried all
|
|
2021-03-24 01:47:58
|
for %i in (C:\Users\User\Documents\jpg2\*.png) do cjxl "%i" "%i.jxl" -s 7 -d 2 --faster_decoding=1 --num_threads=2
|
|
2021-03-24 01:49:04
|
we need new sasha plugin and new https://ci.appveyor.com/project/novomesk/qt-jpegxl-image-plugin/history
|
|
|
|
_wb_
|
|
Scope
<@!794205442175402004> Works <https://www.reddit.com/r/jpegxl/comments/mc5foh/jpegxl_windows_x64_builds/>
I think this could be added to the FAQ, for Windows builds:
<https://ci.appveyor.com/project/EwoutH/jpeg-xl>
|
|
2021-03-24 01:53:12
|
is this a good build? I mean does it have working SIMD and all?
|
|
|
|
Scope
|
2021-03-24 01:53:42
|
I will try, but maybe AVX2 doesn't work
|
|
|
|
fab
|
2021-03-24 01:53:55
|
sse4.1 works
|
|
2021-03-24 01:54:19
|
with vardct and even faster decoding
|
|
2021-03-24 01:54:25
|
that sacrificies quality
|
|
|
|
Scope
|
2021-03-24 01:55:21
|
Appveyor
```[v0.3.5 | SIMD supported: SSE4,Scalar]```
My previous builds
```[v0.3.4 | SIMD supported: AVX2] -march=haswell
[v0.3.4 | SIMD supported: AVX2,SSE4,Scalar]
```
|
|
|
|
fab
|
2021-03-24 01:55:43
|
which cpu
|
|
2021-03-24 01:56:14
|
i will try modular
|
|
|
|
Jyrki Alakuijala
|
2021-03-24 01:56:45
|
the focus of last two versions (0.3.4 and 0.3.5) was to improve decode speed on arm and reduce decoding time memory use
|
|
2021-03-24 01:57:53
|
we made those releases to simplify testing and collaboration with facebook -- they don't have access to the internal repo of the JPEG committee
|
|
2021-03-24 01:58:23
|
facebook is awesome in giving us guidance, i'm sooo happy to get feedback from them
|
|
|
|
Scope
|
|
Scope
Appveyor
```[v0.3.5 | SIMD supported: SSE4,Scalar]```
My previous builds
```[v0.3.4 | SIMD supported: AVX2] -march=haswell
[v0.3.4 | SIMD supported: AVX2,SSE4,Scalar]
```
|
|
2021-03-24 02:00:22
|
Looks like AVX2/3 disabled because of MSVC
|
|
|
|
fab
|
2021-03-24 02:00:52
|
is fast deoding even for modular?
|
|
2021-03-24 02:01:00
|
the faster decoding options?
|
|
|
|
Jyrki Alakuijala
|
2021-03-24 02:04:59
|
there will be a new highway release soon that may (or may not) unblock this
|
|
2021-03-24 02:05:08
|
I believe within a week
|
|
2021-03-24 02:05:14
|
also more speedup for decoding
|
|
2021-03-24 02:05:30
|
relax and continue with SSE4 for now
|
|
|
|
fab
|
2021-03-24 02:08:09
|
3,27 mpx/s the speed for modular decoding
|
|
2021-03-24 02:08:12
|
at the moment
|
|
2021-03-24 02:09:31
|
9,33 mpx/s faster decoding 1 for vardct
|
|
2021-03-24 02:10:04
|
resolution instagram photos 1080x1080
|
|
|
|
_wb_
|
2021-03-24 02:26:34
|
modular is inherently slower than vardct
|
|
2021-03-24 02:28:08
|
it's also not as optimized
|
|
|
|
Lastrosade
|
2021-03-25 08:57:09
|
So uhhh, I have a png that I'm not confortable sharing, it is 800KB and when encoded with cjxl 0.3.4 with `-d 6 -s 3` I get a 5.54MB result
|
|
2021-03-25 08:57:32
|
In fact this happens with all the pngs in a dir
|
|
|
|
veluca
|
2021-03-25 09:00:16
|
what kind of content is it?
|
|
|
|
Lastrosade
|
2021-03-25 09:00:23
|
line art ?
|
|
|
|
veluca
|
2021-03-25 09:00:29
|
ah, that would do it
|
|
2021-03-25 09:00:44
|
vardct is probably not the best there
|
|
|
|
Lastrosade
|
2021-03-25 09:01:11
|
using `-m` only brings it down to 4.41MB
|
|
2021-03-25 09:02:14
|
oh maybe because there is this thing going on
|
|
2021-03-25 09:02:19
|
to darken the background
|
|
2021-03-25 09:02:58
|
|
|
2021-03-25 09:03:34
|
even avif does worst than png
|
|
|
|
veluca
|
2021-03-25 09:06:30
|
yeah that's a very good case for png
|
|
2021-03-25 09:06:40
|
try -m -s 9 -I 0
|
|
2021-03-25 09:06:55
|
and/or -m -s 9 -I 0 -P 0
|
|
|
|
Lastrosade
|
2021-03-25 09:07:20
|
l or I
|
|
2021-03-25 09:07:23
|
uhh
|
|
2021-03-25 09:07:34
|
el or eye
|
|
2021-03-25 09:07:53
|
oh capital eye
|
|
|
|
Jyrki Alakuijala
|
2021-03-25 09:08:24
|
try WebP lossless 😄
|
|
|
|
Lastrosade
|
2021-03-25 09:10:28
|
webp lossless is not doing too hot either, bit I still shaved off 10KB with `-z 9 -preset drawing`
|
|
|
veluca
and/or -m -s 9 -I 0 -P 0
|
|
2021-03-25 09:14:45
|
53KB saved with this
|
|
2021-03-25 09:15:51
|
also I am fairly certain this disables things, why is it slower ?
|
|
2021-03-25 09:16:05
|
oh s 9 nvm
|
|
|
|
Deleted User
|
2021-03-25 09:16:07
|
Dots/patches would probably help with this image...
|
|
|
|
veluca
|
2021-03-25 09:20:26
|
Ah, they're likely enabled by default, try turning them off :P (--patches=0)
|
|
|
|
Lastrosade
|
2021-03-25 09:25:03
|
Doesn't change the size
|
|
|
|
Crixis
|
2021-03-25 09:42:51
|
manga pattern?
|
|
|
|
_wb_
|
|
Lastrosade
53KB saved with this
|
|
2021-03-25 09:45:59
|
so it's smaller than the PNG with that or just smaller than the 4.4 MB file you had before?
|
|
2021-03-25 09:47:45
|
is it a 1-bit PNG? PNG does have an advantage with 1-bit because it does bit-packing (encodes 8 pixels as 1 byte), which then gives it a bigger effective window for deflate
|
|
|
|
Lastrosade
|
2021-03-25 09:48:17
|
Than the png
|
|
2021-03-25 09:49:46
|
Its not 1bit there are grey pixels
`PNG 4299x6071 4299x6071+0+0 8-bit sRGB 32c 816805B 0.000u 0:00.001`
|
|
2021-03-25 09:50:49
|
If I batch encode images I would need a way to identify which one need special flags in cjxl
|
|
2021-03-25 09:52:28
|
It doesn't help that I am in perpetual confusion
|
|
|
|
_wb_
|
2021-03-25 09:55:28
|
`32c` means 32 colors, but that's 5-bit so it doesn't do bit packing for that (only for 1, 2, 4)
|
|
2021-03-25 09:57:06
|
if the jxl is larger than the png, it's likely one of those cases where deflate/lz77 happen to be very useful
|
|
2021-03-25 09:57:41
|
`cjxl -m -s 9 -I 0 -P 0 -g 3` is probably a good idea then
|
|
2021-03-25 09:58:37
|
`-I 0` disables MA trees but it also tells the encoder to put way more effort in finding lz77 matches
|
|
|
|
Lastrosade
|
2021-03-25 10:04:08
|
with `-m -s 9 -I 0 -P 0 -g 3` the result is 12KB bigger than with `-m -s 9 -I 0 -P 0`
|
|
|
|
_wb_
|
2021-03-25 10:43:32
|
Interesting
|
|
2021-03-25 10:43:44
|
What about -g 0 and -g 2?
|
|
|
|
Lastrosade
|
2021-03-25 11:21:29
|
-g
```
0 - 803746 bytes
1 - 762193 bytes
2 - 771354 bytes
3 - 770546 bytes
```
|
|
|
|
_wb_
|
2021-03-25 11:30:11
|
looks like the default is good in this case then 🙂
|
|
|
|
fab
|
2021-03-25 08:24:28
|
LINK BUILDS:
|
|
2021-03-25 08:24:29
|
https://ci.appveyor.com/project/EwoutH/jpeg-xl/builds/38405271/job/ke3uwdrt9pd706jr/artifacts
|
|
|
|
Scope
|
2021-03-25 08:30:33
|
<@!794205442175402004> Also, the link in the faq does not work for the newest builds, I think it would be better to use https://ci.appveyor.com/project/EwoutH/jpeg-xl
|
|
|
|
Jyrki Alakuijala
|
|
_wb_
if the jxl is larger than the png, it's likely one of those cases where deflate/lz77 happen to be very useful
|
|
2021-03-26 01:10:13
|
our LZ77 is more appropriate for images than deflate
|
|
2021-03-26 01:10:23
|
we are just using it correctly yet
|
|
2021-03-26 01:11:03
|
also, some pngs are actually near-lossless for the png format's predictors -- then you get worse compressor with better predictors
|
|
|
|
diskorduser
|
2021-03-26 02:47:05
|
When encoding small images like one with 48x48px, there is a noticeable color/brightness change. Is that normal?
|
|
2021-03-26 03:05:01
|
nvm. got it fixed after stripping out those color profiles.
|
|
|
|
lithium
|
2021-03-26 03:10:25
|
I get some tiny brightness change in non-photographic content(comics, black and white screentone content)
cjxl -d 1.0 -s 7
I think that just a little change, not a big issue
|
|