JPEG XL

Info

rules 57
github 35276
reddit 647

JPEG XL

tools 4225
website 1655
adoption 20712
nomacs 7
UI 11
chrome 34
image-compression-forum 0

General chat

welcome 3810
introduce-yourself 291
color 1414
photography 3435
other-codecs 23765
on-topic 24923
off-topic 22701

Voice Channels

General 2147

Archived

bot-spam 4380

jxl

Anything JPEG XL related

Scientia
 _wb_ I suppose you could wait for the web tool
2021-04-22 07:20:58
I was talking to him about the new utility
2021-04-22 07:21:07
i think you could compile it with msys2
2021-04-22 07:21:15
if i'm not wrong
2021-04-22 07:22:17
<@!416586441058025472> you can use this to compile windows cli utilities https://www.msys2.org/
2021-04-22 07:22:22
idk about jpeg xl
2021-04-22 07:22:32
but i've compiled quite a few things with this
_wb_
2021-04-22 07:36:23
<@111445179587624960> has made a build, I don't know if it includes the jxl_from_tree tool
Scope
2021-04-22 07:39:16
Yes, but it is for AVX2 CPUs and I think it is better and more convenient to wait for a web version update
spider-mario
 _wb_ If cjxl beeps, something very weird must be happening
2021-04-22 09:57:44
doesn’t printing `"\a"` cause a beep? could we be printing that accidentally?
_wb_
2021-04-22 10:13:42
I guess it does, but how would we print that accidentally?
2021-04-22 10:14:04
Unless you somehow encode to /dev/stdout or something
Pieter
2021-04-22 10:14:29
yeah, i was just about to suggest that
2021-04-22 10:14:44
but does that even work in windows?
Deleted User
2021-04-23 03:24:32
``` --intensity_target=N Intensity target of monitor in nits, higher results in higher quality image. Must be strictly positive. Default is 255 for standard images, 4000 for input images known to to have PQ or HLG transfer function.``` A typo sneaked in `cjxl`, the word "to" is both at the beginning of the last line and at the end of the second-last one.
spider-mario
2021-04-23 03:30:20
the comment is also outdated
2021-04-23 03:30:32
it’s now 10000 for PQ and 1000 for HLG
2021-04-23 03:31:04
and a more accurate description now would likely be “luminance of (1, 1, 1)”
2021-04-23 03:31:21
(like OpenEXR’s `whiteLuminance` tag)
BlueSwordM
2021-04-23 03:56:14
Has anyone tested if HBD encoding for LBD sources improves end user quality?
2021-04-23 03:56:46
Since the CJXL encoder does every calculation at 32-bit floats in lossy mode, I wouldn't expect it, but it's still an interesting though nonetheless.
_wb_
2021-04-23 04:07:19
in VarDCT mode, the bit depth literally does not matter - it is just metadata of the image, a suggestion for the decoder to maybe use that bit depth when converting the decoded image to integers
2021-04-23 04:07:51
(in Modular mode however, it does matter since it defines how to interpret the decoded image)
raysar
 _wb_ in VarDCT mode, the bit depth literally does not matter - it is just metadata of the image, a suggestion for the decoder to maybe use that bit depth when converting the decoded image to integers
2021-04-23 07:13:00
So --override_bitdepth is only for modular picture?
_wb_
2021-04-23 07:37:08
Yes. Well it will change the header field for both, but it will make a difference for the encoded image in modular and not in vardct
Scientia
2021-04-24 07:57:06
> continuation from <#803574970180829194> I don't have a shortage of memory I was just noticing that nomacs was using a significant amount of memory for jxls I compressed with maximum settings, mostly the lossless ones and not the compressed jpeg
2021-04-24 07:57:44
it's fine enough just seemed like quite a bit of memory and I was interested in the tradeoffs a bit
2021-04-24 07:58:23
for write once, read little data it is probably ideal
_wb_
2021-04-24 08:27:20
So far, memory footprint reductions have mostly focused on lossy
2021-04-24 08:27:56
There is still some margin for improvement in lossless memory consumption
Pieter
2021-04-24 02:46:00
what is this supposed to be good for?
Deleted User
 Pieter what is this supposed to be good for?
2021-04-24 03:31:38
Farming XP ;)
_wb_
2021-04-24 05:03:34
https://twitter.com/jonsneyers/status/1385634170957934594?s=19
2021-04-24 05:04:37
Summary of the progress for jxl at the JPEG meeting of the past week. The "(very likely)" can be dropped.
Scope
2021-04-24 05:56:03
What are the differences between the generic and web profiles?
_wb_
2021-04-24 05:57:47
There is only one profile, those two are levels
2021-04-24 05:59:28
Web has more limits than generic
2021-04-24 05:59:56
Not more than 16-bit, dimensions below what fits in 1 GB of memory or so, etc
2021-04-24 06:04:02
Basically the limits you can expect browsers to impose in practice
Pieter
 _wb_ Web has more limits than generic
2021-04-24 06:05:40
as in: the limits for web are higher, or web has more restrictions?
_wb_
2021-04-24 06:05:59
For end-user image delivery, there is no need for very high precision or super huge images. 10 bit is likely enough for the coming years for delivery, 12 bit likely enough for the coming decades
Pieter
2021-04-24 06:06:12
or: which one is a subset of which?
_wb_
2021-04-24 06:06:12
Web has more restrictions than generic
2021-04-24 06:06:20
Web is level 5
2021-04-24 06:06:25
Generic is level 10
2021-04-24 06:06:38
Level X is a subset of level X+1
Pieter
2021-04-24 06:06:43
got it
_wb_
2021-04-24 06:07:20
Also level 5 does not allow CMYK
2021-04-24 06:07:37
Or ICC profiles larger than 4 megabytes
fab
 _wb_ For end-user image delivery, there is no need for very high precision or super huge images. 10 bit is likely enough for the coming years for delivery, 12 bit likely enough for the coming decades
