|
Skeebadoo
|
2021-01-30 04:50:45
|
Oh yeah, that too, but there's not much one can do about that
|
|
|
_wb_
|
2021-01-30 04:50:52
|
Photoshop makes it quite easy to do lossy png
|
|
|
spider-mario
|
2021-01-30 04:52:29
|
so does https://pngquant.org/
|
|
|
|
_wb_
|
2021-01-30 04:53:14
|
Lots of pngs are ex-jpegs, sometimes just turned into png to add an alpha channel
|
|
|
|
Skeebadoo
|
2021-01-30 04:54:06
|
True, but at least at that very moment it stops the lossy spiral
|
|
2021-01-30 04:54:34
|
Like, similarly, any capture of analogue source is inherently lossy, but that's the last time you lose data if you fix it in a lossless format
|
|
|
BlueSwordM
|
2021-01-30 04:54:38
|
So, we should just make it that if you encode losslessly, the encoder adds L at the end. 😛
|
|
|
Scope
|
2021-01-30 04:54:43
|
Also many online PNG optimizers use lossy techniques by default
|
|
|
|
_wb_
|
2021-01-30 04:54:51
|
Strictly speaking turning a jpeg into a png adds some extra loss, due to rounding errors in converting ycbcr to rgb...
|
|
|
|
BlueSwordM
|
2021-01-30 04:55:16
|
Lossy encoder = .jxl
Lossless encoder = .jxll
Like what we talked about last time. 😛
|
|
|
lithium
|
2021-01-30 04:55:17
|
probably ex-JPEG can provide some help?, (in dct format jpeg, pik, jpeg xl vardct)
Detector for ex-JPEG images
http://www.imagecompression.info/gralic/Detector.zip
if it's less than 1.05, "NO, this doesn't look like an ex-JPEG image",
if it's less than 1.10, "Maybe: either an ex-JPEG with smart post-processing, or an image with filtering/processing",
and if it's bigger than 1.10, "YES, this looks like an ex-JPEG image".
source: Scope
|
|
|
|
Scope
|
2021-01-30 04:57:41
|
But, even such detectors are not always accurate (especially on Pixel Art and artificial content)
|
|
|
|
lithium
|
2021-01-30 05:00:13
|
Agree , ex-JPEG not always accurate
|
|
2021-01-30 05:05:55
|
In my test, if png pal8 have some weird color banding issue, that png probably use pngquant before, but this method not always accurate.
|
|
2021-01-30 05:08:09
|
and lossy png pal8 probably have some chroma issue(color change)
|
|
2021-01-30 05:10:21
|
if use pingo lossy filter, result png will keep RGBA32 or RGB24, pngquant always output PAL8
|
|
|
|
Deleted User
|
2021-01-30 06:33:56
|
I guess I found a conversion bug?
-q 93 ==> can be viewed
-q 93 --noise=1 ==> Failed to decompress to pixels.
|
|
|
|
_wb_
|
2021-01-30 06:34:22
|
input is png or jpg?
|
|
|
|
Deleted User
|
2021-01-30 06:34:30
|
(Though you probably don't wanna be using noise here)
|
|
2021-01-30 06:34:52
|
It's lossless (webp).
|
|
2021-01-30 06:35:59
|
I would have uploaded the PNG I put into cjxl but that would just waste internet space ;)
|
|
|
I would have uploaded the PNG I put into cjxl but that would just waste internet space ;)
|
|
2021-01-30 06:36:28
|
No, that'd actually be helpful
|
|
|
|
_wb_
|
2021-01-30 06:36:59
|
ok I can reproduce
|
|
|
|
Deleted User
|
2021-01-30 06:37:00
|
I've got a problem with lossless JPEG transcoding, so I've sent there the original, full-size JPEG, without any edits.
|
|
|
_wb_
ok I can reproduce
|
|
2021-01-30 06:38:01
|
I also tried two different programs so I'm sure it's not the PNGs fault.
|
|
|
|
_wb_
|
2021-01-30 06:38:07
|
you can open an issue for this, this should not happen, https://gitlab.com/wg1/jpeg-xl/-/issues
|
|
|
|
Deleted User
|
2021-01-30 06:38:35
|
I don't have a gitlab account. ^^
|
|
|
|
_wb_
|
2021-01-30 06:38:53
|
np, I'll open one then
|
|
|
|
Deleted User
|
2021-01-30 06:39:49
|
thx, and no issue with reuploading my screenshot.
|
|
|
|
lithium
|
2021-01-30 06:43:11
|
use cjxl -d 0.5 -s 7 --gaborish=1 --epf=3, still can't get great result in,
non-photographic image that features high contrast sharp edges and smooth have gradient area,
compressed image have some noise(tiny ringing artefacts) in that area,
i expect that area should be keep smooth and have gradient...
|
|
|
|
_wb_
|
2021-01-30 06:43:35
|
opened an issue <@456226577798135808> , thanks for reporting!
|
|
|
Jim
|
|
Skeebadoo
One thing that bothers me a little is... how will I be able to tell if it's a lossless or lossy jxl?
|
|
2021-01-30 06:44:28
|
Nothing stopping you from saving your files `my_image.lossy.jxl` or `my_image.lossless.jxl` or maybe the shorter `my_image.l.jxl` or `my_image.ll.jxl`.
|
|
|
|
_wb_
|
2021-01-30 06:45:07
|
<@!461421345302118401> maybe just go lossless? `cjxl -q 100 -m`
|
|
|
|
Deleted User
|
2021-01-30 06:46:41
|
Does jxl have an equivalent to near lossless encoding of WebP?
|
|
|
|
_wb_
|
|
|
Deleted User
|
2021-01-30 06:47:20
|
Already usable? (Which command?)
|
|
|
|
_wb_
|
2021-01-30 06:47:23
|
still a bit experimental
|
|
2021-01-30 06:47:29
|
`cjxl -m --lossy-palette --palette=0`
|
|
2021-01-30 06:48:12
|
another near-lossless thing you can try is `cjxl -m -Q 95` (or different number than 95)
|
|
|
|
Deleted User
|
2021-01-30 06:50:08
|
Yes, I already tried -Q 95 but that causes quite some noticeable desaturation in some cases (hopefully that's not another bug) so I wouldn't wanna use that. ^^
|
|
|
|
_wb_
|
2021-01-30 06:50:32
|
maybe -Q 99
|
|
2021-01-30 06:50:46
|
desaturation is a bit strange though
|
|
2021-01-30 06:51:10
|
sure it's not some kind of color profile / gamma issue in your viewer?
|
|
|
|
spider-mario
|
|
_wb_
`cjxl -m --lossy-palette --palette=0`
|
|
2021-01-30 06:51:55
|
also `-P 0`
|
|
|
|
Deleted User
|
2021-01-30 06:55:39
|
<@!794205442175402004> Look at the yellow to the left of Lara.
|
|
2021-01-30 06:55:44
|
|
|
|
|
_wb_
|
2021-01-30 06:58:26
|
I have a hard time spotting a difference tbh
|
|
|
|
spider-mario
|
2021-01-30 06:58:29
|
looks the same to me
|
|
|
|
Deleted User
|
2021-01-30 06:59:11
|
really, it's way more blue to my eyes
|
|
|
|
spider-mario
|
2021-01-30 06:59:32
|
viewing both the webp and the decoded png in Chrome, which should take any embedded ICC profile into account
|
|
|
|
_wb_
|
2021-01-30 07:00:42
|
decoded jxl produces a png with this:
```
png:cHRM: chunk was found (see Chromaticity, above)
png:gAMA: gamma=0.45455 (See Gamma, above)
png:IHDR.bit-depth-orig: 8
png:IHDR.bit_depth: 8
png:IHDR.color-type-orig: 2
png:IHDR.color_type: 2 (Truecolor)
png:IHDR.interlace_method: 0 (Not interlaced)
png:IHDR.width,height: 2560, 1440
png:sRGB: intent=1 (Relative Intent)
```
|
|
|
|
Deleted User
|
2021-01-30 07:00:47
|
But 85 makes it even more pronounced.
|
|
|
|
lithium
|
2021-01-30 07:01:12
|
<@!794205442175402004> lossy compression is fine, in d0.5|q95 image is visually lossless (flicker-test), only that area can perceive some issue.
|
|
|
|
_wb_
|
2021-01-30 07:01:26
|
while decoded webp produces a png with this:
```
png:IHDR.bit-depth-orig: 8
png:IHDR.bit_depth: 8
png:IHDR.color-type-orig: 2
png:IHDR.color_type: 2 (Truecolor)
png:IHDR.interlace_method: 0 (Not interlaced)
png:IHDR.width,height: 2560, 1440
png:sRGB: intent=0 (Perceptual Intent)
```
|
|
|
|
spider-mario
|
2021-01-30 07:01:37
|
still same
|
|
|
|
_wb_
|
2021-01-30 07:02:09
|
maybe the gAMA chunk is causing trouble in some viewers?
|
|
|
|
spider-mario
|
2021-01-30 07:02:13
|
just to clarify, do you mean our left? (but I checked both just in case)
|
|
|
|
_wb_
|
2021-01-30 07:02:14
|
or the rendering intent
|
|
|
|
Deleted User
|
2021-01-30 07:03:10
|
yes, our left, especially the bright yellow towards the ledge.
|
|
2021-01-30 07:03:31
|
Could you send back your decoded PNG?
|
|
|
|
spider-mario
|
|
|
Deleted User
|
2021-01-30 07:06:02
|
It's definitely still there.
|
|
|
|
_wb_
|
2021-01-30 07:06:21
|
i cannot spot any difference in eog, Preview, or Chrome
|
|
|
|
Deleted User
|
2021-01-30 07:06:42
|
Does this mean I have strange eyes? <:ugly:805106754668068868>
|
|
|
|
spider-mario
|
2021-01-30 07:06:57
|
maybe take a screenshot of each?
|
|
|
|
_wb_
|
2021-01-30 07:07:11
|
no, it means you probably have a viewer that does something different than ours
|
|
|
|
spider-mario
|
2021-01-30 07:07:21
|
so we could see what pixel values your viewer is sending to your display
|
|
|
|
_wb_
|
2021-01-30 07:07:40
|
decoded jxl
|
|
2021-01-30 07:08:18
|
decoded webp
|
|
|
|
spider-mario
|
2021-01-30 07:08:20
|
maybe your viewer does color management on one image type and not the other?
|
|
|
|
_wb_
|
|
|
spider-mario
|
2021-01-30 07:08:54
|
let me prepare a test image for your viewer
|
|
|
|
Deleted User
|
2021-01-30 07:09:08
|
Wait, I create an animated webp for you.
|
|
|
|
spider-mario
|
2021-01-30 07:11:00
|
<@456226577798135808> what color is the bench in the following image in your viewer?
|
|
2021-01-30 07:11:07
|
|
|
|
|
_wb_
|
2021-01-30 07:11:13
|
ugh discord preview image seems to ignore color profiles, that screenshot is Display P3 and it looks like it just shows that as if it were sRGB
|
|
|
|
Deleted User
|
2021-01-30 07:11:29
|
https://res.cloudinary.com/mattgore/flicker85.webp
|
|
|
|
_wb_
|
2021-01-30 07:11:45
|
lol that is a good test image 🙂
|
|
|
|
Deleted User
|
2021-01-30 07:11:59
|
res.cloudinary.com/mattgore/flicker85.webp
|
|
|
|
_wb_
|
2021-01-30 07:12:08
|
good to demonstrate crappy discord preview generation
|
|
|
|
Deleted User
|
2021-01-30 07:12:55
|
Anyone from the community that could support my eyes? ^^
|
|
|
|
_wb_
|
2021-01-30 07:13:53
|
aah I wasn't looking there
|
|
2021-01-30 07:14:00
|
yes I see a slight color shift now
|
|
2021-01-30 07:14:28
|
quite minor but yes there is some difference
|
|
|
|
Deleted User
|
2021-01-30 07:15:16
|
😀 phew, and I thought I need to call the doctor.
|
|
|
|
spider-mario
|
2021-01-30 07:15:44
|
I still don’t 😒
|
|
|
|
_wb_
|
2021-01-30 07:15:52
|
no you have good eyes, I didn't catch that color shift myself
|
|
|
|
spider-mario
|
2021-01-30 07:16:06
|
wut discord, that’s not how I imagine “:s”
|
|
|
|
_wb_
|
2021-01-30 07:16:33
|
I first thought the apng was not even changing, took a while before I saw it
|
|
|
|
Deleted User
|
|
spider-mario
I still don’t 😒
|
|
2021-01-30 07:16:36
|
Maybe check if your viewer supports animated WebP?
|
|
|
|
spider-mario
|
2021-01-30 07:17:29
|
it does, I see some slight movement
|
|
2021-01-30 07:17:31
|
but it’s not chromatic
|
|
2021-01-30 07:17:45
|
I’ve also tried flipping manually between two Chrome tabs
|
|
|
|
_wb_
|
2021-01-30 07:18:32
|
the animation is between orig and -m -Q 85 ?
|
|
|
|
Deleted User
|
2021-01-30 07:20:04
|
Yes, but -Q 95 is still pretty obvious for me since it affects a rather large area and persists even when scaled down.
|
|
|
|
spider-mario
|
2021-01-30 07:20:07
|
but maybe the color is outside of my display’s gamut and gets clipped
|
|
|
|
_wb_
|
2021-01-30 07:20:58
|
I'm using a P3 macbook, I can see it but not obvious at all
|
|
|
|
Deleted User
|
2021-01-30 07:21:44
|
Does this have 3 subpixels per pixel?
|
|
|
|
_wb_
|
2021-01-30 07:24:33
|
I assume so, but no clue. It's a 2019 macbook pro
|
|
|
|
spider-mario
|
2021-01-30 07:25:40
|
I think so, rare are those that have experimented with more than 3 primaries
|
|
2021-01-30 07:25:50
|
some OLED displays are starting to add a white subpixel
|
|
|
|
Deleted User
|
|
spider-mario
but maybe the color is outside of my display’s gamut and gets clipped
|
|
2021-01-30 07:25:58
|
But if you zoom, you can clearly see that blue pixels are added where none where in the original.
|
|
|
|
_wb_
|
2021-01-30 07:26:57
|
not at home right now but I do have a calibrated monitor there which can display sRGB images like this without any gamut clipping at all
|
|
2021-01-30 07:28:33
|
the added blue could be an artifact of using XYB
|
|
2021-01-30 07:28:41
|
lossy modular uses XYB by default
|
|
|
|
spider-mario
|
|
But if you zoom, you can clearly see that blue pixels are added where none where in the original.
|
|
2021-01-30 07:28:44
|
ah, a very little bit, but I more or less need to stick my nose to the display for that 😁
|
|
|
|
_wb_
|
2021-01-30 07:29:39
|
can try `-m -Q 95 -c 1` to use RGB instead (or rather it will do YCoCg in this case, but conceptually it's RGB at the FrameHeader level)
|
|
2021-01-30 07:30:17
|
at the near-lossless end, it might be better to stay in RGB instead of going to XYB
|
|
|
|
Deleted User
|
|
spider-mario
ah, a very little bit, but I more or less need to stick my nose to the display for that 😁
|
|
2021-01-30 07:33:20
|
I don't see the pixels itself but how they neutralize the yellow.
|
|
|
_wb_
can try `-m -Q 95 -c 1` to use RGB instead (or rather it will do YCoCg in this case, but conceptually it's RGB at the FrameHeader level)
|
|
2021-01-30 07:33:43
|
Ah, yes, great, thx. That fixed the issue.
|
|
|
|
lithium
|
2021-01-30 07:34:58
|
if in cjxl -d 0.5 -s 7, compress high contrast sharp edges and smooth have gradient area,
still can't reach visually lossless (flicker-test), have some noise issue in smooth have gradient area,
probably that noise issue is vardct mode limit?, only lossless can keep that area visually lossless?
|
|
|
|
_wb_
|
2021-01-30 07:38:13
|
in principle, `cjxl -d 0.3 -s 8` should pass a flicker-test, but maybe you have an exceptionally hard image
|
|
|
|
lithium
|
2021-01-30 07:39:42
|
in avif that smooth area can compress very well, but avif have other issue...
|
|
2021-01-30 07:41:20
|
i post some data in encode jxl post, https://encode.su/threads/3544-JXL-reference-software-version-0-2-released?p=68459&viewfull=1#post68459
|
|
2021-01-30 07:43:27
|
in that image everything is great, only that area...
|
|
|
|
_wb_
|
2021-01-30 07:45:10
|
I see what you mean, but you need quite extreme zoom-in to see that, imo
|
|
2021-01-30 07:46:20
|
we normally assume a viewing distance of 900 pixels
|
|
|
|
lithium
|
2021-01-30 07:46:26
|
i test this image use chrome in flicker-test
|
|
2021-01-30 07:48:07
|
in original image that area should keep smooth, but -d 0.5 will increase some stuff
|
|
|
|
_wb_
|
2021-01-30 07:48:45
|
yes, I can see it when I pixel-peep and turn up display brightness to max
|
|
|
|
lithium
|
2021-01-30 07:49:34
|
i using 1080 va screen
|
|
|
|
_wb_
|
2021-01-30 07:51:11
|
DCT is not ideal for these kind of images
|
|
2021-01-30 07:51:39
|
I hope at some point we'll have an encoder that uses splines and modular to encode some of this
|
|
|
|
lithium
|
2021-01-30 07:53:30
|
In artist(painter) community, they use jpeg yuv444 and q99~100 in this type image
|
|
2021-01-30 07:56:26
|
i don't think use jpeg above q95 is a good idea, hope someday can let artist(painter) community use jpeg xl...
|
|
|
|
_wb_
|
2021-01-30 07:57:34
|
you can also try `-m -Q 97 -c 1` and see if that works well
|
|
2021-01-30 07:58:53
|
also maybe lossless with `-m -q 100 -g 0 -E 3 -s 9 -I 1` could give good compression
|
|
|
|
Deleted User
|
2021-01-30 07:59:57
|
Is there a rule of thumb which -g 0,1,2,3 fits best to a given image type?
|
|
2021-01-30 08:00:15
|
(Sorry for so many questions.^^)
|
|
|
|
_wb_
|
2021-01-30 08:04:23
|
not really, I am often surprised which one works best
|
|
2021-01-30 08:05:48
|
-g 0 tends to work well if there are few different colors in each 128x128 group, because it makes it more likely that effective per-group palette can be done
|
|
|
|
lithium
|
2021-01-30 08:07:11
|
-m -Q 97 -c 1 result is better than vardct, modular blurry smooth area tiny noise, this is good for vision
|
|
|
|
_wb_
|
2021-01-30 08:07:48
|
-g 3 tends to work well if a global palette is as good as a per-group palette, because it maximally avoids poorly-predicted group boundaries (groups are 1024x1024, their top row and left column is not well-predicted because predictors do not look over group boundaries, to keep groups decodable in parallel)
|
|
|
|
lithium
|
2021-01-30 08:13:35
|
<@!794205442175402004> Thank you very much :), now i understand this is a dct limit, not a issue
|
|
2021-01-30 08:18:05
|
A little curious, in encode post, @Jyrki Alakuijala say
I had an off-by-one for smooth area detection heuristic and those areas were detected 4 pixels off.
probably optimize smooth area detection heuristic can handle this?
https://encode.su/threads/3544-JXL-reference-software-version-0-2-released?p=68252&viewfull=1#post68252
|
|
|
raysar
|
2021-01-31 04:43:26
|
cjxl.exe .\mousse.jpg .\mousse.jxl -d 0 -s 9
It's not lossless at all, can you verrify? zoom 2000% look at color changing
|
|
2021-01-31 04:43:30
|
|
|
2021-01-31 04:46:00
|
question: in lossless jpeg transcoding, there is no deblocking option for the decoder?
|
|
|
|
_wb_
|
2021-01-31 07:02:58
|
Not at the moment
|
|
2021-01-31 07:03:53
|
Djxl does render jpegs somewhat differently from libjpeg-turbo, maybe that's what you are seeing?
|
|
2021-01-31 07:05:15
|
Do `djxl -j foo.jxl foo.jpg` to get back the jpeg as a jpeg, so you can view with the same jpeg viewer
|
|
2021-01-31 07:07:40
|
The old jpeg is not defined pixel-exactly, e.g. you are allowed to implement the dct with quite low precision. So different jpeg decoders give slightly different results.
|
|
|
Pieter
|
|
_wb_
The old jpeg is not defined pixel-exactly, e.g. you are allowed to implement the dct with quite low precision. So different jpeg decoders give slightly different results.
|
|
2021-01-31 07:21:50
|
TIL
|
|
|
|
_wb_
|
2021-01-31 07:32:43
|
The original conformance was quite permissive: all they required was that the decoded image, when applying the DCT again, with the same quantization factors, would be within off-by-ones. iirc.
|
|
2021-01-31 07:34:02
|
So decoders strictly speaking don't even have to respect the dequantization buckets, you can move into adjacent buckets and still be 'correct'
|
|
|
|
spider-mario
|
2021-01-31 07:48:06
|
there is also the issue of chroma interpolation, does the JPEG specification say anything about this?
|
|
2021-01-31 07:48:29
|
nearest neighbor vs. even bilinear can make quite a difference
|
|
|
|
_wb_
|
2021-01-31 08:12:07
|
original JPEG spec does not say anything at all about even YCbCr
|
|
2021-01-31 08:12:13
|
it's just "components"
|
|
2021-01-31 08:12:44
|
JFIF specified something
|
|
2021-01-31 08:14:02
|
it wasn't until JPEG XT parts 1 and 4 that things were made a bit more specific
|
|
2021-01-31 08:14:32
|
retroactively turning the de facto standard into an actual standard
|
|
2021-01-31 08:15:48
|
(that was in 2015)
|
|
|
|
lithium
|
2021-01-31 09:05:36
|
Hello, lossy modular use which color transform YCoCg or XYB?
|
|
|
|
_wb_
|
2021-01-31 09:22:10
|
XYB by default, if you want YCoCg you have to do `-c 1`
|
|
|
|
lithium
|
2021-01-31 09:24:28
|
in non-photographic image which color transform is better?
|
|
|
|
_wb_
|
2021-01-31 09:32:51
|
I think it mostly depends on how lossy you want to go. For near-lossless, probably YCoCg will be better.
|
|
|
|
lithium
|
2021-01-31 09:47:21
|
In encode post, i still don't understand this description,
some kind of maximum difference per pixel guaranty,
non-photographic image is conform this condition?
And if i care fidelity(perceptual optimization) in non-photographic image,
What should i pay attention to lossy modular?
jpeg xl 0.2 post:
I don't really recommend lossy modular mode at all as it is right now –
I think the only thing it might be good for, is if you don't care about perceptual optimization
but you want to do something lossy with some kind of maximum difference per pixel guaranty
https://encode.su/threads/3544-JXL-reference-software-version-0-2-released?p=68182&viewfull=1#post68182
|
|
|
|
_wb_
|
2021-01-31 09:51:13
|
lossy modular just quantizes residuals in the same way everywhere in the image, so it doesn't try to do any perceptual optimization (like taking contrast masking into account etc)
|
|
|
|
lithium
|
2021-01-31 09:54:22
|
probably like cwebp near-lossless 60?, use lossy filter
|
|
|
|
_wb_
|
2021-01-31 09:55:39
|
modular can do lossy in several ways, default way is to quantize Squeeze residuals which is the FUIF way, not the webp-near-lossless way
|
|
|
|
lithium
|
2021-01-31 10:00:44
|
if non-photographic image don't so many tiny detail(natural content), only have Artificial detail(synthetic content), probably lossy modular is best method in those image?
|
|
|
|
_wb_
|
2021-01-31 10:02:14
|
yes, it could be
|
|
|
|
lithium
|
2021-01-31 10:05:45
|
I use lossy modular in cjxl -m -Q 95 -s 9 -g 3 -E 3 -I 1 , i should add which flag to get best compress?
|
|
|
|
_wb_
|
2021-01-31 10:20:08
|
can try `cjxl -m -Q 95 -s 9 -g 3 -E 3 -I 1 -c 1`
|
|
|
|
lithium
|
2021-01-31 10:21:20
|
-c 1 will effect quality?, or just effect compress size?
|
|
|
|
_wb_
|
2021-01-31 10:21:29
|
can also try setting luma and chroma quality separately, e.g. `-Q 96,94`
|
|
2021-01-31 10:22:05
|
`-c 1` sets the color space from XYB to YCoCg so it does something quite different, affects quality
|
|
|
|
lithium
|
2021-01-31 10:32:46
|
if lossy modular(XYB) result is fine, how to use --palette transform on less color image?
|
|
2021-01-31 10:35:06
|
cjxl -m -Q 95 -s 9 -g 3 -E 3 -I 1 --lossy-palette --palette=0
|
|
2021-01-31 10:36:19
|
oh...
|
|
2021-01-31 10:36:38
|
--lossy-palette --palette=0 break my image...
|
|
|
|
_wb_
|
2021-01-31 10:44:15
|
don't use it in combination with -Q 95, that will probably do weird stuff
|
|
|
|
spider-mario
|
2021-01-31 10:52:33
|
also, you probably want -P 0 with it
|
|
2021-01-31 10:52:41
|
to use the “zero” predictor on palette indices themselves
|
|
2021-01-31 10:53:11
|
it won’t affect quality but should be slightly denser
|
|
|
|
lithium
|
2021-01-31 11:02:57
|
-m -Q 95 -s 9 --lossy-palette --palette=0
|
|
2021-01-31 11:03:01
|
|
|
|
|
_wb_
|
2021-01-31 11:05:03
|
that's a nice one for <#805007255061790730> 🙂
|
|
|
|
lithium
|
|
|
_wb_
|
2021-01-31 11:06:29
|
yes, combining Squeeze (`-Q 95`) with delta-palette (`--lossy-palette`) is not going to produce something useful, I'm somewhat surprised it doesn't crash on encode or decode
|
|
|
|
lithium
|
2021-01-31 11:08:15
|
cjxl -m -Q 95 -s 9 -g 3 -E 3 -I 1 --palette=0, can transform some less color image to palette(lossless)?
|
|
|
|
_wb_
|
2021-01-31 11:10:55
|
the default is to try to use a palette if that can be done losslessly, but only at `-m -q 100`
|
|
2021-01-31 11:11:15
|
when you do `-Q 95` it does Squeeze and then palette is not a good idea
|
|
|
|
lithium
|
2021-01-31 11:14:45
|
probably can let cjxl choose if can transform to palette(lossless) use palette, else use -m -Q95 in some less color image ?
|
|
|
|
_wb_
|
2021-01-31 11:39:47
|
We don't have an option for that atm
|
|
2021-01-31 11:40:33
|
Can also try --palette 10000 to allow larger palettes and see if it helps for compression
|
|
|
OkyDooky
|
2021-01-31 12:40:48
|
VarDCT/PIK-based compression always allowed some level of progression. This is still always available in VarDCT mode. Minimally 8x8 progression + ordering of 256x256 AC groups making the image slightly more responsive. If you need 16x16 etc. then you need to explicitly store the DC in progressive mode. We may start using that as a default when we get more experience with it -- it already outperfoms the direct DC in the lowest quality compression, but is still slightly worse in high quality.
(<@456226577798135808>)
|
|
2021-01-31 12:42:39
|
Thank you. Our main philosophy is 'no flags needed' and the system should always do reasonable choices. However, we are weak and the demands can be exotic. We will try to be better here. Please consider filing issues on the gitlab when you find improvement possibilities on this.
(<@456226577798135808>)
|
|
2021-01-31 12:45:05
|
AV1 was developed for high density and hardware coding initially. That is why they needed a specialized effort for fast software decoding. JPEG XL was developed for high density, high quality and software coding. The initial version is already very fast on software (there are some catches here, but the decoding speed situation is much better than with AV1 and even Dav1d).
(<@456226577798135808>)
|
|
2021-01-31 12:46:08
|
I'm working on this. I consider this work 15 % complete now, and I have another 15 % in the pipeline.
(<@461421345302118401>)
|
|
|
|
_wb_
|
2021-01-31 12:54:04
|
Hi jyrki - if you use discord itself (not the Matrix) I can assign the core dev role to you
|
|
|
|
OkyDooky
|
2021-01-31 12:55:53
|
I'm removing (or have already removed, not sure about releasing) the -s 9 mode and making the -s 8 mode run in -s 9 for VarDCT. At that time I add a new -s 8 mode.I consider the previous -s 9 too slow for most practical uses and it doesn't work for all uses. Particularly, its DC quantization algorithm is horribly broken and only works in the proximity of d1.0
(<@461421345302118401>)
|
|
2021-01-31 12:59:52
|
We had about five implementations of it. The first time we implemented as an intern project in WebP lossless. I like the current version, but it can be further improved, possibly 20 % or so. I don't have this prioritized right now and anticipate that I can work on this during next summer or so. The team is busy with 'productionizing' features like stabilising the API, increasing security, and reducing memory use.
|
|
2021-01-31 01:03:01
|
I proposed AFV after observing that several 8x8 DCTs caused large distance ringing when one corner was touching another object. There were ideas/implementation of it from me (Alakuijala), Thomas Fischbacher and Versari, so we decided to call it by our names. There is not much elegance in it, it is not super-effective, but it works and reduced the ringing distance and compression density slightly.
(<@167023260574154752>)
|
|
2021-01-31 01:04:44
|
AFV uses one horizontally placed 8x4 DCT and two 4x4 DCTs, with one of the 4x4 DCTs manipulated by a 3 pixel corner cut into a more separate model.
(<@167023260574154752>)
|
|
|
lonjil
|
2021-01-31 01:06:03
|
Ah, interesting
|
|
|
|
OkyDooky
|
2021-01-31 01:10:05
|
There's another trick an encoder could use to reduce mosquitos near edges that does not even require any change of the format. Interested? \:)
|
|
2021-01-31 01:12:36
|
You may be aware of this possibility, but... here it goes\: https://ieeexplore.ieee.org/document/1006398 called SNS (spatial noise shaping)
|
|
2021-01-31 01:14:02
|
A very similar idea already exists in MPEG AAC for audio coding called TNS (temporal noise shaping). The principle is the same but the implemenation is different in that TNS is a dedicated coding tool a decoder has to support.
|
|
|
fab
|
2021-01-31 01:14:04
|
jyri comparison with wp2 with degrading quality, is better degrading (low bitrates) than cavif rs 0.6.6+q 94.8 -s 5?
|
|
2021-01-31 01:14:12
|
when someone will do a comparison?
|
|
2021-01-31 01:14:24
|
after April
|
|
2021-01-31 01:14:31
|
or we'll have comparison before?
|
|
|
|
lithium
|
2021-01-31 01:43:33
|
@jyrkialakuijala, <@!794205442175402004> thank you very much :),
@jyrkialakuijala
In previous discuss(discord), i report this issue to Jon Sneyers,
I think probably vardct can't handle very well on high contrast sharp edges and smooth have gradient area,
and this situation probably is vardct process limit, not a issue?
|
|
|
|
Deleted User
|
|
_wb_
can try `-m -Q 95 -c 1` to use RGB instead (or rather it will do YCoCg in this case, but conceptually it's RGB at the FrameHeader level)
|
|
2021-01-31 02:53:01
|
I just wonder, VarDCT uses XYB as well, right? So why do we only see the saturation issues with modular encoding?
|
|
|
|
_wb_
|
2021-01-31 02:53:57
|
Probably because modular does not even try to be perceptual, it just does uniform quantization
|
|
|
|
Deleted User
|
|
lithium
probably like cwebp near-lossless 60?, use lossy filter
|
|
2021-01-31 03:03:55
|
You can try just converting your image to a near lossless webp or flif 90 and then to lossless jxl. ;)
|
|
|
chuni
|
2021-01-31 04:20:19
|
Hey all, sorry if this is the wrong place but I just wanted to get a sanity check for the issue I just posted: https://gitlab.com/wg1/jpeg-xl/-/issues/131. Am I just doing something wrong here?
|
|
|
|
Deleted User
|
2021-01-31 04:23:23
|
They might not be bit-exact, but you can quickly check for being image-exact by uploading them as two layers into GIMP, changing mode of one of them to `Difference`, flattening the image into one later and cranking up the brightness. If you see something, it means the difference is non-zero and thus the compression isn't mathematically image-exact.
|
|
|
|
_wb_
|
2021-01-31 04:23:31
|
The issue is correct, it's a duplicate though
|
|
2021-01-31 04:23:53
|
Workaround for now is `-m -q 100`
|
|
|
|
chuni
|
2021-01-31 04:23:55
|
Ah, I see the duplicate issue now
|
|
2021-01-31 04:24:05
|
Thank you!
|
|
|
|
_wb_
|
2021-01-31 04:24:12
|
I messed up cjxl default behavior
|
|
|
|
Deleted User
|
2021-01-31 04:24:31
|
I'll leave my explanation for the record, ok?
|
|
|
|
_wb_
|
2021-01-31 04:25:08
|
Easiest way to check lossless is `compare -metric pae foo.png bar.png null:`
|
|
|
|
Deleted User
|
2021-01-31 04:25:36
|
Easiest if you're using Linux. I'm on Windows, don't have those tools installed and prefer to check for the difference visually.
|
|
|
|
chuni
|
2021-01-31 04:26:09
|
Just an fyi, ImageMagick claims the image signature generated by `identify -format "%#"` is format agnostic and based on pixel values rather than bit values
|
|
|
|
_wb_
|
2021-01-31 04:26:27
|
Yes, can also do that
|
|
2021-01-31 04:28:38
|
Hm I wonder if the <#805062027433345044> bot is broken or just slow
|
|
2021-01-31 04:29:51
|
Anyway I hope we can get a 0.3.1 out soon to fix my oopsie
|
|
|
|
lonjil
|
2021-01-31 04:31:32
|
Is there any way to figure out if a difference is small enough to be explained purely from losses from color space conversion?
|
|
|
|
chuni
|
2021-01-31 04:31:49
|
For curiosity's sake, what cli args in the future would get these sort of results? They seem near visually lossless with a difference only in pixel LSBs
|
|
|
|
lonjil
|
2021-01-31 04:32:05
|
Some tools will tell you exactly how big the differences are but I don't know how to interpret really small differences.
|
|
|
|
_wb_
|
2021-01-31 04:34:21
|
You can do `compare -verbose -metric pae`, @Lonnie. For RGB to YCbCr444 and back you should get no more than off-by-ones in G and off-by-twos in R,B, iirc
|
|
|
|
lonjil
|
|
|
_wb_
|
2021-01-31 04:34:46
|
Or maybe off-by-3 for R,B
|
|
|
chuni
For curiosity's sake, what cli args in the future would get these sort of results? They seem near visually lossless with a difference only in pixel LSBs
|
|
2021-01-31 04:35:52
|
Currently -q 100 without the -m does the same as default, i.e. distance 1 vardct
|
|
|
|
lonjil
|
2021-01-31 04:36:12
|
How well does 32 bit fp XYB do? My understanding is that it does a better job with this compared to 8 bit int per channel encodings.
|
|
|
|
_wb_
|
2021-01-31 04:36:50
|
32 bit fp is plenty of precision to roundtrip 8-bit input losslessly
|
|
|
|
lonjil
|
2021-01-31 04:37:04
|
Nice
|
|
2021-01-31 04:37:41
|
I wasn't sure because I had some roundtripping problems with jxl last year.
|
|
|
|
_wb_
|
2021-01-31 04:39:03
|
Well of course color conversion isn't the only thing lossy encoding does, after dct and quantization it's of course no longer precise enough to roundtrip losslessly
|
|
|
|
lonjil
|
2021-01-31 04:40:17
|
Yeah. Last year I only ever tested jpeg transcoding (which is ofc working fine for me now) and modular mode.
|
|
2021-01-31 04:41:37
|
Also, my friend who has tested decoders before told me that he doesn't have time for that kind of stuff right now, but he sent me some information about fuzz testing so maybe I'll try to find some bugs later.
|
|
|
|
_wb_
|
2021-01-31 04:42:10
|
We have already done quite a bit of fuzzing
|
|
|
|
lonjil
|
|
|
_wb_
|
2021-01-31 04:42:37
|
I think there's stuff in the repo for it too
|
|
2021-01-31 04:44:29
|
The author of afl++ is also fuzzing djxl for us, btw
|
|
|
|
lonjil
|
2021-01-31 04:44:39
|
Ooh nice
|
|
2021-01-31 04:44:45
|
Way above my league then haha
|
|
|
|
_wb_
|
2021-01-31 04:45:37
|
Need to find all the malicious stuff people could try, if we want this in chrome
|
|
|
|
lonjil
|
2021-01-31 04:47:40
|
I have a pretty huge collection of random internet images. Might do a large benchmark (admittedly niche content) and then try roundtripping everything while running under UBsan and such. I figure you've done a fair share of that but more is better.
|
|
2021-01-31 04:49:52
|
How do you.think the chances are of cjxl making bad images when using sane options?
|
|
|
bonnibel
|
2021-01-31 04:58:38
|
(🤔 I wonder how long it'll take for someone to make a Rust library)
|
|
|
|
lonjil
|
2021-01-31 04:59:45
|
That's what my friend keeps asking
|
|
|
|
bonnibel
|
2021-01-31 04:59:52
|
sfghjkkkl
|
|
|
|
chuni
|
2021-01-31 05:01:14
|
I could see the benefits of a rust decoder, but would there be any benefit to a rust impl of the encoder? Performant rust generally requires assembly which can mean removing some of the safety guarantees of rust
|
|
|
|
bonnibel
|
2021-01-31 05:02:31
|
Assuming you can keep it largely in safe Rust, it could be used for transcoding user-submitted images to jxl for supporting browsers
|
|
|
|
lonjil
|
2021-01-31 05:04:05
|
Performant rust generally doesn't require ASM. It requires ASM to be as performant as ASM implementations, but afaik regular rust is about as fast as regular C/C++. Though I don't use Rust.
|
|
2021-01-31 05:04:23
|
I'm planning to write decoders in Common Lisp and Zig.
|
|
|
Toggleton
|
|
bonnibel
(🤔 I wonder how long it'll take for someone to make a Rust library)
|
|
2021-01-31 05:45:15
|
did find this but not sure if that is more than a wrapper 🤔 https://github.com/saschanaz/jxl-rs
|
|
|
|
bonnibel
|
2021-01-31 05:46:54
|
Yeah, that's just bindings I think
|
|
|
|
_wb_
|
2021-01-31 05:54:10
|
<@579137895110279168> can you put a link to your viewer in <#803663417881395200>?
|
|
2021-01-31 05:54:37
|
Also, what are your plans wrt medical images? Are you involved in DICOM?
|
|
|
yllan
|
|
_wb_
Also, what are your plans wrt medical images? Are you involved in DICOM?
|
|
2021-01-31 06:12:23
|
I'm working on PACS. My company is trying to store DICOM files with our own DICOM packer (like Lepton/brunsli for JPEG) to reduce storage usage. I think JXL is a good fit for us.
|
|
|
|
_wb_
|
2021-01-31 06:17:54
|
DICOM is also interested in perhaps getting jxl in a future DICOM version, I went to some of their meetings
|
|
|
|
lithium
|
2021-01-31 06:51:47
|
<@!794205442175402004> Hello, I taking some jxl notes, could you teach me about this principle (some kind of maximum difference per pixel guarantee), i need more information or some example.
|
|
|
|
_wb_
|
2021-01-31 07:00:47
|
-m -Q 95 does the Squeeze transform and then does uniform quantization on the residuals, where the quantization only depends on the channel and on the zoom level
|
|
2021-01-31 07:01:19
|
So the per-pixel error should be bounded
|
|
2021-01-31 07:01:49
|
with a bound that depends on the -Q value
|
|
|
|
lithium
|
2021-01-31 07:13:05
|
in photographic image, natural content will let per pixel have small difference, so vardct mode can work well,
in non-photographic, synthetic content will let per pixel have big difference, so modular mode can work well,
probably like this?, maybe i made a mistake?
|
|
|
|
_wb_
|
2021-01-31 07:40:29
|
Yes, non-photo usually has lots of sharp edges. DCT is not good at compressing sharp edges, especially things like text are hard for DCT. Modular tends to be better for non-photo content.
|
|
|
Master Of Zen
|
2021-01-31 08:23:15
|
Is it possibleplaned to have Python/Rust butteraugli?
|
|
|
|
_wb_
|
2021-01-31 08:38:11
|
not afaik, but maybe we could make a library version of the metrics (also ssimulacra, and could add more), and then make some python/rust/whatever bindings
|
|
2021-01-31 08:40:07
|
also the `benchmark_xl` tool that we mostly used for development could be split off and turned into a separate tool (that uses the metrics library, libjxl and whatever other codecs you want to test)
|
|
2021-01-31 08:43:01
|
`benchmark_xl` was made just for internal testing: basically every merge request on the private development repo that could affect quality or compression had benchmark results in the description (also CI bots generated some of them automatically), so regressions were easy to spot and trade-offs between speed, density and quality could be judged in a consistent way
|
|
|
|
OkyDooky
|
2021-01-31 08:55:10
|
Is there some parameter or assumption about the size of a pixel as projected onto the retina (w.r.t. the quantization matrices)?
|
|
2021-01-31 08:55:57
|
(I guess, to some extend this can be controlled with the quality slider?)
|
|
2021-01-31 08:56:26
|
(just asking out of curiosity)
|
|
2021-01-31 08:57:04
|
[Edit](https://discord.com/channels/794206087879852103/794206170445119489/805541910642163713): (I guess, to some extent this can be controlled with the quality slider?)
|
|
|
|
_wb_
|
2021-01-31 08:59:53
|
no specific parameter for that
|
|
2021-01-31 09:02:02
|
overall quality and shape of the quantization matrices (more emphasis on LF or HF) can control that - in general the smaller the retina angle per pixel the less HF precision and the more LF precision you need, relatively (and the less precision overall)
|
|
2021-01-31 09:03:49
|
current `cjxl` default settings are aiming at being at or below 1 unit of just-noticeable-difference at a viewing distance of 900 pixels, i.e. Butteraugli distance 1
|
|
2021-01-31 09:05:00
|
which is roughly the kind of viewing conditions that are typical for phones, laptops, desktops.
|
|
|
|
spider-mario
|
2021-01-31 09:29:06
|
is it 900 specifically? I thought I remembered 1000 but I may have rounded up mentally
|
|
|
|
_wb_
|
2021-01-31 09:30:50
|
I'm going by what jyrki has said about it, e.g. https://encode.su/threads/3544-JXL-reference-software-version-0-2-released?p=68297&viewfull=1#post68297
|
|
2021-01-31 09:33:03
|
you can always go further away, it's the getting closer that is a problem for "visually lossless" statements 🙂
|
|
|
|
OkyDooky
|
2021-01-31 09:43:59
|
Interesting info! Thanks
|
|
|
|
lonjil
|
2021-01-31 09:44:17
|
I've seen a few mentions of the lumen target affecting butteraugli targetting. How does it work, specifically?
|
|
|
|
_wb_
|
2021-01-31 09:47:00
|
I don't know the specifics, but the brighter the display, the more you can see, so it needs to know how many nits peak brightness will be. Can't just assume that a HDR display with 4000 nits behaves the same as an SDR display with 150 nits.
|
|
|
Orum
|
2021-02-01 04:06:44
|
depends a lot on the room you're viewing it in as well
|
|
|
|
BlueSwordM
|
2021-02-01 04:07:24
|
Also, I think someone said here that higher specified luminosity values force the encoder to work with higher bid-depths, yes?
|
|
2021-02-01 04:07:34
|
So it's actually more efficient in some scenarios.
|
|
|
|
lithium
|
2021-02-01 06:35:14
|
Hello, lossy modular -Q 95 -s 9 and modular --near-lossless=max_d, what's the difference?
|
|
|
|
_wb_
|
2021-02-01 06:50:28
|
Not sure if --near-lossless still works
|
|
2021-02-01 06:50:43
|
It's a very different approach
|
|
2021-02-01 06:51:34
|
-Q does Squeeze and then quantizes the residuals of the fine details
|
|
2021-02-01 06:55:07
|
--near-lossless pre-processes the image so pixels get values that cause a predictor to work better
|
|
2021-02-01 06:55:48
|
There's also --lossy-palette --palette=0, which is yet another way to do near lossless
|
|
|
|
lithium
|
2021-02-01 07:12:30
|
--near-lossless = max_d, the max_d quality values is like -q and -Q?
|
|
2021-02-01 07:21:09
|
and --lossy-palette --palette=0, in palette mode, probably have a maxColor values(5000 or 10000),
like if image color below maxColor values can get near lossless quality?
|
|
|
|
_wb_
|
2021-02-01 08:48:12
|
Max_d is supposed to be some small number where smaller means higher quality
|
|
2021-02-01 10:11:40
|
d6 is a bit low quality to my taste, but at least it doesn't get the horrible blocking in the darks like JPEG
|
|
|
|
OkyDooky
|
2021-02-01 10:49:38
|
Hmm, looks like the old JPEG format actually handles the darkhorse logo in the top left better than JPEG XL. JXL blurs the edges and introduces some kinks.
|
|
|
Crixis
|
2021-02-01 10:53:19
|
To me jxl is better than jpg in the logo, I don't see any excessive smoothing, but the small (R) is so bad
|
|
|
|
_wb_
|
2021-02-01 10:58:22
|
the original is a scan, <@!111689857503375360> ?
|
|
2021-02-01 10:59:52
|
original image isn't very clean here, I assume those are mostly artifacts from the printing process
|
|
2021-02-01 11:00:20
|
plus some scanning sensor noise
|
|
2021-02-01 11:00:46
|
maybe also jpeg artifacts
|
|
2021-02-01 11:00:52
|
and then upscaling artifacts
|
|
2021-02-01 11:01:50
|
yes
|
|
2021-02-01 11:02:10
|
not ideal as a starting point
|
|
2021-02-01 11:06:47
|
original was 4:2:0 and quite blocky, it's generally better to start from more pristine sources 🙂
|
|
|
|
Crixis
|
2021-02-01 11:15:41
|
This is a f** good work from Gigapixel, I would resize to original size and encode with jxl, sound as an not "original sensitive" hack but I expect a good result
|
|
|
|
Deleted User
|
2021-02-01 11:46:57
|
`--noise=1` would probably help a bit.
|
|
2021-02-01 11:54:30
|
And have you tried modular lossy encoding?
|
|
2021-02-01 11:55:20
|
Can I see? I'm curious 😉
|
|
|
|
lithium
|
2021-02-01 12:31:24
|
you need -j flag in djxl
|
|
2021-02-01 12:32:07
|
🙂
|
|
|
|
fab
|
2021-02-01 12:34:25
|
--epf=3 --gaborish=1 -q 66.4 -s 7 -j
|
|
2021-02-01 12:34:30
|
same quality as wp2
|
|
2021-02-01 12:34:39
|
or better
|
|
2021-02-01 12:35:20
|
wp2 is maybe only to replace webp
|
|
2021-02-01 12:35:36
|
0.3 libjxl
|
|
|
|
_wb_
|
2021-02-01 12:43:55
|
yes, I agree that default behavior of `djxl` should be to decode losslessly to JPEG if possible, and re-encode the JPEG only if `-j` is used, to make it symmetric with `cjxl`'s `-j`
|
|
|
|
Orum
|
2021-02-01 12:46:24
|
xargs
|
|
|
|
_wb_
|
2021-02-01 12:49:19
|
cjxl and djxl are made only to process one file
|
|
2021-02-01 12:49:36
|
but you can make benchmark_xl do multiple files at the same time
|
|
2021-02-01 12:51:16
|
(benchmark_xl needs to become friendlier...
```$ tools/benchmark_xl --help
benchmark_xl [v0.3.0 | SIMD supported: SSE4,Scalar]
../tools/benchmark/benchmark_file_io.cc:167: JXL_FAILURE: glob failed for
../tools/benchmark/benchmark_xl.cc:958: JXL_CHECK: MatchFiles(Args()->input, &fnames)
Illegal instruction (core dumped)
```)
|
|
2021-02-01 12:52:10
|
how old is that encoder? it's called cjxl for a while now, no?
|
|
|
|
Master Of Zen
|
2021-02-01 12:52:17
|
🚔`Illegal instruction`<:CatBlobPolice:805388337862279198>
|
|
2021-02-01 12:53:13
|
Oof `SIMD supported: SSE4,Scalar]` no avx2?
|
|
|
|
lithium
|
2021-02-01 12:57:14
|
I create a python program to execute many cjxl instance in same time, this method probably have thread safe? or i will get some issue?
|
|
|
|
Scope
|
2021-02-01 12:57:35
|
Btw, wildcards like `*.png` in benchmark_xl are not working under Windows in examples like this:
`benchmark_xl --input "*.png" --codec jxl:wombat:d1,jxl:cheetah:d2`
|
|
|
|
lithium
|
2021-02-01 01:05:12
|
each cjxl.exe have self process, this action probably break encode process?
|
|
|
|
fab
|
2021-02-01 01:09:50
|
it makes the quality more muddy cloudy blurrier, i read in encode.su that avif is useful only for 10-20 kb and gaborish off isn't recommended
|
|
2021-02-01 01:10:01
|
gaborish off is gaborish=1 ?
|
|
2021-02-01 01:10:42
|
also avx2 decoding is faster? like an iphone if it has sse4 (iphone is 12000 old geekbench) how many times it would be slower?
|
|
2021-02-01 01:11:01
|
i read people makes 30 mpx/s for a single core or thread in Vardct
|
|
2021-02-01 01:11:07
|
with djxl.exe
|
|
|
|
veluca
|
2021-02-01 01:11:33
|
30 to 50 is about what I get usually (depends on quality though)
|
|
|
|
fab
|
2021-02-01 01:11:56
|
why i get 1,9 mpx/s with modular?
|
|
|
|
veluca
|
2021-02-01 01:12:02
|
that's with AVX2, SSE4 and NEON are somewhat slower (not 2x slower though) - but it depends on the exact CPU
|
|
|
|
fab
|
2021-02-01 01:12:04
|
single core?
|
|
|
|
veluca
|
2021-02-01 01:12:21
|
modular is slower 🙂 and also not (yet) as efficient as it could be
|
|
2021-02-01 01:12:33
|
most of it is not actually SIMDfied yet
|
|
|
|
fab
|
2021-02-01 01:12:41
|
if a buy a new laptop 14" what it will change
|
|
2021-02-01 01:12:46
|
with amd ryzen
|
|
2021-02-01 01:12:59
|
has it support for laptop cpu?
|
|
2021-02-01 01:13:04
|
or partial?
|
|
|
|
veluca
|
2021-02-01 01:13:12
|
probably not much
|
|
|
|
fab
|
2021-02-01 01:13:17
|
i know is not yet standarzied
|
|
2021-02-01 01:13:35
|
ok thanks
|
|
|
|
veluca
|
2021-02-01 01:14:00
|
amd and intel cpus are relatively similar - phone cpus or apple M1 are another story...
|
|
|
|
fab
|
2021-02-01 01:14:11
|
i know new laptop are even lower consumption
|
|
2021-02-01 01:14:27
|
so i worry about modular not decoding good
|
|
2021-02-01 01:15:09
|
so far i encoded -s 7 -q 88.6 -s 7 -q 88.5 -s 4 -q 99.2 -s 7 -q 66.4 -gaborish=1 --epf=3
|
|
|
|
veluca
|
2021-02-01 01:15:14
|
my guess is that modular is the one that degrades the least with a slower CPU - but we still need quite a few software improvements there to make precise statements about what speed you'd get
|
|
|
|
fab
|
2021-02-01 01:15:22
|
and lossless recompressor and modular with speed 3 the most
|
|
2021-02-01 01:16:13
|
i don't know but i know new laptop are lower consumption so they could be even slower
|
|
2021-02-01 01:16:36
|
amd ryzen for desktop is another story
|
|
2021-02-01 01:17:35
|
not that -d 1 is bad but i encoded mostly screenshots of my phone
|
|
|
|
_wb_
|
2021-02-01 01:29:45
|
hm normally for a big enough image, cjxl should be able to keep your CPU cores busy too. But for encoding, file-level parallelism will be better than single-encode parallelism, since some of the encode steps are not (or cannot be) parallelized.
|
|
|
|
lithium
|
2021-02-01 01:30:17
|
modular is slow, but if create many cjxl instance in same time, that speed is acceptable.
|
|
2021-02-01 01:30:50
|
cjxl
|
|
2021-02-01 01:32:09
|
i using ryzen 1600 6c12t (all core oc 3.65)
|
|
|
|
Crixis
|
2021-02-01 01:34:53
|
Bad multitreading?
|
|
2021-02-01 01:38:02
|
long time to start process the file?
|
|
|
|
_wb_
|
2021-02-01 01:39:56
|
decoding is quite well-parallelized, but encoding still has some things that are sequential
|
|
2021-02-01 01:40:34
|
encoding also inherently is a bit more sequential than decoding, if you want to optimize some stuff globally that's hard to avoid
|
|
|
|
fab
|
2021-02-01 01:42:19
|
for %i in (D:\fidelity*.png) do cjxl "%i" "%i.jxl" -s 7 -q 100 --num_threads=2
there is a \ before *PNG
|
|
2021-02-01 01:42:49
|
orum helped me to do it on 31/12 <@!548366727663321098> if you want you can credit of copy it in some text channel or add in tools
|
|
2021-02-01 01:43:07
|
yes because i flooded last day of year
|
|
|
|
Orum
|
|
fab
orum helped me to do it on 31/12 <@!548366727663321098> if you want you can credit of copy it in some text channel or add in tools
|
|
2021-02-01 01:43:46
|
that still does just one at a time
|
|
|
|
fab
|
2021-02-01 01:44:01
|
yes one core
|
|
|
|
lithium
|
2021-02-01 01:44:11
|
look like create cjxl process action not async?
|
|
|
|
Orum
|
2021-02-01 01:44:13
|
does Windows have an equivalent of xargs?
|
|
|
|
veluca
|
2021-02-01 01:44:43
|
the real question would be if it has an equivalent of `parallel` 😛
|
|
|
|
Orum
|
2021-02-01 01:45:07
|
well I rarely need what parallel provides over xargs
|
|
|
|
veluca
|
2021-02-01 01:45:35
|
I guess that depends on the number of cores one has...
|
|
|
|
Orum
|
2021-02-01 01:46:14
|
anyway, it should do what you want if you can find a Windows version of it <@!111689857503375360>
|
|
|
|
Crixis
|
2021-02-01 01:46:39
|
A official o semi official bulk converter would be very cool (es 4 parallel istances), il possible with bencemark_jxl?
|
|
|
|
fab
|
2021-02-01 01:47:01
|
cmd.exe windows 7
|
|
|
|
lithium
|
2021-02-01 01:47:51
|
Windows bat and Powershell probably can't async create parallel process
|
|
|
|
fab
|
2021-02-01 01:48:10
|
what it change
|
|
2021-02-01 01:48:21
|
to me it looks the same
|
|
|
|
veluca
|
2021-02-01 01:48:26
|
yes: `benchmark_xl --codec jxl:d(something):squirrel--input "path/to/inputs/*.png" --save_compressed --output_dir /path/to/output` should do the trick - not sure if globbing works on windows though
|
|
|
|
Crixis
|
|
lithium
Windows bat and Powershell probably can't async create parallel process
|
|
2021-02-01 01:48:31
|
powershell can https://devblogs.microsoft.com/powershell/powershell-foreach-object-parallel-feature/
|
|
|
|
veluca
|
|
veluca
yes: `benchmark_xl --codec jxl:d(something):squirrel--input "path/to/inputs/*.png" --save_compressed --output_dir /path/to/output` should do the trick - not sure if globbing works on windows though
|
|
2021-02-01 01:49:17
|
(you can pass other options, the name usually matches the name for cjxl but there can be surprises...)
|
|
|
|
lithium
|
|
Crixis
powershell can https://devblogs.microsoft.com/powershell/powershell-foreach-object-parallel-feature/
|
|
2021-02-01 01:50:08
|
thank you, that information very useful:)
|
|
|
|
fab
|
2021-02-01 01:51:14
|
ah to display better in discord
|
|
2021-02-01 01:51:21
|
not to change the command
|
|
2021-02-01 01:51:21
|
ok
|
|
|
|
Crixis
|
2021-02-01 01:52:38
|
ah yes, the impossible to write in italian keyboard caracter
|
|
|
|
_wb_
|
2021-02-01 01:53:38
|
italian keyboards don't have a backtic?
|
|
2021-02-01 01:54:09
|
special purpose à è ù ò keys but no separate `
|
|
2021-02-01 01:54:16
|
ouch
|
|
|
|
Orum
|
2021-02-01 01:54:37
|
every scripter's nightmare
|
|
|
|
Crixis
|
2021-02-01 01:54:38
|
and no tilde
|
|
|
|
_wb_
|
2021-02-01 01:55:15
|
Belgian keyboards are even worse actually
|
|
2021-02-01 01:55:48
|
but I always buy stuff with regular US qwerty keyboards, I hate Belgian keyboards with a passion
|
|
|
|
Crixis
|
2021-02-01 01:56:35
|
i use us keyboad but so many problem whit àèòùì
|
|
|
|
_wb_
|
|
|
Crixis
|
2021-02-01 01:56:54
|
no qwerty, so sad
|
|
|
|
_wb_
|
2021-02-01 01:57:41
|
azerty is very painful, not just because it swaps QW with AZ and M is in a weird spot
|
|
2021-02-01 01:58:02
|
having to use shift for numbers is the most painful part of it
|
|
2021-02-01 01:58:41
|
also all coding symbols are in weird and painful spots
|
|
2021-02-01 01:59:06
|
like () wtf why so far apart
|
|
2021-02-01 01:59:52
|
and [] {} @ behind AltGr, ugh
|
|
|
|
Crixis
|
2021-02-01 02:00:06
|
im only sad for backtik, i use markdown a lot, the rest is ok, your keybord is a nightmare, why è and é so strange position?
|
|
|
_wb_
and [] {} @ behind AltGr, ugh
|
|
2021-02-01 02:00:24
|
this is not a big problem
|
|
|
|
_wb_
|
2021-02-01 02:00:36
|
it's what the French use too
|
|
|
|
Crixis
|
|
_wb_
like () wtf why so far apart
|
|
2021-02-01 02:00:56
|
LOL
|
|
|
Fox Wizard
|
2021-02-01 02:02:19
|
Azerty <:reecat:786377447381532682>
|
|
|
|
Crixis
|
2021-02-01 02:03:01
|
§ only for take space on the keyboard damn
|
|
|
|
veluca
|
2021-02-01 02:27:27
|
italian keyboards also don't have easy [] and {}
|
|
2021-02-01 02:27:33
|
they're pretty bad to program in
|
|
2021-02-01 02:27:50
|
you need AltGr to access [ and AltGr + Shift to get {
|
|
2021-02-01 02:28:13
|
same as Belgian I guess xD
|
|
|
|
Crixis
|
2021-02-01 02:28:26
|
and shift to ;
|
|
|
|
veluca
|
2021-02-01 02:28:39
|
right, I almost forgot about that...
|
|
2021-02-01 02:28:47
|
no easy ~ either
|
|
|
|
Crixis
|
2021-02-01 02:29:57
|
old systems only has alt and number code from numpad for {}, crazy
|
|
|
|
veluca
|
2021-02-01 02:30:00
|
nowadays I use US/UK layouts with the compose key to get all the fancy italian charachers
|
|
|
|
Crixis
|
2021-02-01 02:33:46
|
https://www.amazon.com/Happy-Hacking-Keyboard-Professional2-Keytop/dp/B000F8OECM and GG
|
|
|
|
veluca
|
2021-02-01 02:35:25
|
who looks at the keyboard anyway 😛
|
|
|
|
spider-mario
|
2021-02-01 02:54:54
|
I didn’t realize that Belgium used AZERTY as well
|
|
2021-02-01 02:55:05
|
but I use https://bepo.fr/ myself
|
|
2021-02-01 02:55:27
|
{} [] need Alt Gr too, but at least they are next to each other
|
|
2021-02-01 02:55:42
|
and left hand, which leaves the right hand free for Alt Gr
|
|
|
Nova Aurora
|
2021-02-01 02:58:28
|
I'm lucky to be able to use QWERTY I guess
|
|
|
|
yllan
|
2021-02-01 03:14:34
|
Not recommended
|
|
|
|
bonnibel
|
2021-02-01 03:20:41
|
i have only the proest of gamer keyboards
|
|
|
|
fab
|
|
|
spider-mario
|
|
bonnibel
i have only the proest of gamer keyboards
|
|
2021-02-01 03:41:44
|
I am almost sure that I have seen a keyboard like that in an ASMR video
|
|
|
|
lithium
|
2021-02-01 03:44:10
|
cjxl -m -q 100 -s 9 -g 3 -E 3 -I 1 --palette=0
in some image add --palette=0 will compress smaller,
but some image add --palette=0 will compress bigger than without --palette=0,
I should add --palette=0 flag in lossless compress?
And lossy modular palette, cjxl -m --palette=0 --lossy-palette still have some issue...
|
|
|
|
Fox Wizard
|
2021-02-01 03:45:49
|
At first I thought that keyboard was spilled candy...
|
|
|
|
lithium
|
2021-02-01 03:47:10
|
lossy modular can use --palette=0 flag? ,cjxl -m -Q 95 -s 9 -g 3 -E 3 -I 1 --palette=0
|
|
|
|
bonnibel
|
2021-02-01 03:47:52
|
It's weirdly like a stealth keyboard, I've had multiple people just be in the room (before the pandemic obvs) and just. not realize it was a keyboard until i started typing on it
|
|
|
|
_wb_
|
|
lithium
lossy modular can use --palette=0 flag? ,cjxl -m -Q 95 -s 9 -g 3 -E 3 -I 1 --palette=0
|
|
2021-02-01 04:06:43
|
when doing lossy modular with -Q, it automatically disables palette. Doing lossy on top of palette gives weird results 🙂
|
|
|
|
lithium
|
2021-02-01 04:09:46
|
ok, i think only PixelArt have benefit in cjxl -m -q 100 -s 9 -g 3 -E 3 -I 1 --palette=0
|
|
2021-02-01 04:10:25
|
original
|
|
2021-02-01 04:10:38
|
issue
|
|
2021-02-01 04:11:10
|
in cjxl -m --palette=0 --lossy-palette -s 9 -g 1 -E 3 -I 1
|
|
|
|
_wb_
|
2021-02-01 04:14:02
|
I think --lossy-palette is broken at the moment for images with alpha
|
|
2021-02-01 04:14:35
|
it's a rather experimental encode option, not well tested at all
|
|
|
|
lithium
|
2021-02-01 04:16:26
|
Not recommend use for now?
|
|
|
|
spider-mario
|
2021-02-01 04:17:18
|
not with alpha
|
|
2021-02-01 04:17:20
|
:p
|
|
|
|
lithium
|
2021-02-01 04:18:59
|
ok, i understand, thank you very much 🙂
|
|
|
|
Crixis
|
2021-02-01 04:22:17
|
I wonder how difficult it would be to create an ultra-optimized text-only encoder that uses only pathcs
|
|
2021-02-01 04:29:53
|
Ocr caracter --> Font recognition --> patch encoding --> patch placing
|
|
|
|
_wb_
|
2021-02-01 04:39:00
|
it should be doable, at least for synthetic text like screenshots. Don't necessarily need OCR or font recognition, just a good matching algorithm
|
|
2021-02-01 04:40:23
|
it could also save bits in other things than just text, e.g. encode avatars only once in a screenshot of this chat 🙂
|
|
2021-02-01 04:40:34
|
or this emoji 🙂
|
|
|
|
BlueSwordM
|
2021-02-01 04:43:20
|
Modular would be best for that kind of text image, yes?
|
|
2021-02-01 04:43:27
|
Alongside lossy palette. 🤔
|
|
|
|
_wb_
|
2021-02-01 04:48:31
|
an ideal encoder of a screenshot of my screen right now would encode a sprite sheet with (photographic) avatars with VarDCT, a sprite sheet with letter glyphs and other non-photographic elements like 🙂 with Modular, and then encode everything with Modular, patch-blitting most of the stuff except whatever parts of the UI that are not repetitive.
|
|
|
|
Nova Aurora
|
2021-02-01 04:49:37
|
I apparently don't know enough because 80% of that went over my head
|
|
|
|
BlueSwordM
|
2021-02-01 04:49:58
|
Basically, he's talking about screen content coding recognition.
|
|
2021-02-01 04:50:22
|
IE: By detecting certain image patterns, you change what kind of main algorithm base you use to encode.
|
|
2021-02-01 04:52:21
|
SCCR is a very powerful tool, as mixed content can greatly benefit from this without using different encoding layers.
|
|
|
|
lithium
|
2021-02-01 04:53:09
|
and JBIG2?
|
|
|
|
_wb_
|
2021-02-01 04:53:22
|
JBIG2 is only for 1-bit images
|
|
2021-02-01 04:53:39
|
but it also has something like patches
|
|
2021-02-01 04:54:45
|
(only they messed up some encoder implementations, using avg error metrics instead of max error metrics, which turned 6 into 8 and fun stuff like that)
|
|
2021-02-01 04:55:52
|
the patches mechanism in jxl is more powerful - not only does it work on color images and not just on 1-bit black&white images, it also has different blend modes to do patch blitting with
|
|
2021-02-01 04:56:42
|
a patch is always rectangular, but you don't have to blit with `kReplace`, you can also blit with `kAdd` or `kBlend` blend modes
|
|
|
|
lithium
|
2021-02-01 05:00:13
|
in modular mode -s9 include --patches, --dots?
|
|
|
|
_wb_
|
2021-02-01 05:05:02
|
yes, patches and dots are enabled by default in default speed and slower
|
|
2021-02-01 05:05:26
|
but the detection heuristics can be improved
|
|
2021-02-01 05:07:43
|
but they're not bad
|
|
|
|
Crixis
|
2021-02-01 05:07:57
|
Now use a new or a know matching algorithm?
|
|
|
|
_wb_
|
2021-02-01 05:07:57
|
here is a screenshot of my screen
|
|
2021-02-01 05:08:29
|
this is default cjxl, with only the DC and patches decoded (what you get with `djxl -s 8`)
|
|
|
|
Nova Aurora
|
2021-02-01 05:09:02
|
What's the extension to get tab division like that in chrome?
|
|
|
|
_wb_
|
2021-02-01 05:09:18
|
that is in default chrome
|
|
2021-02-01 05:10:13
|
I need to group my tabs to keep things a bit usable
|
|
2021-02-01 05:10:27
|
but the point is
|
|
2021-02-01 05:10:41
|
it does detect quite a bit of the text and encodes it with patches
|
|
2021-02-01 05:10:48
|
but not everything
|
|
|
|
veluca
|
2021-02-01 05:11:10
|
I'm surprised by how well it works every time I see it 😄 (I wrote most of the detection heuristics)
|
|
|
|
Crixis
|
2021-02-01 05:11:17
|
It don't patch on avatar, why?
|
|
|
|
_wb_
|
2021-02-01 05:11:39
|
probably because the avatars are a bit large
|
|
2021-02-01 05:12:07
|
it does the circles in <@179701849576833024>'s avatar 🙂
|
|
2021-02-01 05:12:19
|
I mean Lee's
|
|
2021-02-01 05:12:24
|
which is the same
|
|
2021-02-01 05:13:00
|
also the favicons in my tabs
|
|
|
|
Crixis
|
|
veluca
I'm surprised by how well it works every time I see it 😄 (I wrote most of the detection heuristics)
|
|
2021-02-01 05:13:18
|
What is the base idea?
|
|
|
|
_wb_
|
2021-02-01 05:14:04
|
and the moon icons in the member list, I wouldn't think it would find those
|
|
|
|
veluca
|
2021-02-01 05:14:41
|
find small things that are on a flat background, cut them out, check if they appear enough many times
|
|
|
|
Crixis
|
2021-02-01 05:15:22
|
Smart the flat bg thing
|
|
|
|
Nova Aurora
|
2021-02-01 05:15:24
|
So that's why the slight change in background color like selected channel destroys the quality of the text?
|
|
|
|
raysar
|
2021-02-01 05:15:51
|
Is there an use case of cjxl.exe do more than 1 thread on cpu? i'm block with 1 thread, even big file, lossy, lossless, 8bit, 16bit.
We need to do parallel powershell script to have a multicore encoding? :/ (i have a 24 threads computer, no avx2 instruction :D)
i have no linux os now to test if multicore works on it.
|
|
|
|
_wb_
|
2021-02-01 05:16:46
|
on linux the auto nb cores detection works fine, I don't know about windows
|
|
2021-02-01 05:17:37
|
it is supposed to work so if it doesn't, open an issue mentioning the build env you used
|
|
2021-02-01 05:17:54
|
these are things that are tricky to do in a portable way
|
|
|
|
raysar
|
2021-02-01 05:19:20
|
yes i ask for windows user, if i'm the only one or not. (even with adding multithread in params)
|
|
|
|
lithium
|
2021-02-01 05:22:56
|
lossy modular cjxl -m -Q 95 -s 9 -g 3 -E 3 -I 1,
probably i missed some flag can optimize file size(not affect quality)?
|
|
|
|
_wb_
|
2021-02-01 05:26:49
|
no, I think you have them all 🙂
|
|
2021-02-01 05:27:14
|
for some images, lossy modular is larger than just going full lossless, so that's always worth checking
|
|
|
|
veluca
|
|
Nova Aurora
So that's why the slight change in background color like selected channel destroys the quality of the text?
|
|
2021-02-01 05:28:30
|
yup... definitely not perfect 😛
|
|
|
|
lithium
|
|
_wb_
no, I think you have them all 🙂
|
|
2021-02-01 05:30:04
|
ok, thank you very much for your help 🙂
|
|
|
|
Deleted User
|
2021-02-01 05:56:48
|
Can patches overlap or aren't they allowed to do that?
|
|
|
|
veluca
|
2021-02-01 05:59:20
|
they can but the encoder doesn't really do that yet
|
|
|
|
Deleted User
|
2021-02-01 06:01:31
|
But the spec allows that, I guess so
|
|
|
|
_wb_
|
2021-02-01 06:09:08
|
Yes, they are just blitted in the order they are signalled
|
|
|
|
fab
|
2021-02-01 07:13:50
|
i encoded screens with -s 4 -q 99.2 without lossy modular.
|
|