|
|
veluca
|
2023-03-09 02:54:15
|
yes
|
|
2023-03-09 02:54:29
|
I mean we modified our ANS/Huffman streams to allow doing LZ77
|
|
2023-03-09 02:54:41
|
instead of just being a sequence of symbols
|
|
|
Traneptora
|
2023-03-09 02:54:59
|
I ask cause I'm taking a class right now in entropy coding and we read shannon's paper and other things about how you can get as close as you want with prefix codes to shannon entropy but not lower
|
|
|
|
veluca
|
2023-03-09 02:55:04
|
also we had a Binary Arithmetic Coder for some features such as special encoding for dots (which was also removed entirely and merged with patches)
|
|
2023-03-09 02:55:38
|
and at some point we also had FSE, another ANS variant, because why not ๐
|
|
|
|
Traneptora
|
2023-03-09 02:55:51
|
arithemetic coding is slow, isn't it?
|
|
|
|
veluca
|
2023-03-09 02:55:55
|
and MANIAC
|
|
2023-03-09 02:55:56
|
yep
|
|
|
|
Traneptora
|
2023-03-09 02:56:07
|
I know in H.264 if you disable cabac it gets much faster (albeit cavlc is not as good)
|
|
|
|
veluca
|
2023-03-09 02:56:11
|
I think we had something like 7 different entropy coders at some point or another
|
|
2023-03-09 02:56:45
|
now we just have Huffman/ANS + optional LZ77
|
|
|
|
Traneptora
|
2023-03-09 02:56:57
|
but I'm taking a class right now where we prove things like, if an independent information source has entropy H then there exists a prefix code or H <= MCL(C) < H + 1/n, for any n > 0, but there is no prefix code that goes lower than H (huffman is the best you can do and it doesn't exceed H)
|
|
2023-03-09 02:57:13
|
so it's nice seeing the theory behind this kinda stuff
|
|
|
|
veluca
|
2023-03-09 02:57:16
|
(I am fairly proud of how flexible that entropy coder managed to be, although I am a bit disappointed about things here and there)
|
|
|
|
Traneptora
|
2023-03-09 02:57:19
|
which I've only actually done in practice
|
|
2023-03-09 02:57:35
|
now in practice, why would one use prefix codes over ANS?
|
|
|
|
veluca
|
2023-03-09 02:57:45
|
there can be many reasons actually
|
|
|
|
Traneptora
|
2023-03-09 02:57:50
|
iirc the ANS implementation is both faster and more efficient
|
|
|
|
veluca
|
2023-03-09 02:58:09
|
1. ANS requires at least 4 bytes, sometimes you don't have 4 bytes of entropy ๐
|
|
|
|
Traneptora
|
2023-03-09 02:58:33
|
well I suppose if you have one symbol then prefix coding is technically more efficient
|
|
|
|
veluca
|
2023-03-09 02:58:37
|
for that matter, ANS's distribution coding uses more bits than canonical prefix codes
|
|
|
|
Traneptora
|
2023-03-09 02:58:57
|
but outside of the degenerate cases I should say
|
|
|
|
veluca
|
2023-03-09 02:59:15
|
2. you can encode prefix codes in parallel/with SIMD, can't do that with ANS
|
|
2023-03-09 02:59:40
|
which is why -e1 -d0 uses prefix codes ๐
|
|
2023-03-09 02:59:58
|
3. ANS requires encoding backwards, which is slower (and requires more buffering)
|
|
|
|
Traneptora
|
2023-03-09 03:00:01
|
if you encode prefix codes in parallel how do you end up bitpacking them?
|
|
|
|
veluca
|
|
Traneptora
if you encode prefix codes in parallel how do you end up bitpacking them?
|
|
2023-03-09 03:00:22
|
same way you do prefix sums, basically
|
|
|
|
Traneptora
|
2023-03-09 03:00:40
|
I meant, okay so you've got a pool of tokens in some order and each thread encodes them
|
|
2023-03-09 03:00:53
|
but now they're some loose bits, and those have to be reordered and placed in a bitstream
|
|
2023-03-09 03:01:29
|
if a later thread ends up encoding a prefix sooner, how do they know where in the buffer to place it?
|
|
2023-03-09 03:01:47
|
I suppose you could have one thread just on assemble duty
|
|
|
|
veluca
|
2023-03-09 03:01:51
|
you assign each thread a segment of tokens, have each thread count the # of bits, sync the threads by computing for each where their data is supposed to start, and then write the bits
|
|
|
|
Traneptora
|
2023-03-09 03:02:14
|
ah so each thread encodes a whole chunk, and then you assemble
|
|
2023-03-09 03:02:21
|
I suppose that makes more sense
|
|
2023-03-09 03:02:36
|
since prefix codes are instantaneous, that makes sense
|
|
2023-03-09 03:02:42
|
I don't think you can parallel decode them though, can you?
|
|
|
|
veluca
|
2023-03-09 03:02:50
|
not as far as I know
|
|
|
|
Traneptora
|
2023-03-09 03:03:07
|
seems like on decode it's usually better to just parallelize over groups
|
|
|
|
veluca
|
2023-03-09 03:03:20
|
there are tricks to parallel/SIMD en/decode ANS, but they cost #threads \* 4 bytes in size, and require a format change
|
|
2023-03-09 03:03:31
|
I am rather unhappy we don't have better solutions for that
|
|
|
|
afed
|
|
veluca
I feel slightly obligated to point you to this: https://github.com/veluca93/libjxl/blob/fmjxl/experimental/fmjxl/fmjxl.cc
|
|
2023-03-09 03:07:00
|
it's like a Motion JPEG?
|
|
|
|
veluca
|
|
afed
it's like a Motion JPEG?
|
|
2023-03-09 03:09:41
|
well, it creates an animated JPEG XL file
|
|
2023-03-09 03:10:10
|
for now it's ARM only (and I am not sure I'll port it to other CPUs myself), but it *does* encode at about 400MP/s on my pixel 7 on a single core... ๐
|
|
2023-03-09 03:10:31
|
(YCbCr_P010 though, because Android is weird)
|
|
|
|
Traneptora
|
2023-03-09 03:15:02
|
is CJXL supposed to be able to re-encode xyb jpegs as JXLs?
|
|
|
|
veluca
|
|
Traneptora
is CJXL supposed to be able to re-encode xyb jpegs as JXLs?
|
|
2023-03-09 03:15:09
|
I wish!
|
|
|
|
Traneptora
|
2023-03-09 03:15:14
|
no, I mean
|
|
|
|
veluca
|
2023-03-09 03:15:23
|
we'd need to change jpegli for that to be possible (or the format)
|
|
|
|
Traneptora
|
2023-03-09 03:15:25
|
`cjxl input-xyb.jpg output.jxl`
this should work, right?
|
|
2023-03-09 03:15:32
|
like not the ideal way
|
|
2023-03-09 03:15:35
|
but it shouldn't *fail*
|
|
|
|
veluca
|
2023-03-09 03:15:47
|
define fail
|
|
|
|
Traneptora
|
2023-03-09 03:15:53
|
crash
|
|
2023-03-09 03:15:58
|
Failed to encode frame
|
|
|
|
veluca
|
2023-03-09 03:16:04
|
yeah no that shouldn't happen, please file a bug
|
|
|
|
Traneptora
|
2023-03-09 03:16:07
|
```
$ cjxl lenna-xyb.jpg test.jxl
JPEG XL encoder v0.9.0 18eaa7b5 [AVX2]
Note: Implicit-default for JPEG is lossless-transcoding. To silence this message, set --lossless_jpeg=(1|0).
Read JPEG image with 54700 bytes.
Encoding [Container | JPEG, lossless transcode, effort: 7 | JPEG reconstruction data],
./lib/jxl/enc_frame.cc:322: JXL_FAILURE: Chroma subsampling is not supported when color transform is not YCbCr
./lib/jxl/enc_frame.cc:1275: JXL_RETURN_IF_ERROR code=1: MakeFrameHeader(cparams, passes_enc_state->progressive_splitter, frame_info, ib, frame_header.get())
./lib/jxl/encode.cc:570: Failed to encode frame
JxlEncoderProcessOutput failed.
EncodeImageJXL() failed.
```
|
|
2023-03-09 03:16:11
|
this is not supposed to happen, right?
|
|
|
|
veluca
|
2023-03-09 03:16:27
|
indeed not
|
|
|
|
Traneptora
|
2023-03-09 03:16:31
|
like iirc it should just attach the ICC and then set uses_original_profile = true
|
|
2023-03-09 03:16:37
|
aight, I'll open a bug
|
|
|
|
veluca
|
2023-03-09 03:16:43
|
it tries to do JPEG recompression, and fails to do so
|
|
|
|
Traneptora
|
2023-03-09 03:16:57
|
yea, I'm thinking jpegli output should be legacy jpeg compatible
|
|
2023-03-09 03:17:01
|
so I feel like that should work
|
|
2023-03-09 03:17:34
|
let me update libjxl to make sure it hasn't been patched already and if it still fails on git main I'll drop an issue
|
|
|
|
veluca
|
|
Traneptora
yea, I'm thinking jpegli output should be legacy jpeg compatible
|
|
2023-03-09 03:17:37
|
it is, but when we designed jpeg recompression we said: who in their right mind would ever do "chroma subsampling" on an RGB JPEG??? and decided to not support that
|
|
2023-03-09 03:17:47
|
and, well, then we decided to do that in jpegli
|
|
|
|
Traneptora
|
2023-03-09 03:18:08
|
ah, so is that intentional?
|
|
2023-03-09 03:18:11
|
that this doesn't work?
|
|
|
|
veluca
|
2023-03-09 03:18:26
|
intentional, no, but it is a consequence of past decisions
|
|
|
|
Traneptora
|
2023-03-09 03:18:59
|
I guess what I'm asking is, is this something that you fix by permitting this in cjxl or is this something that you fix by not permitting that in jpegli?
|
|
|
|
veluca
|
2023-03-09 03:19:08
|
we could make jpegli not subsample the B channel
|
|
2023-03-09 03:19:17
|
I think that answers your question ๐
|
|
|
|
Traneptora
|
2023-03-09 03:19:23
|
it does
|
|
|
jonnyawsom3
|
2023-03-09 03:27:37
|
Speaking of jpegli, as a lowly Windows user I couldn't for the life of me get it to write an output. I was using the benchmark, output directory set, save compressed, extention type, codec... But it would always just say the same write error listing a D drive and directory that I assume is the default path
|
|
|
|
Traneptora
|
2023-03-09 03:28:55
|
what command, what output?
|
|
|
_wb_
|
|
veluca
and, well, then we decided to do that in jpegli
|
|
2023-03-09 03:34:09
|
the irony...
|
|
|
|
Traneptora
|
2023-03-09 03:34:25
|
tbf it's not really subsampled RGB, it's really subsampled XYB
|
|
|
|
_wb_
|
2023-03-09 03:35:15
|
yeah it's hacking JPEG by using ICC to get an 'RGB' that is actually XYB
|
|
|
|
Traneptora
|
|
veluca
yeah no that shouldn't happen, please file a bug
|
|
2023-03-09 03:35:32
|
https://github.com/libjxl/libjxl/issues/2284
|
|
|
|
_wb_
|
2023-03-09 03:37:00
|
how much do we gain from subsampling B? I would expect there to be cases where the subsampling hurts, and I wonder if there's really much of a gain compared to just deadzoning it more aggressively
|
|
|
|
Traneptora
|
2023-03-09 03:38:12
|
worth mentioning that in XYB jxl we have CFL so B really is `S - (L + M) / 2`
|
|
2023-03-09 03:38:26
|
but in XYB jpeg we don't have CFL
|
|
2023-03-09 03:38:39
|
unless the ICC Profile takes that into account
|
|
2023-03-09 03:39:07
|
cause in theory we could let `S = Y + B` rather than let `S = B` in the icc profile
|
|
|
|
_wb_
|
2023-03-09 03:39:17
|
I would expect the ICC version of XYB to apply that default CFL (and shift the ranges so that all three are in 0..1 range)
|
|
|
|
Traneptora
|
2023-03-09 03:39:35
|
ah, so we do actually subtract Y from that
|
|
2023-03-09 03:39:40
|
er, add, depending on direction
|
|
|
|
_wb_
|
2023-03-09 03:39:50
|
<@179701849576833024> did you define that ICC version of XYB? or who made that
|
|
|
|
Traneptora
|
2023-03-09 03:40:04
|
what I'm wondering is why defining `B = S - (L + M) / 2` isn't something that was done originally in the XYB definition?
|
|
2023-03-09 03:40:24
|
since at every part of XYB jxl encoding/decoding that is done by default
|
|
|
|
veluca
|
|
_wb_
<@179701849576833024> did you define that ICC version of XYB? or who made that
|
|
2023-03-09 03:40:42
|
yup
|
|
|
Traneptora
what I'm wondering is why defining `B = S - (L + M) / 2` isn't something that was done originally in the XYB definition?
|
|
2023-03-09 03:40:53
|
I think only Jyrki knows this ๐
|
|
|
|
Traneptora
|
2023-03-09 03:41:16
|
maybe it makes more sense to not do it as a metric (e.g. butteraugli)
|
|
2023-03-09 03:41:30
|
but does make sense to do it as a coding tool?
|
|
|
|
veluca
|
|
Traneptora
maybe it makes more sense to not do it as a metric (e.g. butteraugli)
|
|
2023-03-09 03:41:54
|
that is likely the explanation, yes
|
|
|
_wb_
I would expect the ICC version of XYB to apply that default CFL (and shift the ranges so that all three are in 0..1 range)
|
|
2023-03-09 03:42:27
|
(this is indeed correct, by the way)
|
|
|
|
_wb_
|
2023-03-09 03:43:17
|
in ssimulacra2 I'm using B-Y, I haven't tried using just B but to me it doesn't make sense that there is B error in a grayscale image
|
|
2023-03-09 03:43:57
|
so doing the default CFL makes the most sense to me, both for coding and for metrics
|
|
2023-03-09 03:44:30
|
I think we never really bothered to define XYB that way because CFL could do it anyway
|
|
2023-03-09 03:44:50
|
just like we never bothered to give XYB components a sane range because quantization could do that anyway
|
|
2023-03-09 03:46:49
|
I remember at some point asking to redefine XYB in a nicer way (like in 2019 or so) but the conclusion then was that it would be too much work to adjust all the constants / heuristics
|
|
|
|
jonnyawsom3
|
|
Traneptora
what command, what output?
|
|
2023-03-09 03:56:10
|
Was stuck on my phone after a 3 hour long power outage across town. Just turning things back on then I can run it again
|
|
2023-03-09 03:56:41
|
Ironically it was a supermarket that had emergency power, not the hospital, phone towers or traffic lights
|
|
2023-03-09 04:26:11
|
Oh, I think I figured it out, the input didn't like `"C:\Users\jonat\Downloads\image.png"` but just `image.png` worked fine
|
|
2023-03-09 04:33:40
|
Although the html report then tries to access `file://image.png` instead of the proper path
|
|
2023-03-09 04:43:29
|
Now that I have it working though, damn you guys made some mighty fine work on such an old format. Actually had to do a flip test between it and JXL at similar sizes to notice the artefacts
|
|
|
|
Traneptora
|
2023-03-09 04:50:57
|
it has since occurred to me how much more work is required to get a rudimentary encoder than a decoder
|
|
2023-03-09 04:51:11
|
I still haven't executed any code in Hydrium yet
|
|
2023-03-09 04:51:39
|
at least with a decoder I can, say, parse a header and then abort to test out that feature
|
|
2023-03-09 04:51:45
|
but for an encoder I can't do that yet
|
|
|
|
veluca
|
2023-03-09 05:48:56
|
you kinda can? you need to instrument the decoder though
|
|
2023-03-09 05:49:07
|
that's what I did with fmjxl ๐
|
|
|
|
Traneptora
|
2023-03-09 05:49:17
|
well I guess I can just dump a header and let the decoder abort when it hits EOF
|
|
|
|
veluca
|
2023-03-09 05:49:41
|
you can take a djxl compiled from my fmjxl branch, it will tell you lots of stuff
|
|
|
|
Traneptora
|
2023-03-09 05:51:09
|
jxlatte also provides verbose info, but atm I haven't done anything except spit out the frame header and the TOC
|
|
|
|
jonnyawsom3
|
2023-03-09 06:17:03
|
I read though this old blog post while looking for something else, unsurprisingly I look to the right and Moritz is right here haha
https://opensource.googleblog.com/2021/09/using-saliency-in-progressive-jpeg-xl-images.html
|
|
2023-03-09 06:57:55
|
Apologies for all my random topics today, but I've always been curious about dissecting images and looking at the blocks like this, don't supose there's a relatively easy way to do it still? https://youtu.be/nfWJED1ZvQU
|
|
|
|
veluca
|
2023-03-09 06:58:54
|
<@794205442175402004> knows, IIRC it's not too hard to do (something like using benchmark_xl and --debug_image_dir but not 100% sure)
|
|
|
|
jonnyawsom3
|
2023-03-09 07:01:16
|
Well, it is from his youtube channel after all, just thought what better time to ask than while surrounded by the people who made it haha
|
|
2023-03-09 09:16:24
|
Welp, there is a flag for that, but...
```C:\Users\jonat\Downloads\JXL>benchmark_xl --debug_image_dir=. --input=Test.png --save_compressed --output_dir=. --codec jxl:squirrel:d1
benchmark_xl v0.8.0 adfc39b [AVX2,SSE4,SSSE3,Unknown]
16 total threads, 1 tasks, 0 threads, 16 inner threads
Error in jxl:squirrel:d1 codec
D:\a\libjxl\libjxl\tools\benchmark\benchmark_xl.cc:144: JXL_CHECK: speed_stats.GetSummary(&summary)```
|
|
|
|
_wb_
|
2023-03-09 09:23:28
|
There's an example script to produce something like those youtube videos somewhere in tools
|
|
2023-03-09 09:24:01
|
Jxlatte also has a nice block segmentation visualization iirc
|
|
|
|
Traneptora
|
2023-03-09 09:25:25
|
It does, yea
|
|
2023-03-09 09:25:40
|
`--draw-varblocks`
|
|
2023-03-09 09:33:47
|
|
|
2023-03-09 09:34:18
|
this is e7
|
|
2023-03-09 09:35:51
|
this is e5
|
|
2023-03-09 09:36:25
|
and this is e9
|
|
2023-03-09 09:36:38
|
notice that e9 and e7 made identical decisions
|
|
|
|
veluca
|
2023-03-09 09:37:24
|
yup block selection doesn't change above d7
|
|
|
|
Traneptora
|
2023-03-09 09:37:32
|
well that makes sense <:kek:857018203640561677>
|
|
2023-03-09 09:37:48
|
(that's a photograph of my pet gecko that I took, feel free to reuse it)
|
|
|
|
jonnyawsom3
|
2023-03-09 09:40:42
|
Unfortunately I'm lacking the spare braincells to build it myself so I'll carry on prodding the benchmark
|
|
|
|
Traneptora
|
2023-03-09 09:43:12
|
I haven't put any binary releases on github but I can just attach a jarfile here
|
|
2023-03-09 09:43:16
|
|
|
|
|
jonnyawsom3
|
2023-03-09 09:48:23
|
Found the script Jon mentioned too, can probably whip up an extremely rough version for windows and ffmpeg only
|
|
|
Welp, there is a flag for that, but...
```C:\Users\jonat\Downloads\JXL>benchmark_xl --debug_image_dir=. --input=Test.png --save_compressed --output_dir=. --codec jxl:squirrel:d1
benchmark_xl v0.8.0 adfc39b [AVX2,SSE4,SSSE3,Unknown]
16 total threads, 1 tasks, 0 threads, 16 inner threads
Error in jxl:squirrel:d1 codec
D:\a\libjxl\libjxl\tools\benchmark\benchmark_xl.cc:144: JXL_CHECK: speed_stats.GetSummary(&summary)```
|
|
2023-03-10 12:25:02
|
Yeah, just always that same error with --output_dir unfortunately. It was also today I found out Java 8 is the only public facing version, everything else is on the SDK site with development versions only, but I did get jxlatte to work at least. Now I should probably sleep instead of spending hours again randomly compressing images
|
|
|
username
|
|
Yeah, just always that same error with --output_dir unfortunately. It was also today I found out Java 8 is the only public facing version, everything else is on the SDK site with development versions only, but I did get jxlatte to work at least. Now I should probably sleep instead of spending hours again randomly compressing images
|
|
2023-03-10 02:15:51
|
this is usually where people get java nowadays https://adoptium.net/
|
|
|
DZgas ะ
|
|
Traneptora
|
|
2023-03-10 03:16:57
|
wait what, when did it appear???
|
|
|
|
Traneptora
|
|
DZgas ะ
wait what, when did it appear???
|
|
2023-03-10 03:17:13
|
when did what appear
|
|
|
|
DZgas ะ
|
|
Traneptora
when did what appear
|
|
2023-03-10 03:18:01
|
jxlatte is what
|
|
|
|
Traneptora
|
2023-03-10 03:19:02
|
a pure-java JPEG XL decoder
|
|
|
|
DZgas ะ
|
2023-03-10 03:19:56
|
I complained every month that benchmark_xl.exe it does not work in Windows to draw blocks, but it turns out that SOME software has been existing for 5 months and no one is talking about it
|
|
2023-03-10 03:22:30
|
But I'll be honest, it's so slow that you can die. it also consumes an awful lot of memory โ๏ธ but it will still be better than the broken official benchmark_xl
|
|
2023-03-10 03:26:43
|
although. apart from observing the bad algorithms that create blocks on empty, I won't see anything else here.
|
|
|
|
veluca
|
|
Yeah, just always that same error with --output_dir unfortunately. It was also today I found out Java 8 is the only public facing version, everything else is on the SDK site with development versions only, but I did get jxlatte to work at least. Now I should probably sleep instead of spending hours again randomly compressing images
|
|
2023-03-10 07:09:03
|
Can you file a bug? I suspect it has something to do with the windows directory handling shim...
|
|
|
|
username
|
2023-03-10 07:17:39
|
currently I'm making a pull request for the jpegxl.info site does this look good? (first image is the current repo for the site while the second image is the edits I made)
|
|
2023-03-10 07:23:09
|
also cleaned up some of the hyperlinks but that isn't shown in the images
|
|
|
spider-mario
|
|
veluca
Can you file a bug? I suspect it has something to do with the windows directory handling shim...
|
|
2023-03-10 07:51:34
|
yes, iirc we generate filenames with `:` in them
|
|
2023-03-10 07:51:44
|
which work on Linux but not Windows
|
|
|
|
veluca
|
|
|
spider-mario
|
2023-03-10 07:53:07
|
there is a string replace somewhere where one can just switch from `:` to, say, `_`, and it makes `--output_dir` work better on Windows
|
|
|
|
veluca
|
2023-03-10 07:53:39
|
I thought we replaced the : already
|
|
|
|
jonnyawsom3
|
|
veluca
Can you file a bug? I suspect it has something to do with the windows directory handling shim...
|
|
2023-03-10 10:10:10
|
https://github.com/libjxl/libjxl/issues/2287
|
|
|
|
spider-mario
|
|
veluca
I thought we replaced the : already
|
|
2023-03-10 06:55:41
|
ah, right, so thatโs not it
|
|
2023-03-10 06:56:04
|
I vaguely remember having a few more substitutions in my local copy at some point, maybe between `'/'` and `'\\'`
|
|
2023-03-10 06:56:12
|
but I donโt remember in which direction ๐
|
|
|
|
jonnyawsom3
|
2023-03-10 07:01:42
|
Well, unless there's still one left somewhere, although it could be a wrong slash. Or something entirely unrelated
|
|
|
gb82
|
2023-03-10 10:01:28
|
when converting this image to a png with `convert` the colors change dramatically
|
|
2023-03-10 10:01:48
|
or any other jxl image right now, for that matter. doesn't matter which version of libjxl I'm using
|
|
2023-03-10 10:02:49
|
```
โ ~ magick -version
Version: ImageMagick 7.1.1-0 Q32-HDRI x86_64 20944 https://imagemagick.org
Copyright: (C) 1999 ImageMagick Studio LLC
License: https://imagemagick.org/script/license.php
Features: Cipher DPC HDRI Modules OpenCL OpenMP(4.5)
Delegates (built-in): bzlib cairo djvu fftw flif fontconfig fpx freetype gvc heic jbig jng jp2 jpeg jxl lcms lqr ltdl lzma openexr pangocairo png raqm raw rsvg tiff webp wmf x xml zip zlib
Compiler: gcc (12.2)
```
|
|
2023-03-10 10:03:32
|
is imagemagick 7.1.1 broken for jpeg-xl? it used to work fine on 7.1.0
|
|
|
|
jonnyawsom3
|
2023-03-10 10:15:14
|
I know I've been having Krita fail to load JXLs occasionally, wonder if both could do with a new libjxl version
|
|
|
|
gb82
|
2023-03-10 10:16:57
|
even if I encode jxl images w cjxl 0.7.0 it still discolors them
|
|
2023-03-10 10:17:42
|
it also appears to be every image I try to encode
|
|
|
|
jonnyawsom3
|
2023-03-10 10:20:25
|
I assume using djxl to turn them into a PNG doesn't have the same issue?
|
|
|
|
gb82
|
2023-03-10 10:22:34
|
u can do that?
|
|
2023-03-10 10:24:23
|
yeah just tested, djxl is fine
|
|
2023-03-10 10:27:34
|
although now the colors are ruined somehow
|
|
2023-03-10 10:28:08
|
|
|
|
|
Traneptora
|
2023-03-10 10:31:02
|
what happens with cjxl?
|
|
2023-03-10 10:31:08
|
does it not mess up the coors?
|
|
2023-03-10 10:31:31
|
cause cjxl 0.7.0 has some known color issues that have since been fixed
|
|
|
|
gb82
|
2023-03-10 10:31:34
|
the image on the left was encoded w cjxl from a 16-bit png
|
|
2023-03-10 10:32:05
|
```
โ jpegxl_imagetest15 cjxl -V
cjxl v0.9.0 13caf6f8 [AVX2,SSE4,SSSE3,SSE2]
Copyright (c) the JPEG XL Project
```
|
|
|
|
Traneptora
|
|
|
gb82
|
2023-03-10 10:32:27
|
djxl is obv the same version
|
|
2023-03-10 10:32:31
|
do u want the source image?
|
|
|
|
Traneptora
|
2023-03-10 10:32:40
|
if you can give it, sure
|
|
2023-03-10 10:32:46
|
and even then, if that's still happening I'd probably open an issue about it
|
|
2023-03-10 10:33:06
|
well I don't wan't it personally but it could be helpful to attach it to the issue
|
|
|
|
gb82
|
2023-03-10 10:33:22
|
it is 96.6mb
|
|
2023-03-10 10:34:43
|
weirdly enough, reencoding the PNG actually gave a sane looking output with cjxl
|
|
2023-03-10 10:35:05
|
the PNG that was the decoded jxl which was reencoded from the original
|
|
|
|
Traneptora
|
2023-03-10 10:37:16
|
if you view the JXL file directly, are the colors wrong?
|
|
2023-03-10 10:37:49
|
or are they only wrong if you first djxl to a PNG, and then view the PNG?
|
|
2023-03-10 10:38:03
|
or are they only wrong if you use imagemagick to convert from jxl to png?
|
|
2023-03-10 10:39:25
|
I ask because there was a bug in imagemagick where it would tag sRGB PNGs as gamma2.2 and not as sRGB
|
|
2023-03-10 10:39:32
|
so there might be some subtle color correction issues there
|
|
|
|
gb82
|
|
Traneptora
if you view the JXL file directly, are the colors wrong?
|
|
2023-03-10 10:41:11
|
no
|
|
|
Traneptora
or are they only wrong if you first djxl to a PNG, and then view the PNG?
|
|
2023-03-10 10:41:43
|
there's weird artifacts with djxl > png, & the entire image coloration is totally off with `convert`
|
|
|
|
Traneptora
|
2023-03-10 10:41:57
|
what kind of "weird artifacts"
|
|
2023-03-10 10:42:05
|
also can you upload the encoded JXL?
|
|
|
|
gb82
|
|
gb82
|
|
2023-03-10 10:42:11
|
observe around the window
|
|
|
gb82
when converting this image to a png with `convert` the colors change dramatically
|
|
2023-03-10 10:42:16
|
^
|
|
2023-03-10 10:42:27
|
there's the JXL encoded directly from the 16-bit PNG
|
|
|
|
Traneptora
|
2023-03-10 10:42:37
|
oh, interesting
|
|
2023-03-10 10:43:06
|
the JXL that works when viewed with a viewer but not with djxl, can you attach that?
|
|
|
|
gb82
|
2023-03-10 10:43:10
|
but reencoding the djxl png back to jxl makes it look fine again
|
|
|
|
Traneptora
|
2023-03-10 10:43:41
|
also, what image viewer is this?
|
|
|
|
gb82
|
2023-03-10 10:45:16
|
source png > cjxl = expected result
source png > cjxl > png (convert) = entire image is clearly discolored, much darker
source png > cjxl > png (djxl) = slight discoloration in certain areas, as seen in my attached comparison screenshot
source png > cjxl > png (djxl) > cjxl = expected result
|
|
|
Traneptora
also, what image viewer is this?
|
|
2023-03-10 10:45:34
|
gnome's image viewer. opening the djxl png in Firefox gives the same results though
|
|
|
|
Traneptora
|
2023-03-10 10:46:20
|
Eye of Gnome has some known color mapping weaknesses
|
|
2023-03-10 10:46:25
|
Eye of MATE is the same
|
|
2023-03-10 10:46:35
|
what's the JXL tagged as?
|
|
|
|
gb82
|
2023-03-10 10:46:51
|
how do I figure that out?
|
|
|
Traneptora
Eye of Gnome has some known color mapping weaknesses
|
|
2023-03-10 10:47:08
|
I'm sure, but considering the problem persists in Firefox...
|
|
|
|
Traneptora
|
2023-03-10 10:47:12
|
`jxlinfo -v some-file.jxl`
|
|
|
|
gb82
|
2023-03-10 10:47:36
|
also `convert`'s png doesn't display properly anywhere. I noticed something was wrong because of terrible ssimulacra2 scores
|
|
|
|
Traneptora
|
2023-03-10 10:47:56
|
that's probably because convert is doing something wrong with color management before feeding it to libjxl
|
|
2023-03-10 10:48:11
|
I'm more interested in djxl producing weird PNGs ngl
|
|
2023-03-10 10:48:26
|
can you attach a JXL file that works incorrectly with djxl?
|
|
|
|
gb82
|
2023-03-10 10:48:31
|
```
โ jpegxl_imagetest15 jxlinfo -v imagetest15-Q70.jxl
JPEG XL image, 5470x3656, lossy, 16-bit RGB
num_color_channels: 3
num_extra_channels: 0
have_preview: 0
have_animation: 0
Intrinsic dimensions: 5470x3656
Orientation: 1 (Normal)
Color space: 888-byte ICC profile, CMM type: "lcms", color space: "RGB ", rendering intent: 0
```
|
|
|
Traneptora
can you attach a JXL file that works incorrectly with djxl?
|
|
2023-03-10 10:48:52
|
the one I attached above is the one I'm observing this strange behavior with
|
|
|
|
Traneptora
|
2023-03-10 10:49:07
|
oh you did attach it
|
|
2023-03-10 10:49:08
|
I missed that
|
|
|
|
gb82
|
|
gb82
when converting this image to a png with `convert` the colors change dramatically
|
|
2023-03-10 10:49:23
|
this should be it. linked to this reply
|
|
|
|
Traneptora
|
2023-03-10 10:54:20
|
The problem is that djxl is producing a linear light PNG image
|
|
2023-03-10 10:54:23
|
for some reason
|
|
2023-03-10 10:54:45
|
and there likely isn't enough precision
|
|
2023-03-10 10:55:14
|
when a client requests sRGB correctly from libjxl, they're receiving it fine
|
|
2023-03-10 10:55:32
|
or in the case of jxlatte, it also produces a correct sRGB PNG
|
|
2023-03-10 10:55:44
|
but some color mapping went weird somewhere
|
|
|
|
gb82
|
2023-03-10 10:57:00
|
Considering this is for an image benchmark, should I be making cjxl output at a dif bit depth for better compression?
|
|
2023-03-10 10:57:10
|
Like how avif is better at 10 bit
|
|
|
|
Traneptora
|
2023-03-10 10:57:24
|
JXL internally doesn't have big depth
|
|
2023-03-10 10:57:31
|
that's just a tag, you can actually request any bit depth from djxl
|
|
2023-03-10 10:57:43
|
well sorta
|
|
2023-03-10 10:57:48
|
it does for modular, but not for vardct
|
|
2023-03-10 10:58:04
|
modular deals with raw integers, vardct deals with real numbers between 0 and 1
|
|
|
|
gb82
|
|
Traneptora
JXL internally doesn't have big depth
|
|
2023-03-10 10:58:05
|
Is this related to the xyb colorspace having 24 bit precision w integer
|
|
|
|
Traneptora
|
2023-03-10 10:58:21
|
well xyb color space deals with real numbers
|
|
|
|
gb82
|
2023-03-10 10:58:38
|
Darktable has that bit depth output option for JXL which is odd
|
|
|
|
Traneptora
|
2023-03-10 10:58:46
|
yea, cause there's a tag in the header
|
|
|
|
gb82
|
|
|
Traneptora
|
2023-03-10 10:58:55
|
but that tag is just suggested bit depth output
|
|
2023-03-10 10:59:05
|
like, if you took 8-bit input, you wouldn't really want 16-bit output
|
|
2023-03-10 10:59:10
|
so you tag the input as a suggestion
|
|
|
|
gb82
|
2023-03-10 10:59:18
|
True
|
|
2023-03-10 11:06:02
|
Iโll test if ssimu2 cares about the broken pngs later
|
|
2023-03-10 11:11:41
|
```ssimulacra2_rs image imagetest15-Q70_djxl.png imagetest15.png
Score: -184.37155132```
|
|
2023-03-10 11:11:45
|
yeah it def does :(
|
|
|
|
Traneptora
|
2023-03-10 11:13:06
|
I think it's possible the ICC profile that is attached to them is incorrect somehow
|
|
2023-03-10 11:14:55
|
nope, nvm, even if I rely on cICP it's still off
|
|
2023-03-10 11:14:56
|
interesting
|
|
2023-03-10 11:15:27
|
it's still weird that's it's outputting a linear light PNG though
|
|
2023-03-10 11:20:27
|
this is a very interesting JXL file
|
|
2023-03-10 11:20:32
|
it's also screwing with FFmpeg
|
|
2023-03-10 11:20:53
|
I have to figure out what's going on
|
|
2023-03-10 11:40:04
|
looks like something isn't tonemapping the linear light correctly
|
|
2023-03-10 11:40:48
|
as taking in `ffmpeg -i test.png -init_hw_device vulkan:0 -vf libplacebo=color_trc=iec61966-2-1:format=rgba64le test2.png`
|
|
2023-03-10 11:40:49
|
this works
|
|
|
|
gb82
|
|
Traneptora
as taking in `ffmpeg -i test.png -init_hw_device vulkan:0 -vf libplacebo=color_trc=iec61966-2-1:format=rgba64le test2.png`
|
|
2023-03-11 02:20:08
|
Iโll try this & see if ssimu2 respects it
|
|
2023-03-11 02:20:16
|
Should I submit an issue for djxl?
|
|
|
Traneptora
as taking in `ffmpeg -i test.png -init_hw_device vulkan:0 -vf libplacebo=color_trc=iec61966-2-1:format=rgba64le test2.png`
|
|
2023-03-11 02:43:23
|
keep getting "conversion failed" with this
|
|
|
|
Traneptora
|
2023-03-11 02:58:11
|
need a more recent version of libplacebo
|
|
2023-03-11 02:58:18
|
and more recent of ffmpeg
|
|
2023-03-11 02:58:19
|
git master
|
|
|
gb82
Should I submit an issue for djxl?
|
|
2023-03-11 03:35:09
|
yea, it's outputting a linear light PNG for no real reason
|
|
2023-03-11 03:35:19
|
and I believe that's messing things up
|
|
|
|
gb82
|
2023-03-11 05:11:20
|
https://github.com/libjxl/libjxl/issues/2289
|
|
2023-03-11 05:11:28
|
Thereโs the issue
|
|
|
yoochan
|
2023-03-11 02:08:16
|
<@794205442175402004> I just extracted some letters of a manga (here in png but I suspect it has transited via high quality jpeg) and I don't see how patches could apply, not two of them are exactly identical
|
|
|
|
Traneptora
|
|
yoochan
<@794205442175402004> I just extracted some letters of a manga (here in png but I suspect it has transited via high quality jpeg) and I don't see how patches could apply, not two of them are exactly identical
|
|
2023-03-11 02:09:12
|
patches don't have to be identical, you could use patches to create an approximation and then record the residuals
|
|
|
|
yoochan
|
2023-03-11 02:11:57
|
ok, then it could be tried ๐
|
|
|
|
Traneptora
|
2023-03-11 02:13:58
|
not sure how valuable it would be, but it could be done in theory
|
|
|
|
yoochan
|
2023-03-11 02:14:23
|
what's the size at which a patch become useful do you think ?
|
|
|
|
Traneptora
|
2023-03-11 02:14:45
|
I meant more the overhead of encoding the residuals might not be any lower entropy than encoding the pixels
|
|
|
|
yoochan
|
2023-03-11 02:15:26
|
indeed... that's why we wanted to try by hand guiding the encoder with pre-selected pathes... and see
|
|
|
|
_wb_
|
2023-03-11 02:19:32
|
For lossless, the current encoder only uses exact matches, and only finds some of them since it uses some heuristics to find candidates quickly, in particular, it requires regions of 4x4 (iirc) exactly-the-same-color to be adjacent to the candidate patches.
|
|
2023-03-11 02:21:09
|
Doing non-exact matches might be worth it if the residuals are very small (e.g. one pixel is different) but I would guess that if more than 5% or so of the pixels need to change (in an irregular way), it will not be worth it.
|
|
2023-03-11 02:26:15
|
For lossy, obviously non-exact matches can help. Avoiding the JBIG2 issue (8 becoming 6 etc) is important though. We try to avoid it by always keeping the residuals; if the differences are small, later dct quantization will probably remove them, but if there's a bigger difference, it will be (to some extent at least) preserved. Of course here too, things become less effective or counterproductive if there are high freq residuals left to be encoded, so the current heuristics will avoid matching when the difference is big enough to leave significant residuals.
|
|
|
|
yoochan
|
2023-03-11 02:34:37
|
thanks for the details... I understand better
|
|
|
|
_wb_
|
2023-03-11 02:36:12
|
Patches is a lot like splines: making an encoder that makes good use of the coding tool is a lot harder than making a decoder for it. In a way, patches is the 2D version of lz77, and it is also a way to combine lossless (modular) techniques and VarDCT in a single image. It's a very powerful tool, and we're currently only using it in a pretty restricted way. It's like patches is a Swiss army knife and libjxl is currently only using it as a bottle opener. It's better than splines, which is not being used at all atm, but there's still tons of opportunity for future creative encoder improvements involving patches.
|
|
|
|
yoochan
|
2023-03-11 02:50:13
|
Perhaps, some use cases (like comics translation and lettering, I'm focusing on this particular subject as you noticed ๐
) could account for this constraint beforehand and generate patch friendly images (for modular) ... Could patch be applied from one frame to another?
|
|
2023-03-11 02:52:00
|
The 4x4 adjacent constraint is only a limitation of the current encoder not of the format right?
|
|
|
|
username
|
|
yoochan
The 4x4 adjacent constraint is only a limitation of the current encoder not of the format right?
|
|
2023-03-11 02:53:42
|
yes
|
|
2023-03-11 02:54:04
|
encoder limitation not format
|
|
|
|
jonnyawsom3
|
2023-03-11 03:01:53
|
Huh, this entire time I've been throwing images with lots of curves at the encoder thinking splines were doing the heavy lifting, goes to show how well the current techniques already work
|
|
|
fab
|
2023-03-11 04:41:49
|
i never get to like jpeg xl
|
|
2023-03-11 05:01:15
|
Jxl is good on photography such as pon
|
|
2023-03-11 05:01:23
|
S8 d1 does it job
|
|
2023-03-11 05:01:48
|
But for screenshot you need modular lossy for all the frame
|
|
2023-03-11 05:01:54
|
It will look better
|
|
2023-03-11 05:02:18
|
Tested against AVM CPU 9
|
|
2023-03-11 05:03:32
|
AVM is hella slow it gets 11 seconds and it recognizes only a frame it doesn't code inter
|
|
2023-03-11 05:03:44
|
If there are at least 5fps
|
|
2023-03-11 05:03:56
|
Libx264 crf0 to y4m
|
|
|
|
jonnyawsom3
|
2023-03-11 05:04:23
|
You're talking about animated JXL I assume?
|
|
|
|
fab
|
2023-03-11 05:04:32
|
No
|
|
2023-03-11 05:04:48
|
Avm has a good quality in 65111
|
|
2023-03-11 05:04:57
|
Really a lot of details
|
|
2023-03-11 05:05:16
|
Jxl I don't call it warm but it retains good of
|
|
2023-03-11 05:06:35
|
|
|
2023-03-11 05:07:35
|
|
|
2023-03-11 05:07:48
|
Avm goes at those colours
|
|
2023-03-11 05:08:01
|
And with less size
|
|
2023-03-11 05:09:11
|
Jpeg xl was born too complicated
|
|
2023-03-11 05:10:57
|
You need s9 to be sure
|
|
2023-03-11 05:11:05
|
In cjxl
|
|
2023-03-11 05:12:30
|
Q 94.1 JPEG li looks better to me even if it isn't a new codec
|
|
2023-03-11 05:12:38
|
18:12
|
|
2023-03-11 05:13:16
|
I'm not fully convinced of JPEG XL
|
|
2023-03-11 05:14:07
|
Like for GitHub pages or screenshot jpegli at q94.1 without extensions Is good
|
|
2023-03-11 05:14:33
|
But I won't use for my work
|
|
2023-03-11 05:16:26
|
Reoptimized gaborish encoding at s7 d 0.8
|
|
2023-03-11 05:16:34
|
Has good max p norm
|
|
2023-03-11 05:18:18
|
Ah is the same build
|
|
2023-03-11 05:18:35
|
It performes overcompression by default
|
|
|
|
jonnyawsom3
|
2023-03-11 05:20:38
|
How old is the cjxl you're using? It's not used the `s` settings for quite a while, now it uses `e` instead
|
|
|
|
fab
|
2023-03-11 05:26:34
|
i'll tell you the settings to improve quality and appeal
|
|
2023-03-11 05:26:41
|
cjxl qa.png -e 7 -q 86.068 --intensity_target=258 --epf=1 --dots=0 qa.jxl
|
|
2023-03-11 05:26:45
|
use this
|
|
2023-03-11 05:27:00
|
tell me the difference <@226977230121598977>
|
|
|
diskorduser
|
|
fab
cjxl qa.png -e 7 -q 86.068 --intensity_target=258 --epf=1 --dots=0 qa.jxl
|
|
2023-03-11 05:28:01
|
Why 258
|
|
|
|
fab
|
|
diskorduser
Why 258
|
|
2023-03-11 05:32:01
|
You need more aggressive deblurring by default
|
|
2023-03-11 05:32:19
|
You don't care if you can't see the text Telefunken
|
|
2023-03-11 05:33:35
|
Those normal settings are because you don't want to lose many generations of quality
|
|
2023-03-11 05:34:05
|
If you need something more sophiaticated use avm CPU 5
|
|
2023-03-11 05:34:40
|
|
|
2023-03-11 05:35:09
|
Those settings I described will also improve the colours in those scenarios
|
|
|
fab
You need more aggressive deblurring by default
|
|
2023-03-11 05:36:08
|
I don't know why it can be made a settings and let the person decide
|
|
2023-03-11 05:36:21
|
No encoder permits that
|
|
|
|
yoochan
|
|
fab
No encoder permits that
|
|
2023-03-11 06:28:39
|
perhaps because the codestream was frozen only a few month ago and the encoder is still experimenting exciting stuffs ?
|
|
|
|
_wb_
|
|
fab
No encoder permits that
|
|
2023-03-11 07:24:40
|
It's a matter of scope. Denoising is not a task of an encoder, nor is sharpening, auto contrast, or red eye removal. If you want to 'enhance' images, use Photoshop or Gimp or whatever. An encoder should always assume that the input image is what needs to preserved as well as possible.
|
|
|
|
DZgas ะ
|
|
fab
cjxl qa.png -e 7 -q 86.068 --intensity_target=258 --epf=1 --dots=0 qa.jxl
|
|
2023-03-11 07:51:46
|
there are a lot of commands. no idea what they're doing ๐ intensity_target dots
|
|
|
|
jonnyawsom3
|
2023-03-11 08:11:45
|
> --intensity_target=N
> Upper bound on the intensity level present in the image in nits. Leaving this set to its default of 0 lets libjxl choose a sensible default value based on the color encoding.
> --epf=-1|0|1|2|3
> Edge preserving filter level, -1 to 3. Value -1 means: default (encoder chooses), 0 to 3 set a strength.
> --dots=0|1
> Force disable/enable dots generation. (not provided = default, 0 = disable, 1 = enable).
|
|
|
|
DZgas ะ
|
|
> --intensity_target=N
> Upper bound on the intensity level present in the image in nits. Leaving this set to its default of 0 lets libjxl choose a sensible default value based on the color encoding.
> --epf=-1|0|1|2|3
> Edge preserving filter level, -1 to 3. Value -1 means: default (encoder chooses), 0 to 3 set a strength.
> --dots=0|1
> Force disable/enable dots generation. (not provided = default, 0 = disable, 1 = enable).
|
|
2023-03-11 08:53:46
|
it's all well written, of course. but it doesn't explain anything. why do I need to generate dots for what? it's better to do it where?
how to understand which parameters of intensity_target are responsible for what, there are no examples, there are not even recommended values, or standard values. The phrase "libjxl choose" only says that the edit parameter is useless and it is different on each image
|
|
2023-03-11 08:54:44
|
<@416586441058025472>you work with it as I see, can you explain?
|
|
|
|
fab
|
2023-03-11 08:55:08
|
no i don't encode
|
|
2023-03-11 08:55:19
|
especially images
|
|
|
|
_wb_
|
2023-03-11 09:07:37
|
There used to be a coding tool called 'dots', which would be a representation of small (around 1-2px radius) ellipses, e.g. for stars on a night sky and other dot-shaped image features. Like splines, the idea is that these are hard to compress with the dct, so taking them out and representing them separately would be more effective. Dots had their own quad tree representation for their locations (with subpixel precision iirc), a specific representation for quantized ellipses, and even a specific entropy coding. We simplified the spec by getting rid of it, using patches instead to represent dots if we want to represent dots separately.
The encoder code for detecting dots is still there, but instead of using the 'dots' coding tool to signal them (which no longer exists), it uses patches.
|
|
2023-03-11 09:13:10
|
It's a somewhat neglected part of the encoder though. I don't think it combines well with the 'usual' patch detection (the one we use to extract letters and other duplicated patterns). We could generalize it to detect other things than ellipses โ any thin shape with high contrast is probably better extracted, either as spline (if it's long) or as patch (if it's not).
|
|
|
|
DZgas ะ
|
|
_wb_
There used to be a coding tool called 'dots', which would be a representation of small (around 1-2px radius) ellipses, e.g. for stars on a night sky and other dot-shaped image features. Like splines, the idea is that these are hard to compress with the dct, so taking them out and representing them separately would be more effective. Dots had their own quad tree representation for their locations (with subpixel precision iirc), a specific representation for quantized ellipses, and even a specific entropy coding. We simplified the spec by getting rid of it, using patches instead to represent dots if we want to represent dots separately.
The encoder code for detecting dots is still there, but instead of using the 'dots' coding tool to signal them (which no longer exists), it uses patches.
|
|
2023-03-11 09:50:53
|
tI noticed when I was doing tests that if draw 2 dots side by side, then a field of artifacts appears. But if you draw one pixel per 1 block, then there will be 1 ideal dot
|
|
|
|
_wb_
|
2023-03-11 09:54:53
|
This is likely the difference between dot detection getting triggered or not
|
|
|
|
DZgas ะ
|
|
_wb_
This is likely the difference between dot detection getting triggered or not
|
|
2023-03-11 10:00:10
|
but for some reason, this works only on e6 and e7, artifacts appear on all the others e8 and e9, and at e4 and below, the point turns into a terrible sight
|
|
2023-03-11 10:02:23
|
e4 e5 e7 e9
|
|
2023-03-11 10:04:28
|
standard JPEG
|
|
|
|
gb82
|
2023-03-11 10:05:19
|
do u have the source image?
|
|
|
|
DZgas ะ
|
|
gb82
do u have the source image?
|
|
2023-03-11 10:05:44
|
?? draw the dot
|
|
|
|
gb82
|
2023-03-11 10:05:57
|
it's not part of a larger image?
|
|
|
|
DZgas ะ
|
2023-03-11 10:06:04
|
just dot
|
|
|
|
gb82
|
2023-03-11 10:06:21
|
ok I'll test
|
|
2023-03-11 10:24:01
|
|
|
2023-03-11 10:24:11
|
source
|
|
2023-03-11 10:24:33
|
this is RGB jpegli, btw
|
|
2023-03-11 10:45:52
|
that's jxl e7 I just realized. I'll try e4 & e9
|
|
2023-03-11 10:54:46
|
Isn't it odd how e4 performs better lower down here?
|
|
|
HLBG007
|
2023-03-11 11:03:17
|
me would interest which of all colorspaces of the world perform best with every codec https://en.wikipedia.org/wiki/List_of_color_spaces_and_their_uses
|
|
|
|
Traneptora
|
|
fab
You need more aggressive deblurring by default
|
|
2023-03-11 11:08:50
|
intensity target has nothing to do with deblurring
|
|
|
BlueSwordM
|
|
_wb_
It's a somewhat neglected part of the encoder though. I don't think it combines well with the 'usual' patch detection (the one we use to extract letters and other duplicated patterns). We could generalize it to detect other things than ellipses โ any thin shape with high contrast is probably better extracted, either as spline (if it's long) or as patch (if it's not).
|
|
2023-03-12 12:33:33
|
Wouldn't it be possible to also use it for coarse dithering?
|
|
|
|
_wb_
|
2023-03-12 01:21:22
|
Like a kind of grain synthesis you mean? For that I think we could experiment with MA-tree based cellular automata (aka jxl art) that just gets added as a second layer (with low alpha so the effect is subtle). Bad for decode time, but signaling cost could be very low (a few dozen bytes, plus perhaps some modulation on a low res alpha channel if it needs to be region-dependent).
|
|
|
|
BlueSwordM
|
|
_wb_
Like a kind of grain synthesis you mean? For that I think we could experiment with MA-tree based cellular automata (aka jxl art) that just gets added as a second layer (with low alpha so the effect is subtle). Bad for decode time, but signaling cost could be very low (a few dozen bytes, plus perhaps some modulation on a low res alpha channel if it needs to be region-dependent).
|
|
2023-03-12 04:24:39
|
Yes. Looking at how dots is done, it should de doable for some specific patterns that tend to badly compress with DCT, like large dithering.
|
|
|
|
DZgas ะ
|
|
gb82
source
|
|
2023-03-12 07:37:08
|
What are you doing?
|
|
|
DZgas ะ
tI noticed when I was doing tests that if draw 2 dots side by side, then a field of artifacts appears. But if you draw one pixel per 1 block, then there will be 1 ideal dot
|
|
2023-03-12 07:38:19
|
<@703028154431832094> I wrote that this only works if 1 dot per 1 DCT block
|
|
|
|
Traneptora
|
2023-03-12 11:18:16
|
I noticed that ANS returns `uint32_t` symbols but it has a frequency distribution of length `1 << logAlphabetSize` where `logAlphabetSize` ranges between 5 and 8 (i.e. `5 + u(2)`)
|
|
2023-03-12 11:18:46
|
does that mean tokens returned by ANS distributions always are capped at 255?
|
|
|
|
veluca
|
|
Traneptora
does that mean tokens returned by ANS distributions always are capped at 255?
|
|
2023-03-12 11:19:21
|
yup
|
|
2023-03-12 11:19:28
|
need huffman to go above that
|
|
|
|
Traneptora
|
2023-03-12 11:19:42
|
and if so, is that what the purpose of the HybridIntegerConfig is?
|
|
|
|
veluca
|
|
Traneptora
and if so, is that what the purpose of the HybridIntegerConfig is?
|
|
2023-03-12 11:19:52
|
also yup
|
|
|
|
_wb_
|
2023-03-12 11:21:43
|
Basically with ANS in jxl you can entropy-code up to 8 bits per symbol and you can choose which ones: most significant mantissa bits, exponent bits, the sign bit, or lsb bits.
|
|
2023-03-12 11:22:03
|
The remaining bits are signaled raw
|
|
|
|
Traneptora
|
2023-03-12 11:22:36
|
I'm thinking for things like the LF Coefficient modular stream you'll probably rarely go above 256 though
|
|
2023-03-12 11:22:43
|
so you probably can encode those as-is
|
|
|
|
_wb_
|
2023-03-12 11:23:41
|
Yes, for lossy I assume you could entropy-code the whole symbols if you wanted, at least at the not-too-high quality settings
|
|
2023-03-12 11:24:25
|
But there's no point in using entropy coding to signal bits that effectively have a 50-50 probability
|
|
|
|
Traneptora
|
2023-03-12 11:24:26
|
you're looking at `1f/256f` as your quant factor for B with a default quantLF of `100` and a default globalScale of `32768` so if you scale that by `1 << 16` you end up with `1/(256f * 50)` as your *default* B quant factor
|
|
2023-03-12 11:25:56
|
using `scaledDequant[B] = (1 << 16) * lfQuant[B] / (quantLF * globalScale)`
|
|
2023-03-12 11:26:28
|
hm, so if you want to encode B=1.0 you'd need to write 256*50 to the stream
|
|
2023-03-12 11:26:37
|
or 12800
|
|
2023-03-12 11:27:46
|
unless my math is wrong, this requires prefix coding?
|
|
2023-03-12 11:30:48
|
assuming CFL is disabled and all that jazz
|
|
|
|
_wb_
|
2023-03-12 11:30:56
|
No, you do ANS with a hybriduintconfig that lets some lsb be signaled raw
|
|
|
|
Traneptora
|
2023-03-12 11:32:12
|
so you'd signal maybe the higher order 8 bits with ANS, and the lower order 6 bits raw?
|
|
2023-03-12 11:32:20
|
as the lower order bits are likely to be very high-volatility?
|
|
2023-03-12 11:33:57
|
although this is technically after modular prediction goes through
|
|
|
|
_wb_
|
2023-03-12 11:33:57
|
IIRC a common hybriduintconfig is to have dedicated tokens for 0..15 (which means -8..7 after UnpackSigned), then for higher amplitude symbols you put the exponent and two msb inside the token, and the rest (so the lsbs, including the sign bit which is effectively the lsb after PackSigned) are raw bits
|
|
|
Jarek
|
2023-03-12 11:36:10
|
generally, ANS can work with arbitrarily large alphabets, e.g. 2^25 symbols here: https://cds.cern.ch/record/2758822/files/10.1051_epjconf_202024501001.pdf
|
|
|
|
Traneptora
|
2023-03-12 11:36:31
|
that might be the case, but I'm referring to ANS specifically as it appears in JXL codestreams though
|
|
2023-03-12 11:36:36
|
as I'm writing an encoder
|
|
2023-03-12 11:37:29
|
hm, and what's the easiest way to generate the frequency distribution, other than by brute force? for 3x32x32 that's probably not that computationally intensive to just literally iterate over all the tokens to encode
|
|
2023-03-12 11:37:40
|
but for the HF coefficients I can imagine it gets more complicated
|
|
2023-03-12 11:37:49
|
as you have a lot more of them
|
|
|
|
_wb_
|
|
Traneptora
so you'd signal maybe the higher order 8 bits with ANS, and the lower order 6 bits raw?
|
|
2023-03-12 11:38:05
|
Yeah it's not quite msb vs lsb, it's an exponent-mantissa representation for symbols above the cutoff (low-amplitude symbols get a token of their own since they are very common, as distributions have most of their mass around zero)
|
|
|
|
Jarek
|
2023-03-12 11:38:34
|
sure, usually people use 256 size to have symbols as bytes
|
|
|
|
Traneptora
|
2023-03-12 11:39:57
|
oh, I think I see how this works, the split_exponent splits the token into a lower order and a higher order part
|
|
2023-03-12 11:40:51
|
er, the hybrid config does
|
|
2023-03-12 11:41:09
|
split_exponent refers to actual number of bits of the symbol
|
|
2023-03-12 11:42:19
|
lsb_in_token refers to the number of lower order bits of the token
msb_in_token refers to the index of the rest of the bits in the token
|
|
|
|
_wb_
|
|
Jarek
generally, ANS can work with arbitrarily large alphabets, e.g. 2^25 symbols here: https://cds.cern.ch/record/2758822/files/10.1051_epjconf_202024501001.pdf
|
|
2023-03-12 11:42:42
|
Yes, that's perfectly possible, but by keeping the alphabet size low (8 bit) and the precision of the probabilities low too (12 bit) we can do some trickery to speed up the state updates. If we would have a 32-bit alphabet, it would be slower, and the compression benefit would be small. Also the signaling cost for distributions over such a big alphabet size would become a problem...
|
|
|
|
Traneptora
|
2023-03-12 11:44:16
|
hm, actually it looks like msb_in_token refers to the index in the token of the higher order bits
|
|
2023-03-12 11:45:02
|
after shifting by lsb_in_token that is
|
|
|
|
Jarek
|
2023-03-12 11:45:19
|
sure, but if needed in some scenarios, maybe just add optional alternative implementation for e.g. 12 bit alphabet
|
|
|
|
Traneptora
|
2023-03-12 11:47:40
|
which means if `msb_in_token + lsb_in_token != log_alphabet_size` then you're probably doing something wrong
|
|
|
|
Jarek
|
2023-03-12 11:47:42
|
... but it would be proble.atic especially for hardware implementations
|
|
|
|
_wb_
|
2023-03-12 11:48:31
|
Typical actual alphabet sizes are probably more like 50 or so in jxl. The lsb of high amplitude residuals behave basically like random bits, so it's a waste of time and signaling bits to include them in the distributions (which are fixed and signaled in jxl) as opposed to just using raw bits for those. That's the 'hybrid' in HybridUint: it's a mix between entropy coding the part that has low entropy and not entropy coding the part that is basically pure entropy anyway...
|
|
|
|
Traneptora
|
2023-03-12 11:49:30
|
```c
int n = config.splitExponent - config.lsbInToken - config.msbInToken
+ ((token - split) >> (config.msbInToken + config.lsbInToken));
```
|
|
2023-03-12 11:49:39
|
what I'm trying to figure out is what the term on the 2nd line is for
|
|
2023-03-12 11:51:04
|
I'd assume that `lsbInToken + msbInToken` generally will be the size of the token
|
|
2023-03-12 11:51:46
|
so I'd figure `config.splitExponent - config.lsbInToken - config.msbInToken` would be the remaining bits left of the hybrid integer
|
|
|
|
yoochan
|
2023-03-12 02:29:35
|
let say I encoded a png file as lossy (-q 96) + progressive, I would like to know (or change) the number of passes used for the progressiveness, and also I would like to know if we can easily guess where passes end, so that I can try to truncate exactly at the end of one
|
|
|
|
DZgas ะ
|
|
yoochan
let say I encoded a png file as lossy (-q 96) + progressive, I would like to know (or change) the number of passes used for the progressiveness, and also I would like to know if we can easily guess where passes end, so that I can try to truncate exactly at the end of one
|
|
2023-03-12 03:11:08
|
https://github.com/libjxl/libjxl/blob/a741606839f6b5118dba7be0b67d2f496e225543/lib/jxl/enc_frame.cc#L73
|
|
2023-03-12 03:12:21
|
to make 8 layers of progressive decoding, I changed this code and compiled jpeg xl
|
|
|
_wb_
There used to be a coding tool called 'dots', which would be a representation of small (around 1-2px radius) ellipses, e.g. for stars on a night sky and other dot-shaped image features. Like splines, the idea is that these are hard to compress with the dct, so taking them out and representing them separately would be more effective. Dots had their own quad tree representation for their locations (with subpixel precision iirc), a specific representation for quantized ellipses, and even a specific entropy coding. We simplified the spec by getting rid of it, using patches instead to represent dots if we want to represent dots separately.
The encoder code for detecting dots is still there, but instead of using the 'dots' coding tool to signal them (which no longer exists), it uses patches.
|
|
2023-03-12 03:34:02
|
looking at how the 1 bit images are compressed at q10 e7, I notice that it seems to be the same dots algorithm?
|
|
2023-03-12 03:35:03
|
I was actually surprised when I saw this, a perfect letter in 1 bit color next to the letter in the artifacts
|
|
|
|
diskorduser
|
2023-03-12 04:05:39
|
Is there any way to tell imagemagick to do lossless jpeg transcode?
|
|
|
|
DZgas ะ
|
|
diskorduser
Is there any way to tell imagemagick to do lossless jpeg transcode?
|
|
2023-03-12 04:16:57
|
why do you need lossless jpeg
|
|
|
sklwmp
|
2023-03-12 04:17:08
|
what
|
|
2023-03-12 04:17:11
|
ah
|
|
2023-03-12 04:17:19
|
they mean jxl's ability to losslessy compress jpeg
|
|
2023-03-12 04:17:31
|
i don't think that's exposed in imagemagick, no
|
|
2023-03-12 04:17:35
|
i remember a conversation like this before
|
|
2023-03-12 04:17:48
|
magick can't do it because it works with pixel data, lossless jpeg transcode works on encoded data
|
|
|
|
diskorduser
|
|
sklwmp
magick can't do it because it works with pixel data, lossless jpeg transcode works on encoded data
|
|
2023-03-12 04:24:18
|
Oh okay
|
|
|
|
DZgas ะ
|
|
sklwmp
they mean jxl's ability to losslessy compress jpeg
|
|
2023-03-12 04:24:33
|
yep
|
|
2023-03-12 04:25:02
|
cjxl does transcode by default if the input is jpeg
|
|
2023-03-12 04:26:21
|
imagemagick translates the image into an uncompressed form for next compression. therefore, it does not work so simply
|
|
|
sklwmp
magick can't do it because it works with pixel data, lossless jpeg transcode works on encoded data
|
|
2023-03-12 04:26:56
|
ok
|
|
|
|
diskorduser
|
2023-03-12 04:30:10
|
is there any progress on enabling jxl on gnome web (browser)?
|
|
2023-03-12 04:31:05
|
https://www.reddit.com/r/gnome/comments/11pav5t/gnome_web_44_leaps_and_bounds/
|
|
|
Fraetor
|
|
diskorduser
is there any progress on enabling jxl on gnome web (browser)?
|
|
2023-03-12 04:31:57
|
How does gnome web do its image decoding? Does it use GDK pixbuf, or does it use the formats built into webkit?
|
|
|
|
_wb_
|
|
DZgas ะ
I was actually surprised when I saw this, a perfect letter in 1 bit color next to the letter in the artifacts
|
|
2023-03-12 04:32:56
|
This is thanks to patches. Ideally it would detect all letters to do them with patches. Now it detects some (and they will be fine) while it fails to detect others (and they will have dct artifacts).
|
|
|
|
diskorduser
|
|
Fraetor
How does gnome web do its image decoding? Does it use GDK pixbuf, or does it use the formats built into webkit?
|
|
2023-03-12 04:33:09
|
idk
|
|
|
|
DZgas ะ
|
|
_wb_
This is thanks to patches. Ideally it would detect all letters to do them with patches. Now it detects some (and they will be fine) while it fails to detect others (and they will have dct artifacts).
|
|
2023-03-12 04:34:46
|
works on ~90% of letters
|
|
|
|
_wb_
|
2023-03-12 04:41:19
|
That's nice, but it makes the 10% remaining letters look bad and it's not a very good experience in terms of consistency imo. Hard to find good encoder heuristics for this though...
|
|
|
|
DZgas ะ
|
2023-03-12 08:47:58
|
well. according to the results of my tests, it turned out that it is much more accurate and at the same time much more efficient to use q98-99 with the gaborish=0 prameter instead use modular lossy
|
|
|
|
jonnyawsom3
|
2023-03-12 10:33:55
|
Distance 2+ Gaborish is better on, with some preliminary testing
|
|
2023-03-12 10:35:46
|
Oddly enough, at exactly 2 and more. At 1.9 it's better off
|
|
2023-03-12 10:46:48
|
Scratch that, it adds quite a lot of artefacts, might be worth checking at the very low distances like DZgas said though
|
|
|
|
gb82
|
2023-03-13 04:25:57
|
try converting this to jxl & back to png. it refuses to work for me
|
|
2023-03-13 04:26:27
|
here's my encoded image
|
|
2023-03-13 04:32:10
|
https://github.com/ImageMagick/ImageMagick/issues/6157
|
|
2023-03-13 04:58:09
|
How do I convert to AdobeRGB, like my source PNG?
|
|
2023-03-13 05:03:40
|
|
|
2023-03-13 05:11:05
|
what's the gamma bug?
|
|
2023-03-13 05:13:37
|
wow. looks like I might have to redo my image comparison in sRGB <:PepeHands:808829977608323112>
|
|
2023-03-13 05:22:04
|
djxl is broken too
|
|
|
gb82
https://github.com/libjxl/libjxl/issues/2289
|
|
2023-03-13 05:22:18
|
^
|
|
|
|
DZgas ะ
|
|
Scratch that, it adds quite a lot of artefacts, might be worth checking at the very low distances like DZgas said though
|
|
2023-03-13 07:27:57
|
https://discord.com/channels/794206087879852103/848189884614705192/1084485803482288280 Well no one from the developers has answered me yet
|
|
|
Razor54672
|
2023-03-13 12:52:43
|
Is there a script to batch convert PNGs to JXL (-d 1)?
|
|
|
|
yoochan
|
|
yoochan
I'm stackoverflowing to try to find the equivalent in .bat ๐
|
|
2023-03-13 01:10:14
|
here ^ I tried to provide one
|
|
|
|
Razor54672
|
2023-03-13 01:38:52
|
Thanks!
|
|
2023-03-13 01:39:01
|
I just asked ChatGPT and it gave me a very similar code
|
|
2023-03-13 01:39:05
|
truly a gamechanger
|
|
|
|
yoochan
|
2023-03-13 01:48:59
|
as long as it works
|
|
|
OkyDooky
|
2023-03-13 02:13:36
|
Michael's stance is that he will enable it in Epiphany (GNOME Web) only when some other major browsers do... and he said that to me some months ago, before the Chrome team sabotaged the whole momentum ๐
|
|
|
|
Razor54672
|
|
yoochan
as long as it works
|
|
2023-03-13 02:17:31
|
sheesh, took some time for it to fit my usecase
|
|
|
|
OkyDooky
|
2023-03-13 02:19:07
|
I hope that even with Mozilla's "neutral" stance, Firefox would still proceed to finishing implementing and deploying jxl, but I'm really not holding my breath there... and the add-on that recently showed up exhibits an [incredible RAM & CPU usage bug](https://github.com/zamfofex/jxl-crx/issues/4) even on *wb* / <@794205442175402004> 's art page; I suspect this might be of interest to you folks if you hadn't seen it
|
|
|
|
Razor54672
|
2023-03-13 02:19:17
|
```
INPUT_DIR=""
OUTPUT_DIR=""
for file in "$INPUT_DIR"/*.png
do
filename=$(basename "$file" .png)
"/path/to/cjxl.exe" -d 1 "$file" "$OUTPUT_DIR/$filename.jxl"
done
```
this is the bash script I ended up using
|
|
2023-03-13 02:19:19
|
-
|
|
2023-03-13 02:20:48
|
I was actually converting manga pages to jxl and was curious as to whether there is an optimized setting for the same since it is black and white
|
|
2023-03-13 02:35:23
|
-
|
|
2023-03-13 02:35:24
|
dang
|
|
2023-03-13 02:35:37
|
the png files I had seem to originally have a different file format
|
|
2023-03-13 02:36:05
|
since the resulting jxl files were larger in size
|
|
2023-03-13 02:36:19
|
I am not used to bash ๐
|
|
2023-03-13 02:36:26
|
Windows
|
|
|
|
spider-mario
|
2023-03-13 02:43:57
|
even on windows, actually specifying the .exe suffix is optional
|
|
2023-03-13 02:44:08
|
windows will try the extensions listed in the PathExt environment variable
|
|
2023-03-13 02:44:34
|
(and conversely, on Linux, you could decide to name your binaries something.exe although that would be weird)
|
|
|
|
_wb_
|
2023-03-13 02:48:02
|
CJXL.COM
|
|
|
|
Razor54672
|
|
spider-mario
even on windows, actually specifying the .exe suffix is optional
|
|
2023-03-13 02:53:51
|
ah I see
|
|
2023-03-13 02:54:35
|
btw, is there a way to determine if the png files I have were originally a jpg/webp or not?
|
|
|
|
spider-mario
|
2023-03-13 02:58:38
|
no sure way but there can be hints
|
|
|
|
Razor54672
|
2023-03-13 03:01:08
|
if an image of resolution : `3450*4912` is 855 KiB, it is definitely not lossless right?
|
|
2023-03-13 03:01:24
|
(manga panel)
|
|
|
|
jonnyawsom3
|
2023-03-13 03:02:59
|
I'd suggest zooming in and checking for artefacts
|
|
|
|
Razor54672
|
2023-03-13 03:03:58
|
thing is, upon trying to convert it using cjxl, the result is around 2.3 MiB
|
|
2023-03-13 03:04:00
|
which is weird
|
|
|
|
jonnyawsom3
|
2023-03-13 03:04:33
|
Out of curiosity, try -d 0 and maybe -d 3
|
|
|
|
Razor54672
|
2023-03-13 03:04:57
|
I used -d 1
|
|
|
|
jonnyawsom3
|
2023-03-13 03:05:07
|
Sometimes lossless is better than practically any lossy setting, and I find 3 usually gets past old jpeg artefacts and such
|
|
|
|
Razor54672
|
2023-03-13 03:05:08
|
hmm, I will check still
|
|
2023-03-13 03:06:11
|
1.3 MiB with -d 3
|
|
2023-03-13 03:06:58
|
lossless is 966 KiB
|
|
|
|
_wb_
|
|
Razor54672
if an image of resolution : `3450*4912` is 855 KiB, it is definitely not lossless right?
|
|
2023-03-13 03:07:03
|
if it's not scanned but digitally created, that could be lossless
|
|
2023-03-13 03:07:23
|
try lossless with -g 3
|
|
2023-03-13 03:07:37
|
is it color or b&w?
|
|
|
|
Razor54672
|
2023-03-13 03:07:42
|
black and white
|
|
|
|
_wb_
|
2023-03-13 03:08:09
|
then see if `--patches=0` helps, and/or `-g 3 -I 0 -e 9 -P 0`
|
|
|
|
Razor54672
|
2023-03-13 03:09:12
|
alright, I will try that
|
|
|
|
jonnyawsom3
|
2023-03-13 03:09:28
|
Yeah, -d 0 and -g 3 should get it at least on par with the original file
|
|
|
|
Razor54672
|
2023-03-13 03:11:13
|
that made it go down to 840KiB
|
|
|
|
jonnyawsom3
|
2023-03-13 03:15:33
|
Seeing as the 'original' is only 850KB, think you could send it here?
|
|
|
|
Razor54672
|
2023-03-13 03:16:47
|
yeah sure
|
|
2023-03-13 03:17:22
|
|
|
|
|
spider-mario
|
2023-03-13 03:27:07
|
that looks plausibly lossless to me
|
|
|
|
Razor54672
|
2023-03-13 03:28:46
|
really? why does it not compress well then?
|
|
|
|
afed
|
|
|
Razor54672
|
2023-03-13 03:44:54
|
woah
|
|
2023-03-13 03:44:55
|
nice
|
|
2023-03-13 03:45:09
|
I wonder what's the lower ceiling
|
|
2023-03-13 03:45:25
|
still weird that it doesn't compress all that well tbh
|
|
|
|
_wb_
|
2023-03-13 03:47:33
|
0.27 bpp is quite good compression for lossless, no?
|
|
2023-03-13 03:50:45
|
those dithering patterns are challenging; possibly there is room for improvement to "learn" them better as MA trees or to use patches more effectively
|
|
|
|
Razor54672
|
|
_wb_
0.27 bpp is quite good compression for lossless, no?
|
|
2023-03-13 03:54:08
|
Yeah but no gains with lossy, which I don't get
Although I will admit that I have very limited understanding of the underlying mechanism at play
|
|
|
_wb_
those dithering patterns are challenging; possibly there is room for improvement to "learn" them better as MA trees or to use patches more effectively
|
|
2023-03-13 03:54:53
|
maybe presets depending on content being encoded can be defined with JPEG-AI
|
|
2023-03-13 03:55:39
|
I just tried MozJPEG, WebP and AVIF on Squoosh and none of them are reducing it
|
|