2021-04-24 06:07:51
me that i only have jpeg xl 32 bit
2021-04-24 06:08:00
how i convert to 10 bit
2021-04-24 06:08:45
i shouldn't have converted my images
_wb_
2021-04-24 06:08:50
What cjxl produces by default for png/jpeg/ppm input should be ok for level 5 unless the image is very huge
2021-04-24 06:09:28
Only if you do lossless pfm (32-bit float) or exr as input it will probably not be level 5
fab
2021-04-24 06:09:42
nomacs said that all my jpeg xl images are 32 bit
2021-04-24 06:09:46
i used only png
_wb_
2021-04-24 06:10:08
I don't know who nomacs is but he or she or it is wrong
fab
2021-04-24 06:10:38
nomacs viewer
2021-04-24 06:10:52
i started to convert from 0.2.0
2021-04-24 06:11:04
current commits what bits produces?
_wb_
2021-04-24 06:11:07
The signalled bit depth is what counts, and the header flag that says whether int16 buffers are ok or int32 is needed
2021-04-24 06:11:23
If you take png as input, by default it will copy the bit depth of the png
2021-04-24 06:11:27
Which is probably 8
2021-04-24 06:11:30
Or maybe 16
2021-04-24 06:11:35
In any case not more
fab
2021-04-24 06:12:45
Pieter
2021-04-24 06:12:48
if you start from 16-bit png, and use RCT1, the result doesn't fit in 16-bit buffers i assume?
fab
2021-04-24 06:12:54
xnview and nomacs said 32 bit
Pieter
2021-04-24 06:12:57
(because signs)
fab
2021-04-24 06:13:03
argb
_wb_
2021-04-24 06:13:10
Yes then you need int32
fab
2021-04-24 06:13:17
this is a lossless modular
_wb_
2021-04-24 06:13:39
So in practice you either have to do no RCT (and no Squeeze) or you need int32
fab
2021-04-24 06:14:10
i can send the image
_wb_
2021-04-24 06:14:13
But the web doesn't really need lossless 16-bit anyway
fab
2021-04-24 06:14:21
2021-04-24 06:14:28
what bits is this
2021-04-24 06:14:37
this is new commit
2021-04-24 06:14:59
is this -s 7 -d 1 or lossless
2021-04-24 06:15:06
has it squeeze
2021-04-24 06:15:17
vardct or lossless
_wb_
2021-04-24 06:20:05
jxl_info will tell you that
2021-04-24 06:22:41
``` jxlinfo 00Cattura.PNG.jxl xsize: 428 ysize: 262 have_container: 0 uses_original_profile: 1 bits_per_sample: 8 exponent_bits_per_sample: 0 intensity_target: 255.000000 min_nits: 0.000000 relative_to_max_display: 0 linear_below: 0.000000 have_preview: 0 have_animation: 0 orientation: 1 num_extra_channels: 1 alpha_bits: 8 alpha_exponent_bits: 0 alpha_premultiplied: 0 extra channel: 0 info: type: 0 bits_per_sample: 8 exponent_bits_per_sample: 0 dim_shift: 0 name_length: 0 alpha_associated: 0 spot_color: 0.000000 0.000000 0.000000 0.000000 cfa_channel: 1 color profile: format: JPEG XL encoded color profile color_space: 0 white_point: 1 white_point XY: 0.312700 0.329000 primaries: 1 red primaries XY: 0.639999 0.330010 green primaries XY: 0.300004 0.600003 blue primaries XY: 0.150002 0.059997 transfer_function: 13 rendering_intent: 0 ```
fab
2021-04-24 06:23:00
_wb_
2021-04-24 06:23:05
So 8-bit, both for the RGB and for the alpha
fab
2021-04-24 06:23:44
jpg to png xnview to jxl how get encoded
2021-04-24 06:23:49
is there a rule
2021-04-24 06:24:11
also is there some probability i have 32 bit files with the old encoders
2021-04-24 06:24:15
from 0.2 and up
_wb_
2021-04-24 06:24:36
Not if you used PNG input or JPEG input
fab
2021-04-24 06:24:55
so no even with older encoders
2021-04-24 06:24:58
image will work in browser
2021-04-24 06:25:05
chrome firefox and android
2021-04-24 06:25:06
and all
_wb_
2021-04-24 06:25:07
Only with PFM or EXR input (maybe PSD too) is more than 16 bit even an option
fab
2021-04-24 06:25:10
and also ios and mac
_wb_
2021-04-24 06:25:28
Unless you manually did --override_bitdepth=20 or something like that
fab
2021-04-24 06:25:39
ok
2021-04-24 06:26:02
before jxl how people encoded 32 bit
Pieter
2021-04-24 06:28:11
<@416586441058025472> What your software reports as 32 bits is just 8 bit depth (but 4 channels of it)
_wb_
2021-04-24 06:32:29
Ah yes. That is a confusing habit of image software, to call both 8-bit RGBA and very high precision (e.g. PFM) single channel "32-bit"
2021-04-24 06:33:50
JPEG XL can go up to 131168-bit, if you count it like that
Crixis
2021-04-24 06:34:50
For blender a normal channell will be so cool for texures
_wb_
2021-04-24 06:34:56
Level 5 is limited to 112-bit (at most 7 channels of 16-bit each)
2021-04-24 06:35:54
Level 10 is limited to 8288-bit (at most 3+256 channels of 32-bit each)
2021-04-24 06:36:25
Beyond level 10 you can in principle signal 3+4096 channels of up to 64-bit each
2021-04-24 06:37:08
So I was wrong, the bitstream limit is 262336-bit, not half that
Pieter
2021-04-24 06:37:21
does the software have separate instanciations using 16-bit, 32-bit, and 64-bit channel value representations?
_wb_
2021-04-24 06:37:46
But the reference implementation only supports integer up to 24-bit and float up to 32-bit atm
2021-04-24 06:38:00
No, atm we do everything with float and int32
Pieter
2021-04-24 06:38:35
ah, but it's expected to have an optimization that only uses int16 when that's sufficient?
_wb_
2021-04-24 06:38:39
Yes
Pieter
2021-04-24 06:38:42
as the header signals that
_wb_
2021-04-24 06:38:50
Exactly
Pieter
 _wb_ So I was wrong, the bitstream limit is 262336-bit, not half that
2021-04-24 06:39:07
Cool, so one JXL pixel can contain more information than a tweet.
_wb_
2021-04-24 06:39:34
Very powerful pixel
Pieter
2021-04-24 06:39:52
unless of course the tweet contains an image...
_wb_
2021-04-24 06:39:57
Haha yes
2021-04-24 06:40:35
Twitter recompressing my jxl art to ugly big jpegs is interesting to see
190n
2021-04-24 06:40:49
a single jxl pixel could contain most of wb's jxl art :D
_wb_
2021-04-24 06:41:32
You can also have a jxl image that is a gigapixel and only 1 pixel high or wide
2021-04-24 06:43:04
Or a gigapixel wide and high, which would be an exapixel image
2021-04-24 06:44:28
Terapixel and petapixel is probably already too big to handle in practice though
Some1NamedNate
2021-04-25 03:02:29
I got a visual on `#enable-jxl` in Chrome Canary 92.0.4487.0
2021-04-25 03:03:15
Simply enabling it and drag-and-dropping a .jxl image in it and it works as intended!
Orum
2021-04-25 07:31:31
anyone else noticing color shifts at `-d 1`? Seems to be away from green/blue and toward red/magenta
monad
2021-04-25 07:40:51
You're sure it's not the viewer?
Jake
2021-04-25 07:41:10
Hey, I'm new on jxl.
Orum
2021-04-25 07:41:20
I thought that might be the case, but I've checked in nomacs and firefox, and both seem to exhibit the issue
2021-04-25 07:41:43
it's subtle, but still noticeable
monad
2021-04-25 07:42:35
Jon's mentioned before that Firefox has poor color management.
Orum
2021-04-25 07:42:51
well if there's another viewer I should try I'm all ears
2021-04-25 07:43:30
it's the same (i.e. the color shift is still visible) in GIMP too
monad
2021-04-25 07:43:41
Mm, GIMP should be good.
_wb_
2021-04-25 07:44:40
What is the original image?
Orum
2021-04-25 07:44:58
_wb_
2021-04-25 07:46:33
That's a PNG without a color profile
2021-04-25 07:46:41
I mean without an ICC profile
2021-04-25 07:46:48
It does have the sRGB chunk
Orum
2021-04-25 07:47:33
ah, does it guess at the profile and then get it wrong or something?
_wb_
2021-04-25 07:47:34
It is likely that many software renders it wrong on a non-sRGB screen
Orum
2021-04-25 07:47:57
well, my display is sRGB
_wb_
2021-04-25 07:47:57
I _think_ cjxl/djxl are doing the correct thing
2021-04-25 07:48:17
But lots of other software gets it wrong
Orum
2021-04-25 07:48:25
ah, okay
2021-04-25 07:48:52
so if I embed an ICC profile it should look correct?
_wb_
2021-04-25 07:49:36
Yes, well there is also software that ignores icc profiles but then it is more clear that they have a problem
2021-04-25 07:50:05
In PNG you have the gamma chunk, the sRGB chunk, and you can have icc profiles
2021-04-25 07:51:23
And without an icc profile a lot of software (including e.g. firefox) does not do the right thing
Orum
2021-04-25 07:51:42
what viewer is the best to ensure things are actually rendering correctly?
_wb_
2021-04-25 07:52:04
Desktop chrome gets it right iirc
2021-04-25 07:52:20
(mobile chrome not fully iirc)
Pieter
2021-04-25 07:52:50
_without_ an ICC profile firefox does it wrong? so with an icc profile it does do it right?
_wb_
2021-04-25 07:52:56
Yes
Pieter
2021-04-25 07:53:10
so it's just not assigning the right profile by default?
_wb_
2021-04-25 07:53:23
Firefox just transfers pixels to the screen if there is no icc profile
2021-04-25 07:53:26
By default
Pieter
2021-04-25 07:53:31
i see
2021-04-25 07:53:41
it uses "native" as default profile 😄
_wb_
2021-04-25 07:53:52
(there is a flag to make it do the right thing, but that's not enabled by default)
2021-04-25 07:54:43
Yes, that is an easy default to implement :) but not a very good one if you want images to look the same regardless of display space
Orum
2021-04-25 07:55:38
what's the flag?
Pieter
2021-04-25 07:55:42
ok, changed mine
_wb_
2021-04-25 07:55:46
The same pixel data will look more saturated on a P3 display than on an sRGB display, for example
Pieter
2021-04-25 07:55:50
gfx.color_management.mode
2021-04-25 07:56:00
needs to be "1" for it to be always on
_wb_
2021-04-25 07:56:20
And then people complain to us that the image looks desaturated after we process it
2021-04-25 07:56:46
While they were seeing an incorrectly oversaturated original image
Orum
2021-04-25 07:56:51
hrm, even with the flag changed, it looks the same
fab
2021-04-25 07:57:07
no now with new encoder image looks right
_wb_
2021-04-25 07:57:15
That flag only helps for icc profiles iirc
fab
2021-04-25 07:57:19
but with the commits before i saw something
Orum
2021-04-25 07:57:27
ah okay
fab
2021-04-25 07:57:31
it was for the patches
_wb_
2021-04-25 07:57:49
I mean
2021-04-25 07:58:07
That flag only helps for images without any color space info
2021-04-25 07:58:14
Like untagged jpegs or pngs
2021-04-25 07:58:39
In this case you have a png with a gamma chunk and an srgb chunk
2021-04-25 07:58:58
IIRC the sRGB chunk takes precedence over the gamma chunk
Orum
2021-04-25 07:59:30
Okay, I saved the gamma and the color profile into it, and I still am seeing a shift <:SadOrange:806131742636507177>
_wb_
2021-04-25 07:59:47
Interesting
Orum
2021-04-25 07:59:59
maybe my eyes are just more sensitive to it
_wb_
2021-04-25 08:00:26
What happens if you do d0.1 ?
Orum
2021-04-25 08:01:04
Then things look fine
_wb_
2021-04-25 08:01:07
Or something like -m -Q 99.9 -c 1
2021-04-25 08:01:11
Ah ok
2021-04-25 08:01:20
Then it is just lossy being lossy
2021-04-25 08:01:26
Not a colorspace issue
Orum
2021-04-25 08:01:40
Ah okay, so I guess I should just expect that even at -d 1
Scientia
2021-04-25 08:01:51
I think it depends on the image
_wb_
2021-04-25 08:02:10
I mean, d 1 is supposed to be at most just barely noticeable
Scientia
2021-04-25 08:02:20
There's probably no way to have every lossy image at the same quality unnoticed by everyone
_wb_
2021-04-25 08:02:29
The 1 means "one unit of just-barely-noticeable difference"
Scientia
2021-04-25 08:02:38
There's always problem cases in these things afaik
_wb_
2021-04-25 08:02:45
At least that is the goal
2021-04-25 08:02:55
Of course some people have better vision than others
2021-04-25 08:03:17
And it also depends a lot on the viewing distance. We assume 1000 pixels viewing distance.
2021-04-25 08:03:24
(or more, obviously)
Orum
2021-04-25 08:03:38
yeah, it's subtle, but it's more noticeable without zooming in compared to detail-related changes, because the color shift is over a wide area
_wb_
2021-04-25 08:04:02
It's probably DC quantization I guess
Scientia
2021-04-25 08:04:15
Is it noticeable when you look at one image then look at the other, but not side by side?
Orum
2021-04-25 08:04:37
I'll have to look at them side-by-side, I've been doing flip tests so far
_wb_
2021-04-25 08:04:56
You can try if -p makes it better (uses modular with squeeze for DC instead of the normal cleverly quantized non-squeezed modular)
2021-04-25 08:05:15
We test with flip tests, it is more sensitive
2021-04-25 08:05:46
Side-by-side d1 should be visually lossless nearly always
monad
2021-04-25 08:06:31
still assuming you don't zoom in
_wb_
2021-04-25 08:06:47
Yes, at a viewing distance of 1000 pixels
2021-04-25 08:07:08
If you make your pixels 1cm large, that is 10 meters 😅
Orum
2021-04-25 08:09:13
actually I think the color shift is even more noticeable in side-by-side vs flip
2021-04-25 08:10:21
hard to tell if it's an artifact of the display though
Jake
2021-04-25 08:10:53
Color shift?
Orum
2021-04-25 08:11:32
yeah, just a minor shift due to lossy encoding
_wb_
2021-04-25 08:11:42
More noticeable I doubt (if the flipping is instant), but very low freq issues like color shifts can be more easily visible in side by side than more local issues
Jake
2021-04-25 08:11:45
Well, that's going to keep me up at night.
2021-04-25 08:12:03
Lossy formats support ICC profiles, right?
_wb_
2021-04-25 08:12:11
Yes
Jake
2021-04-25 08:12:17
I haven't actually used JPEG for awhile.
_wb_
2021-04-25 08:12:33
Anything except GIF supports icc profiles
2021-04-25 08:13:12
Anything compressed I mean
Jake
2021-04-25 08:14:42
Well, I suppose I'll get started with some test encodes.
2021-04-25 08:15:54
Sigh. I'm on windows.
_wb_
2021-04-25 08:15:58
<@548366727663321098> does encoding with `-p` make it better, worse, or same?
Orum
2021-04-25 08:16:09
uhh, let me test
Jake
2021-04-25 08:16:27
Anyone have any compiled executables or know a server hosting any?
Orum
2021-04-25 08:17:29
`-p` looks about the same (meaning still a slight shift)
2021-04-25 08:19:52
oh, that's interesting... `-m -d 1` has no shift though <:WhatThe:806133036059197491>
_wb_
 Jake Anyone have any compiled executables or know a server hosting any?
2021-04-25 08:20:57
https://encode.su/threads/3564-JXL-version-0-3-released?p=69454&viewfull=1#post69454
Orum oh, that's interesting... `-m -d 1` has no shift though <:WhatThe:806133036059197491>
2021-04-25 08:21:35
Different method gives different result
Orum
2021-04-25 08:22:06
Yeah, it's weird though. It looks almost (if not) lossless
2021-04-25 08:22:17
maybe I'll up the distance
Jake
2021-04-25 08:22:27
Yeah. I can probably figure out how to compile it.
2021-04-25 08:22:31
Oh, they have a guide.
monad
2021-04-25 08:22:37
-m would make it lossless
Jake
2021-04-25 08:22:45
Sorry, I'm just a little out of it.
Orum
2021-04-25 08:22:48
oh, I thought there was a lossy modular?
monad
2021-04-25 08:23:03
you'd need -Q or -q for lossy modular
Orum
2021-04-25 08:23:07
ah
Scope
2021-04-25 08:24:38
Also <https://encode.su/threads/3401-JPEG-XL-status-update-and-key-distinguishing-features?p=66779&viewfull=1#post66779> (but encode.su seems to be overloaded, it's one of my old posts) <https://slow.pics/c/0nQeUsBl>
2021-04-25 08:26:27
Jake
2021-04-25 08:26:38
Hmm
2021-04-25 08:26:52
How close are you looking at these images in comparison to the original?
_wb_
2021-04-25 08:31:39
We are talking about a pretty subtle difference
2021-04-25 08:33:23
The kind of thing that likely would be solved by very slightly bumping up the precision in the DC of one of the chroma channels in the encoder.
Orum
2021-04-25 08:44:56
I take it there's no option to do that right now
_wb_
2021-04-25 08:48:13
I don't think there is (besides globally setting a lower distance target)
Pieter
2021-04-25 08:57:42
perhaps a separate max distance for DC makes sense as slightly advanced option?
Crixis
2021-04-25 09:02:53
<@532010383041363969> was tweaking red distance if I'm right
fab
2021-04-25 09:41:23
2021-04-25 09:41:49
i upped the bitrate more
2021-04-25 09:41:53
-q 90.33 --noise=0 --gaborish=1 --epf=3 --dots=0 --patches=1 -s 8
2021-04-25 09:41:59
epf 3 is too strong
2021-04-25 09:42:10
but i don't notice at this bitrate with current encoder
2021-04-25 09:42:18
obviously new encoder will improve
_wb_
2021-04-25 09:42:49
We did have adjustable multipliers for X and B at some point as a cjxl flag iirc, dunno if that's still there. But the goal is to just get the defaults right, 99.99% of users are not going to manually tune detailed flags like that
2021-04-25 09:44:03
(the 0.01% being Fabian)
Pieter
2021-04-25 09:46:02
there are 9999 other users? :o
_wb_
2021-04-25 09:50:48
Not yet but I can dream, right?
2021-04-25 09:51:45
(dream being that eventually there will be ~8 billion users)
Jyrki Alakuijala
2021-04-25 09:52:25
I have submitted an improvement to red-green distance that takes larger deviations stronger into account
2021-04-25 09:53:23
It was too much risk for Luca and he needed a release for other needs -- so we post-poned that into the next release
2021-04-25 09:53:35
basically small changes in red-green are punished a bit less
2021-04-25 09:53:46
but larger changes are punished more
2021-04-25 09:53:52
... or it is more complicated than that
_wb_
2021-04-25 09:54:03
That's in the AC heuristics, right?
Jyrki Alakuijala
2021-04-25 09:54:22
changes in large absolute values of X in AC are punished more
_wb_
2021-04-25 09:54:31
Subtle global color shift is likely a DC issue
Jyrki Alakuijala
2021-04-25 09:54:34
changes in small absolute values of X in AC are punished more
2021-04-25 09:54:52
this is a butteraugli change, but it is coming in the next release
_wb_
2021-04-25 09:55:05
Affects speed 8,9 only then?
Jyrki Alakuijala
2021-04-25 09:55:31
I have looked at Scope's example and it was a problem when posted on encode.su
2021-04-25 09:55:54
I have reworked the related heuristics about half a year ago, but I don't know if it got worse or better
_wb_ Affects speed 8,9 only then?
2021-04-25 09:56:27
yes, it will only affect those speeds that iterate with butteraugli
2021-04-25 10:00:28
when every second pixel is black vs. white and the codec decides to not to store chromacity at high frequencies, the chromacity is brought back into the white and black pixels. However, chromacity of black pixels doesn't actually contribute to the image -- they are just black. This causes some reduction of chromacity that we might be able to detect iteratively at encoding time by changing the DC chromacity levels iteratively so that they take into account the chromacity reduction.
2021-04-25 10:00:52
since this is a subtlety and a big fix is complicated -- it is very likely best to post-pone experimentation with this idea
fab
2021-04-25 11:35:33
2021-04-25 11:35:44
those are actually the (random) settings i used in real scenarios
2021-04-25 11:35:51
to re encode jpg
2021-04-25 11:35:55
but they didn't bring gain
2021-04-25 11:36:04
but d 1 s 7 for png galaxy s4 screenshots
2021-04-25 11:36:11
it brought large gain
2021-04-25 11:37:27
i would avoid modular as normal user will user lossless jpg transcode or vardct lossy to compress anime or ex
2021-04-25 11:37:43
they won't install 0.3.7 ab7c5e9b modular
Scientia
2021-04-25 11:38:12
Why turn off patches?
fab
2021-04-25 11:38:17
q 90.33 is high
2021-04-25 11:38:33
i doubt i can see difference with graphic or worse with jpg (or if i see i see only with this commit and very small difference)
2021-04-25 11:38:48
i would use lossless jpg transcode or d 1 s 7
2021-04-25 11:39:29
also comparing s 8 to s7 isn't good
Scientia Why turn off patches?
2021-04-25 11:40:13
is not turned off
Scientia
2021-04-25 11:40:37
Wouldn't patches=0 turn off patches?
fab
2021-04-25 11:40:39
is just less brightness to hide saturation maybe
2021-04-25 11:40:50
i don't actually do what it does
2021-04-25 11:41:03
anyway i don't know the file sizes
Scientia
2021-04-25 11:41:17
Why use it if you don't know what it does <:monkaMega:809252622900789269>
fab
2021-04-25 11:41:23
71 kb i got
2021-04-25 11:41:25
average
2021-04-25 11:41:33
from 410 kb jpeg
2021-04-25 11:42:54
wait i find the folder
2021-04-25 11:46:22
69,3 kb medium
2021-04-25 11:46:28
1280x720
2021-04-25 11:48:14
i captured one of the worse quality
2021-04-25 11:48:15
2021-04-25 11:48:33
74,34 kb
2021-04-25 11:48:48
most of their screenshots are already in 70 kb range
2021-04-25 11:48:57
so i compress the one that weight more
2021-04-25 11:49:28
parameters are
2021-04-25 11:49:38
for %i in (C:\Users\User\Documents\s4\*.png) do cjxl "%i" "%i.jxl" -q 87.1 --gaborish=1 --patches=0 --intensity_target=219 --dots=1 --epf=2 -s 9 --num_threads=2
2021-04-25 11:49:42
if you are interested
2021-04-25 11:49:47
sorry for offtopic
2021-04-25 11:49:54
and randomness
Scientia
 Scientia Why use it if you don't know what it does <:monkaMega:809252622900789269>
2021-04-25 11:50:09
Also speaking of things that I don't know what they do, what is the gaborish filter?
veluca
2021-04-25 11:50:27
just a 3x3 symmetric convolution that is applied post-IDCT 🙂
Deleted User
2021-04-25 11:51:12
In more... humane terms?
veluca
2021-04-25 11:52:16
(I don't think "humane" is the word you really want to use here 🤣)
Scientia
2021-04-25 11:52:40
I need to learn more about DCT and the stuff that makes compression work
veluca
2021-04-25 11:52:54
at some point, you replace each pixel with a * pixel + b * pixels_at_distance_1 + c * pixels_at_distance_2
Scientia
2021-04-25 11:53:21
It's complex but it should be rewarding to learn with it's wide application
veluca
2021-04-25 11:53:24
("distance" here is taxicab distance, https://en.wikipedia.org/wiki/Taxicab_geometry)
Deleted User
 veluca (I don't think "humane" is the word you really want to use here 🤣)
2021-04-25 11:54:50
An average human barely understands advanced maths 😉 Unfortunately that's the case for me too despite being an IT student...
veluca
 fab
2021-04-25 11:54:52
(tgcom? really? 😛 my first parsing of that sentence went rather wrong btw xD)
fab
2021-04-25 11:55:21
51 channel
2021-04-25 11:55:25
anyway offtopic
2021-04-25 11:55:32
i'm not good at creating script
2021-04-25 11:55:40
i do not know how to do
Scientia
 An average human barely understands advanced maths 😉 Unfortunately that's the case for me too despite being an IT student...
2021-04-25 11:55:45
DCT is a lot of advanced math <:FeelsReadingMan:808827102278451241>
veluca
 An average human barely understands advanced maths 😉 Unfortunately that's the case for me too despite being an IT student...
2021-04-25 11:55:50
IIRC humane means ~ "not torture" or things like that, I might be wrong though 😛
fab
2021-04-25 11:56:05
if you want to use modular lossy to compress anime or e x
2021-04-25 11:56:10
you can do better than me
2021-04-25 11:56:25
because you can train a script to delete more than 25% 30%
veluca
2021-04-25 11:56:26
having or showing compassion or benevolence. "regulations ensuring the humane treatment of animals"
fab
2021-04-25 11:56:30
and i do not know how to do
2021-04-25 11:57:07
without a gui i can't do anything
Scientia
2021-04-25 11:57:18
does lossy modular actually do better than dct on content with low noise and defined lines like cartoons/anime?
Deleted User
 veluca having or showing compassion or benevolence. "regulations ensuring the humane treatment of animals"
2021-04-25 11:57:20
> "regulations ensuring the humane treatment of animals" and not exposing them to advanced mathematics
veluca
2021-04-25 11:57:32
😛
Scientia
2021-04-25 11:58:44
when dealing with compression advanced mathematics is something often encountered. I barely know about that kind of thing either, I'm working on it.
veluca
2021-04-25 11:58:52
one way to think about DCT is that you can write any set of 8x8 values as a sum of these (with multipliers): https://upload.wikimedia.org/wikipedia/commons/2/24/DCT-8x8.png
fab
2021-04-25 11:58:54
2021-04-25 11:58:59
pinwheel i refer to that
Deleted User
 Scientia DCT is a lot of advanced math <:FeelsReadingMan:808827102278451241>
2021-04-25 11:59:08
I know ;_; The tragic paradox: I'd love to dedicate my life to DSP, including codecs, but I wholeheartedly hate maths necessary to understand it <:FeelsSadMan:808221433243107338>
fab
2021-04-25 11:59:13
like q 90.33 helps to have less of those artifacts with more epf
2021-04-25 11:59:18
with new encoder
2021-04-25 11:59:28
but modular d 1 s7 is good
Deleted User
 veluca one way to think about DCT is that you can write any set of 8x8 values as a sum of these (with multipliers): https://upload.wikimedia.org/wikipedia/commons/2/24/DCT-8x8.png
2021-04-25 11:59:50
I roughly know that DCT works that way, but I couldn't be able to recreate it from scratch
fab
2021-04-25 11:59:58
this is made because the ar field was increased
2021-04-25 12:00:02
something likethat
2021-04-25 12:00:07
but i don't know science
2021-04-25 12:00:38
but i guess lossy will always cause those artifacts
Deleted User
 I roughly know that DCT works that way, but I couldn't be able to recreate it from scratch
2021-04-25 12:00:49
And if you start treating me with words like "calculus" or "imaginary numbers", I'll panic
veluca
2021-04-25 12:00:51
ah, there's a few tricks to figuring out how to *get* a DCT
fab
2021-04-25 12:00:54
is due to the patches
veluca
2021-04-25 12:01:08
(or fourier transform, which is kinda the same)
2021-04-25 12:02:37
if you ask a phisicist, they'll tell you that it's all about getting a translation-invariant set of basis vectors
Deleted User
 veluca (or fourier transform, which is kinda the same)
2021-04-25 12:02:53
Roughly know about that one, too. But exact details? I wish I could understand them, but I'm too stupid for that ;_;
Scientia
2021-04-25 12:03:00
Wish discord would finally implement their threads feature
Deleted User
 Scientia Wish discord would finally implement their threads feature
2021-04-25 12:03:38
There is a service with nearly infinite threads and it's called Disqus
veluca
2021-04-25 12:04:11
anyway, from my point of view it's a lot more advanced engineering than advanced maths... but that might be a side effect of having a maths' degree 😛
diskorduser
 Scientia does lossy modular actually do better than dct on content with low noise and defined lines like cartoons/anime?
2021-04-25 12:46:38
I don't think so. Avif works well on line art.
2021-04-25 12:46:52
Like anime drawings and cartoons
Scientia
2021-04-25 12:47:50
Fabian seems to think it does, I was just wondering if he was right or not
diskorduser
2021-04-25 12:48:59
In my experience jxl works well for real life photos and avif works well for graphic content.
Scientia
2021-04-25 12:49:55
vardct at least
2021-04-25 12:50:13
it could be possible lossy modular would work better on graphic content
2021-04-25 12:50:20
Haven't tested such a thing
2021-04-25 12:50:40
I do know that lossless modular is great for graphic content
diskorduser
 Scientia I do know that lossless modular is great for graphic content
2021-04-25 12:51:22
Lossless mode works well for any image but it doesn't matter . Because it's lossless
Scientia
2021-04-25 12:51:34
Fair enough
2021-04-25 12:52:09
Actually no
2021-04-25 12:52:37
Modular does **worse** at graphical content than photographic content
2021-04-25 12:52:47
Compression wise
2021-04-25 12:53:25
I was confused
2021-04-25 12:53:30
I though it did better
fab
2021-04-25 02:16:19
https://www.reddit.com/r/jxlArt/comments/my94g3/jpeg_xl_art_in_exactly_2_hours/
Crixis
2021-04-25 03:09:46
modular is good at anime content but in d 1 / d 3 target to my experience vardct is always better
fab
2021-04-25 03:24:08
i encoded real person
2021-04-25 03:24:21
not japanese cartoon person
2021-04-25 03:24:36
but i don't know if it could work the same
2021-04-25 03:24:51
guess is not worth experimenting
Crixis
2021-04-25 03:25:22
on real foto modular lossy is garbage
fab
2021-04-25 03:25:29
unless you have 0.3.7 this commit, the command i posted on my guide, and a script that said i delete a jpg if is 30% bigger
2021-04-25 03:26:25
not worth going into your p/hoto archive to test every photo at once
2021-04-25 03:27:29
but i have not zoomed these photos
2021-04-26 12:47:24
2021-04-26 12:47:25
2021-04-26 12:47:33
https://it.wikipedia.org/wiki/JPEG_XL
2021-04-26 12:47:37
https://es.wikipedia.org/wiki/JPEG_XL
2021-04-26 12:48:25
do you see any errors in the title of iso
_wb_
2021-04-26 12:51:21
No
2021-04-26 12:51:49
things could be updated though, part 2 is going to FDIS, part 4 to DIS stage
2021-04-26 12:52:31
(then again, officially part 1 and 2 are still DIS since the FDIS isn't approved yet by the national bodies of ISO, and part 4 was only just approved as CD)
2021-04-26 12:53:18
so it depends on whether you want to put the "approved by JPEG" status or the "approved by ISO and all its members" status — there is about 6 months difference between those two things
fab
2021-04-26 01:02:53
until iso finishes the cyle
2021-04-26 01:08:38
crixis maybe can fix the orphan it jpeg xl page
Petr
 fab crixis maybe can fix the orphan it jpeg xl page
2021-04-26 01:32:44
done 🙂
fab
 Petr done 🙂
2021-04-26 01:38:12
what you did
2021-04-26 01:38:46
Petr
2021-04-26 01:38:54
https://it.wikipedia.org/wiki/Speciale:Contributi/Avayak
fab
2021-04-26 01:38:55
it said link are random
2021-04-26 01:39:59
https://it.wikipedia.org/w/index.php?title=JPEG_XL&action=history
2021-04-26 01:40:02
see here link don't work
2021-04-26 01:40:18
and latest commit is mine
2021-04-26 01:40:48
ah you added .jxl .jxl as jpeg xl
Petr
2021-04-26 01:40:55
What links there: https://it.wikipedia.org/wiki/Speciale:PuntanoQui/JPEG_XL
fab
2021-04-26 01:41:39
so now when they will remove oprhan data
2021-04-26 01:41:54
orphan data means what are linked there
2021-04-26 01:42:05
in a wiki
2021-04-26 01:42:25
wikipedia itself with some admin will do
2021-04-26 01:42:30
for the it project
2021-04-26 01:42:45
i hope they will not take time
2021-04-26 01:43:31
for espanol there is a lot to fix
2021-04-26 01:43:50
first formato abierto need to be Si
2021-04-26 01:44:06
so with a yes symbol
2021-04-26 01:44:21
then add the name of the standard in the table ISO OEC
Petr
2021-04-26 01:44:27
Before removing the orphan template, some Italian speaker could also add "normal" links to JPEG XL into relevant articles, e.g. https://it.wikipedia.org/wiki/Compressione_dell%27immagine
fab
2021-04-26 01:44:47
so we need to wait
2021-04-26 01:44:56
ok can you do something for es article
2021-04-26 01:45:40
also how to see what jpeg xl in es project is linked?
Petr What links there: https://it.wikipedia.org/wiki/Speciale:PuntanoQui/JPEG_XL
2021-04-26 01:46:04
this in spanish
2021-04-26 01:46:55
ah i saw on the left
2021-04-26 01:47:50
2021-04-26 01:48:21
first formato abierto need to be Si so with a yes symbol then add the name of the standard in the table ISO OEC
2021-04-26 01:48:51
fix the bugged table if you have time
2021-04-26 01:49:07
or you know spanish
2021-04-26 01:50:06
https://es.wikipedia.org/wiki/JPEG_XL <@!792428046497611796>
2021-04-26 01:50:34
or wait until it becomes popular and some spanish fix
2021-04-26 01:50:59
at least the standard table is translated
Petr
 fab or you know spanish
2021-04-26 01:51:10
I know it but I don't speak it. 😉 So I can do almost nothing for that article.
fab
2021-04-26 02:28:34
https://it.wikipedia.org/wiki/JPEG_XL
2021-04-26 08:29:59
2021-04-26 08:30:11
what are these in english
2021-04-26 08:30:15
post
Pieter
2021-04-26 09:29:34
what is gaborish?
Scientia
 veluca just a 3x3 symmetric convolution that is applied post-IDCT 🙂
2021-04-26 09:36:56
This is the explanation
2021-04-26 09:37:12
Hope you can understand it better than I can <:HaDog:805390049033191445>
Pieter
2021-04-26 09:42:15
oh so a very simple blurring filter for example could be done that way?
2021-04-26 09:42:27
post-IDCT, so on the decoded pixel data
Scientia
2021-04-26 09:43:37
I know it was referenced as a way to add blur in <#824000991891554375>
2021-04-26 09:44:23
https://discord.com/channels/794206087879852103/824000991891554375/836319525976670280
_wb_
2021-04-27 05:21:47
The encoder does a slight sharpening pre-encode and the decoder does a slight blurring post-decode. It's a way to avoid some block artifacts.
2021-04-27 05:23:23
But the weights can be signalled, so in principle you could signal different weights and get post-decode sharpening or blurring for free (not having to change anything except the header)
2021-04-27 05:25:19
With the limitation that it's only a 3x3 convolution decode-side, so cannot do big blurs or sharpenings that way. But mild ones should be doable.
2021-04-27 05:26:27
It happens in the XYB space and the edge-preserving filter is applied afterwards
Orum
2021-04-27 03:27:36
Any chance we can get a little more modern argument parsing, like bundling arguments? Would be nice to be able to do `cjxl -hv` instead of `cjxl -h -v`
_wb_
2021-04-27 03:40:33
that would indeed be useful - could you open a gitlab issue for it? shouldn't be hard to do but it's easy to forget about it 🙂
2021-04-27 03:40:46
(also if there are other things besides bundling args)
Orum
2021-04-27 03:59:27
will do, if there isn't one already
2021-04-27 04:18:18
GitLab seems to have blocked my old account and a new one I just created.
Deleted User
2021-04-28 01:29:10
I've just found this 2010 comparison of x264 vs WebP vs JPEG by Dark Shikari. https://web.archive.org/web/20150319214453/http://x264dev.multimedia.cx/archives/541
2021-04-28 01:29:39
This comment: https://web.archive.org/web/20150319214453/http://x264dev.multimedia.cx/archives/541#comment-6211
2021-04-28 01:32:39
> I think adding mandatory deblocking to jpeg, and growing blocks from 8×8 to 32×32 (yes, not 16×16, as 32×32 isn’t a performance problem for still images IMHO), improving “psy” encoding (buy for example using variable quality for each block – by detecting foregraound, backgraound, etc) is better idea. Much more compatible, easier to implement decoder (hey, it is just a tweaked jpeg), and probably better than both jpeg and webp. Sounds familiar? I've seen it somewhere recently, but I don't know exactly where... <:Thonk:805904896879493180> *(just kidding, it's a rough description of something similar to JPEG XL)*
Crixis
2021-04-28 06:52:53
so... public repo and 0.4.0?
fab
2021-04-28 06:56:03
2021-04-28 06:56:22
when this would look similar to the original at q 38.3 and speed 9
Nova Aurora
 fab
2021-04-28 06:56:39
Firefox bookmarks?
fab
2021-04-28 06:56:44
firefox new tab
2021-04-28 06:57:54
the encoder is good for screenshots of a phone but photographic it doesn't make miracle
2021-04-28 06:58:10
at least it don't blur aggressively
2021-04-28 06:58:39
and is conservative
Nova Aurora Firefox bookmarks?
2021-04-28 07:11:55
png image
BlueSwordM
 fab
2021-04-28 07:22:03
Just use lossless JXL.
2021-04-28 07:22:13
Best overall for these types of images.
Crixis
2021-04-28 07:44:49
yup
2021-04-28 07:45:04
-m -s 9 -E 3
Scientia
2021-04-28 07:58:14
I just use -d 0 -s 9 -E 3
2021-04-28 07:58:34
I guess it archives the same result 🤔
2021-04-28 07:59:01
Modular defaults to lossless
2021-04-28 07:59:12
And lossless is only possible in modular
Crixis
2021-04-28 08:01:12
Yup
_wb_
2021-04-28 08:01:14
add -I 1 for possibly slightly better compression
2021-04-28 08:02:25
I suppose we should make a -s 10 that just adds the -E 3 -I 1 to -s 9
2021-04-28 08:02:32
or something
Scientia
2021-04-28 08:03:51
What is -l 1?
2021-04-28 08:04:04
And how much on average better?
Crixis
2021-04-28 08:04:14
A little
2021-04-28 08:04:29
Not as much E 3
Scope
 _wb_ I suppose we should make a -s 10 that just adds the -E 3 -I 1 to -s 9
2021-04-28 08:05:01
https://discord.com/channels/794206087879852103/803645746661425173/809784769608548382
Scientia
2021-04-28 08:05:09
Also I've noticed that using -E flags on lossless jpeg compression somehow increases size by very tiny amounts (think fractions of kilobytes)
2021-04-28 08:05:27
I wouldn't think -E is even applicable
2021-04-28 08:05:44
But it somehow produces a different file specifying it
_wb_
2021-04-28 08:06:17
the DC of a jpeg gets encoded with modular
Scientia
2021-04-28 08:06:26
Hm
_wb_
2021-04-28 08:07:23
any DC gets encoded with modular actually, but for the default from-pixels vardct we use a fast subset of modular that encodes and decodes fast
Scientia
2021-04-28 08:08:09
-E giving probably statistically and mostly objectively insignificant worse results on lossless jpeg though is interesting
_wb_
2021-04-28 08:08:28
but for jpeg recompression we can't use that codepath since it does modular encoding and DC quantization at the same time
2021-04-28 08:08:50
are you doing -s 9 -E 3?
Scientia
2021-04-28 08:09:01
Yeah for the jpeg recompression
2021-04-28 08:09:07
I did this a few days ago
2021-04-28 08:09:10
I remember
_wb_
2021-04-28 08:09:15
and it's worse than -s 9?
2021-04-28 08:09:18
that's a bit odd
Scientia
2021-04-28 08:09:30
The size difference as I said is like 0.1 kilobytes or something
2021-04-28 08:09:53
So not like drastically worse, but not worth it
_wb_
2021-04-28 08:10:02
could be it's because we're not properly taking the cost of the tree itself into account
Scientia
2021-04-28 08:10:07
Especially since I presume its slower
_wb_
2021-04-28 08:10:41
so the data itself might compress better, but not enough to make up for the tree also getting larger
Scientia
2021-04-28 08:11:01
That could be possible
_wb_
2021-04-28 08:11:13
in general it's probably not really worth it to do something slower than default for jpeg recompression
Scientia
2021-04-28 08:11:16
It may be that I was dealing with smaller files
2021-04-28 08:11:35
Maybe on a very large jpeg -E 3 would be better?
_wb_
2021-04-28 08:11:43
could be
2021-04-28 08:12:00
but you don't want to do -s 9 -E 3 on a very large jpeg right now
Scientia
2021-04-28 08:12:14
Yeah probably not <:kekw:808717074305122316>