|
spider-mario
|
2021-02-15 04:59:58
|
bi-level images are kind of jbig2’s thing, I wonder how it performs on this type of pixel art
|
|
2021-02-15 05:00:24
|
probably not quite as well as for those scanned documents for which it’s designed?
|
|
|
|
Deleted User
|
|
spider-mario
for what it’s worth, I would call this “bi-level” rather than “monochrome” — the term monochrome generally refers to multiple shades of one hue
|
|
2021-02-15 05:19:56
|
I would simply call it black-and-white image. If it only uses two levels, then why not call them by their name. :)
|
|
|
|
spider-mario
|
2021-02-15 05:20:25
|
some people interpret “black and white” as grayscale, though
|
|
2021-02-15 05:21:13
|
might as well avoid the ambiguity if it’s that easy
|
|
|
|
Deleted User
|
2021-02-15 05:25:24
|
For me it's:
black and white – bi-level grayscale
grayscale – monochrome without colors
|
|
|
spider-mario
for example, wikipedia gives this as an example of monochrome green image: https://upload.wikimedia.org/wikipedia/commons/6/64/Afghan_National_Army_commandos_with_the_1st_Tolai%2C_6th_Special_Operations_Kandak_clear_a_compound_during_an_operation_in_Nejrab_district%2C_Kapisa_province%2C_Afghanistan%2C_Dec._16%2C_2013_131216-A-CL980-198.jpg
|
|
2021-02-15 05:27:41
|
This is actually not even monochrome green since it contains other colors as well (╯°□°）╯︵ ┻━┻
|
|
|
|
spider-mario
|
2021-02-15 05:28:11
|
what other colors?
|
|
|
BlueSwordM
|
2021-02-15 05:28:21
|
Actually, it's only green.
|
|
2021-02-15 05:28:26
|
Different levels of green. 😛
|
|
2021-02-15 05:28:53
|
You have very dark green, dark green, medium green, light green, very light green.
|
|
|
|
Deleted User
|
2021-02-15 05:29:16
|
No, zoom in or check out a histogram, it contains small parts of yellow, red, ...
|
|
2021-02-15 05:29:51
|
What about that blinding white in the middle? It's not only max green, but also max red and max blue...
|
|
2021-02-15 05:29:52
|
but I don't know if that's only caused by JPEG compression
|
|
|
|
spider-mario
|
|
What about that blinding white in the middle? It's not only max green, but also max red and max blue...
|
|
2021-02-15 05:30:22
|
depending on your state of adaptation, you could call it achromatic 😉
|
|
2021-02-15 05:31:47
|
I think I would call this mostly green
|
|
|
|
Deleted User
|
2021-02-15 05:32:02
|
What's that software?
|
|
|
|
spider-mario
|
2021-02-15 05:32:18
|
DaVinci Resolve
|
|
|
|
Deleted User
|
2021-02-15 05:34:11
|
the free or paid version?
|
|
|
Crixis
|
|
spider-mario
bi-level images are kind of jbig2’s thing, I wonder how it performs on this type of pixel art
|
|
2021-02-15 05:34:21
|
similiar to png
|
|
|
|
spider-mario
|
|
the free or paid version?
|
|
2021-02-15 05:34:54
|
I’m using the paid version but I’m almost sure that this feature is also in the free version
|
|
|
_wb_
|
|
This is actually not even monochrome green since it contains other colors as well (╯°□°）╯︵ ┻━┻
|
|
2021-02-15 05:36:14
|
That kind of depends in what colorspace you look at things.
|
|
|
lonjil
|
2021-02-15 05:38:31
|
Also: in a lot of contexts, a very strong light of a pure color will look white.
|
|
|
|
Crixis
|
|
_wb_
That kind of depends in what colorspace you look at things.
|
|
2021-02-15 05:39:28
|
since most colorspaces are also non linear I can make 3 cordinate there are 33,3333..% in the image
|
|
|
|
spider-mario
|
2021-02-15 05:40:19
|
yes, what looks “white” is very much dependent on the viewer’s https://en.wikipedia.org/wiki/Chromatic_adaptation state
|
|
|
|
Crixis
|
|
lonjil
Also: in a lot of contexts, a very strong light of a pure color will look white.
|
|
2021-02-15 05:40:25
|
good hdr visualization of f***ing strong green
|
|
|
|
lonjil
|
2021-02-15 05:41:20
|
I believe "filmic" rendering in blender does this, because cameras don't have perfect filtration.
|
|
|
|
spider-mario
|
2021-02-15 05:41:36
|
plus, there is the complication of related vs. unrelated colors
|
|
2021-02-15 05:41:50
|
brown is a related color, for example, and so is grey
|
|
2021-02-15 05:41:58
|
they only ever exist in contrast to another, brighter color
|
|
2021-02-15 05:42:23
|
try to illuminate a room with “brown” or “grey” light and they will just look orange and white, respectively
|
|
|
|
Crixis
|
|
spider-mario
yes, what looks “white” is very much dependent on the viewer’s https://en.wikipedia.org/wiki/Chromatic_adaptation state
|
|
2021-02-15 05:42:59
|
I have a room with red curtains, my smartphone cant equilibrate white so much, all become pink
|
|
|
|
spider-mario
|
2021-02-15 05:45:13
|
there is a whole paper dedicated to brown: https://onlinelibrary.wiley.com/doi/abs/10.1111/j.1520-6378.1976.tb00041.x
|
|
|
lithium
|
2021-02-15 05:57:21
|
A little curious, in near file size and high bbp,
lowest dssim and lowest ssimulacra image file quality is better?
(0.000646, 0.00484238), (0.000862, 0.00885931), (0.001299, 0.01023229)
|
|
|
Scope
|
|
|
lithium
|
2021-02-15 06:03:53
|
thank you very much <@!111445179587624960> 🙂
|
|
|
Jyrki Alakuijala
|
2021-02-15 07:09:33
|
dssim, ssimulacra and butteraugli all chose the same philosophy where 0.0 == no loss, the bigger the value more difference between the images
|
|
2021-02-15 07:10:16
|
pretty much every other metric has bigger numbers for better quality, some metrics have infinity for the same image (annoying for normalization for example for graphing purpose, leading the infinity to be clamped some weird number like 99)
|
|
|
Crixis
monocromatic pixelart seem hard for jxl
|
|
2021-02-15 07:13:43
|
The way we designed the palette and context modeling allows us to put more pixels than one in a palette entry. For example, one palette entry could have pixels '0110110110111111000000', and we could make that sequence to trigger at different probabilities based on the surrounding pixels
|
|
2021-02-15 07:14:06
|
if we go that way, jxl will eat every other codec for breakfast for b/w images
|
|
2021-02-15 07:14:17
|
but it requires encoder work and has not been a priority for now
|
|
2021-02-15 07:14:46
|
building such an encoder could make a great intern project for a 2022 summer intern
|
|
|
|
lithium
|
2021-02-15 07:16:23
|
Something let ssimulacra and dssim upset?(jpeg xl -d, -Q)
// Butteraugli
{
"original_cut_128x128_01_cavif_Q90_s1.png": {
"maxButteraugli": "0.868652",
"dssim": "0.000646",
"ssimulacra": "0.00484238"
},
"original_cut_128x128_01_cjxl_d0.3_s7.png": {
"maxButteraugli": "0.614911",
"dssim": "0.000617",
"ssimulacra": "0.00574458"
},
"original_cut_128x128_01_cjxl_d0.4_s7.png": {
"maxButteraugli": "0.776700",
"dssim": "0.000933",
"ssimulacra": "0.00802986"
},
"original_cut_128x128_01_cjxl_m_Q97_s9.png": {
"maxButteraugli": "0.399970",
"dssim": "0.000434",
"ssimulacra": "0.00536010"
},
"original_cut_128x128_01_cjxl_m_Q98_s9.png": {
"maxButteraugli": "0.368563",
"dssim": "0.000273",
"ssimulacra": "0.00366640"
}
}
|
|
2021-02-15 07:24:56
|
// Butteraugli jxl
{
"original_cut_128x128_01_cavif_Q90_s1.png": {
"maxButteraugli": "1.7593579292",
"6Norm": " 1.052826",
"12Norm": " 1.311489",
"averageNorm": 1.1821575
},
"original_cut_128x128_01_cjxl_d0.3_s7.png": {
"maxButteraugli": "0.6046031713",
"6Norm": " 0.382781",
"12Norm": " 0.442715",
"averageNorm": 0.412748
},
"original_cut_128x128_01_cjxl_d0.4_s7.png": {
"maxButteraugli": "0.7529764175",
"6Norm": " 0.483268",
"12Norm": " 0.558505",
"averageNorm": 0.5208865
},
"original_cut_128x128_01_cjxl_m_Q97_s9.png": {
"maxButteraugli": "0.4559305310",
"6Norm": " 0.280250",
"12Norm": " 0.326356",
"averageNorm": 0.303303
},
"original_cut_128x128_01_cjxl_m_Q98_s9.png": {
"maxButteraugli": "0.3702372909",
"6Norm": " 0.216346",
"12Norm": " 0.258042",
"averageNorm": 0.23719400000000002
}
|
|
2021-02-15 07:33:06
|
in -d 0.3 s7 dssim and ssimulacra is fine, but if increase -d, they will very upset.
|
|
|
|
Jyrki Alakuijala
|
2021-02-15 07:39:12
|
which value is upset?
|
|
|
|
lithium
|
2021-02-15 07:40:12
|
I using avif Q90 compare jpeg xl -d and -Q,
|
|
2021-02-15 07:40:35
|
in avif Q90 "dssim": "0.000646", "ssimulacra": "0.00484238"
|
|
|
|
Jyrki Alakuijala
|
2021-02-15 07:41:20
|
are you able to get error maps from the metrics?
|
|
2021-02-15 07:41:28
|
if yes, take look at where the error is
|
|
2021-02-15 07:41:55
|
ssimulacra looks at edges and maximum error and puts some weight on them
|
|
2021-02-15 07:42:47
|
https://dougallj.github.io/applegpu/docs.html looks somewhat interesting
|
|
|
|
Scope
|
2021-02-15 07:42:58
|
I think with such a small image resolution, there may be more spread of metric values
|
|
|
|
Jyrki Alakuijala
|
2021-02-15 07:43:00
|
I wonder what the implications are for running JPEG XL on it
|
|
|
|
lithium
|
2021-02-15 07:44:32
|
That image is from my gitlab issue
|
|
|
|
Jyrki Alakuijala
|
2021-02-15 07:44:34
|
Lee, I think you can just use the 9Norm instead of 6 and 12 and averaging
|
|
|
|
lithium
|
2021-02-15 07:45:30
|
ok, i will change to 9Norm 🙂
|
|
|
|
Jyrki Alakuijala
|
2021-02-15 07:46:58
|
or use, 7.777 norm, 7 is my lucky number
|
|
2021-02-15 07:47:13
|
in my experience it doesn't matter so much which one you use
|
|
2021-02-15 07:47:24
|
I'm often using 3-6 norm for optimization
|
|
|
|
lithium
|
2021-02-15 07:47:56
|
dismap -d0.5 s7
|
|
|
|
Jyrki Alakuijala
|
2021-02-15 07:47:58
|
currently I'm optimizing low bpp and ac strategy, and there I'm using a very low norm, 1.5, to have more weight on the errors made on larger surfaces
|
|
|
|
lithium
|
2021-02-15 07:48:33
|
how to correct read this dismap?
|
|
2021-02-15 07:51:00
|
oh i understand, green area is error?
|
|
2021-02-15 07:58:56
|
I forget say this information,
in uncut original image, -d 0.5 -s7 114kb, -Q 95 -s9 127kb, avif -Q 90 93kb
|
|
|
|
Jyrki Alakuijala
|
2021-02-15 08:00:12
|
how many stars can we get on the JPEG XL in Blink bug: https://bugs.chromium.org/p/chromium/issues/detail?id=539120
|
|
|
|
lithium
|
2021-02-15 08:00:17
|
<@!111445179587624960> 128x128 is error area, cut from original image, original image is 800x600
|
|
|
|
Jyrki Alakuijala
|
|
lithium
I forget say this information,
in uncut original image, -d 0.5 -s7 114kb, -Q 95 -s9 127kb, avif -Q 90 93kb
|
|
2021-02-15 08:01:36
|
if the error map is from butteraugli, blue is lowest error, then green (still ok), and yellow is the higher error (next is red and then magenta, and then cycling to pastel colors)
|
|
2021-02-15 08:02:07
|
(it doesn't look like a usual error map from butteraugli)
|
|
|
|
lithium
|
2021-02-15 08:04:29
|
butteraugli_jxl original_cut_128x128_01.png original_cut_128x128_01_cjxl_d0.5_s7.png --distmap distmap.png
|
|
2021-02-15 08:05:41
|
jpeg-xl 0.3.1 ef3f7a62
|
|
|
|
veluca
|
|
Jyrki Alakuijala
how many stars can we get on the JPEG XL in Blink bug: https://bugs.chromium.org/p/chromium/issues/detail?id=539120
|
|
2021-02-15 08:09:58
|
I think you meant to send this: https://bugs.chromium.org/p/chromium/issues/detail?id=1178058 😛
|
|
|
|
lithium
|
2021-02-15 08:15:26
|
I don't want to pick a fight on jpeg xl, just hope jpeg xl can make better.
|
|
|
|
Deleted User
|
2021-02-16 03:35:14
|
Question about patches: do they require an exact, pixel-perfect match in the encoder or can they differ slightly (e.g. text with lossy JPG artifacts) and be "corrected" afterwards in another layer?
|
|
|
|
_wb_
|
2021-02-16 06:30:58
|
They can differ slightly, they get subtracted from the image so residuals still remain to be encoded (or quantized away, at low enough quality and if they are insignificant enough)
|
|
2021-02-16 09:44:08
|
|
|
2021-02-16 09:44:28
|
this is what default cjxl produces
|
|
2021-02-16 09:44:35
|
(without --progressive)
|
|
2021-02-16 09:48:30
|
hm did something wrong, forgot to make it decode the non-truncated image (you see the last truncated one when it says "done")
|
|
|
fab
|
2021-02-16 02:54:56
|
i have chrome 88 and jpeg xl doesn't display
|
|
2021-02-16 02:55:06
|
i have experimental web features enabled
|
|
|
|
Deleted User
|
2021-02-16 02:55:48
|
You need to download Chrome Canary
|
|
2021-02-16 02:56:06
|
And even then it's probably not included in the compiled binary (yet)
|
|
|
|
fab
|
2021-02-16 02:57:35
|
windows 7 user
|
|
2021-02-16 02:57:50
|
so maybe i have a binary for older computers
|
|
2021-02-16 02:57:52
|
or not
|
|
2021-02-16 02:58:13
|
still i'm put in a blacklist ip
|
|
2021-02-16 02:58:38
|
so chrome says the captcha error
|
|
2021-02-16 02:58:50
|
and i can't browse with chrome
|
|
2021-02-16 02:58:52
|
so i need firefox
|
|
|
|
Deleted User
|
2021-02-16 02:59:53
|
Don't use products by Google. They are evil. ^^
|
|
|
|
fab
|
2021-02-16 03:03:19
|
i read that can be caused by user agent switcher but even by adblockers python
|
|
2021-02-16 03:03:22
|
the stuff i use
|
|
2021-02-16 03:03:31
|
i visit 180-480-560 sites daily
|
|
2021-02-16 03:04:17
|
but it can be also an adware that malwarebytes knows
|
|
2021-02-16 03:04:47
|
also can be the old computer who still runs old graphics etc OS
|
|
2021-02-16 03:05:10
|
delay in paying bill
|
|
2021-02-16 03:05:32
|
i don't really know what is the cause but i have the error not new
|
|
2021-02-16 03:05:43
|
many years and i haven't knw anything
|
|
2021-02-16 03:06:27
|
it can simply be that i haven't a VPN or some type of protection
|
|
2021-02-16 03:07:35
|
maybe i downloaded folders of flacs
|
|
2021-02-16 03:07:53
|
but i don't understand why my friends all use chrome opera etc with no problems
|
|
2021-02-16 03:19:41
|
....
|
|
2021-02-16 03:20:05
|
no still it don't read the image
|
|
2021-02-16 03:28:42
|
and chrome can't let open the first site
|
|
2021-02-16 03:29:06
|
maybe that happens when Google is the only company
|
|
|
|
Deleted User
|
2021-02-16 03:32:39
|
JPEG XL is probably not yet compiled into the binary, you have to checkout the code yourself from the repo and compile your own Chromium browser
|
|
2021-02-16 03:33:07
|
No wonder you can't open .jxl yet
|
|
|
|
_wb_
|
2021-02-16 03:34:23
|
it will take a while
|
|
2021-02-16 03:34:32
|
https://chromium-review.googlesource.com/c/chromium/src/+/2693607
|
|
2021-02-16 03:34:40
|
patch still needs to get accepted
|
|
|
|
fab
|
2021-02-16 03:35:06
|
yes but why using jpeg xl
|
|
|
|
Deleted User
|
2021-02-16 03:35:14
|
> Merge conflict
Ooopsie...
|
|
|
|
fab
|
2021-02-16 03:35:15
|
if people still use jpg and png and gif
|
|
2021-02-16 03:35:25
|
and lossless need to be updated
|
|
|
|
_wb_
|
2021-02-16 03:35:40
|
what do you mean?
|
|
|
|
fab
|
2021-02-16 03:36:39
|
maybe there will be new version of lossless mode modular
|
|
|
|
_wb_
|
|
|
fab
|
2021-02-16 03:36:50
|
so why bother with jpeg xl now
|
|
|
|
Deleted User
|
2021-02-16 03:36:52
|
There will be none
|
|
|
|
_wb_
|
2021-02-16 03:36:53
|
the bitstream is finalized
|
|
2021-02-16 03:37:06
|
we are still looking at encoder improvements
|
|
2021-02-16 03:37:40
|
the encoder will likely see many improvements still, to pick better defaults for lossless, do better at low bitrates, etc
|
|
2021-02-16 03:37:45
|
but the decoder is done
|
|
|
|
fab
|
2021-02-16 03:38:04
|
but who will do these conversion
|
|
2021-02-16 03:38:15
|
for example an image of a female journalist in png
|
|
2021-02-16 03:38:19
|
who will convert it to jxl
|
|
2021-02-16 03:38:30
|
who is that will choose the speed
|
|
2021-02-16 03:38:36
|
is that cloudflare
|
|
2021-02-16 03:38:38
|
cloudinary
|
|
|
|
_wb_
|
2021-02-16 03:38:42
|
that's up to web devs to decide
|
|
|
|
fab
|
2021-02-16 03:38:43
|
or it can be anyone
|
|
|
|
Deleted User
|
2021-02-16 03:38:51
|
Believe me <@416586441058025472>, the bitstream is so damn expressive that it'll take ages for the encoder devs to exploit all the quirks
|
|
|
|
_wb_
|
2021-02-16 03:39:04
|
anyone can use whatever encoder settings, write their own encoder if they want to
|
|
|
|
Deleted User
|
2021-02-16 03:39:07
|
It already took 20+ years since JPEG's creation to create mozjpeg
|
|
|
|
fab
|
2021-02-16 03:39:18
|
but how to force adoption
|
|
2021-02-16 03:39:30
|
for example reddit is forcing webp
|
|
|
|
Deleted User
|
2021-02-16 03:39:43
|
We have to write to them and convince them
|
|
2021-02-16 03:39:51
|
E.g. I'll convince Google Photos
|
|
2021-02-16 03:40:08
|
I gonna write the ticket when Chromium support will be ready
|
|
|
|
Crixis
|
2021-02-16 03:40:12
|
stop fun and force jxl, #NOW
|
|
|
|
fab
|
2021-02-16 03:40:27
|
in most sites there are file size limits
|
|
2021-02-16 03:40:35
|
but you can also update png and jpg
|
|
|
|
_wb_
|
2021-02-16 03:40:56
|
you cannot force adoption
|
|
|
|
fab
|
2021-02-16 03:40:57
|
but who will force adoption and say to italians you need to download your image in jxl
|
|
|
|
_wb_
|
2021-02-16 03:41:05
|
you can only encourage it
|
|
|
|
fab
|
2021-02-16 03:41:07
|
at least on most sites
|
|
|
|
_wb_
|
2021-02-16 03:41:24
|
JPEG, GIF and PNG will not die anytime soon
|
|
|
|
Crixis
|
|
fab
at least on most sites
|
|
2021-02-16 03:41:24
|
but why?
|
|
2021-02-16 03:41:39
|
https://tenor.com/view/why-huh-but-why-gif-13199396
|
|
|
|
fab
|
2021-02-16 03:41:47
|
like who will do speed 7 lossless jxl
|
|
|
|
_wb_
|
2021-02-16 03:42:04
|
but if we make it easy enough to adopt jxl, then hopefully people will use it
|
|
|
|
fab
|
2021-02-16 03:42:04
|
crixis do you know
|
|
|
|
_wb_
|
2021-02-16 03:42:55
|
e.g. with Cloudinary, it will be pretty easy. For most of our customers, they will at some point start using jxl without them even knowing about it
|
|
2021-02-16 03:43:13
|
because we have a `f_auto` feature that automatically uses the best available format
|
|
|
|
fab
|
2021-02-16 03:43:26
|
obviously in this server you can't talk about cloudflare
|
|
2021-02-16 03:43:31
|
only cloudinary talks
|
|
|
|
Crixis
|
2021-02-16 03:44:49
|
what? I don't need force other persons to use the best format, I only want me use the best format, all know <@!794205442175402004> use only FLIF in his private
|
|
|
|
fab
|
2021-02-16 03:45:04
|
like we will see in newer image jxl
|
|
2021-02-16 03:45:15
|
but old images archives will remain older formats
|
|
2021-02-16 03:45:25
|
and probably they will not use lossless
|
|
|
|
_wb_
|
2021-02-16 03:45:32
|
```$ curl -sD - https://res.cloudinary.com/jon/f_auto/sample.jpg
HTTP/2 200
content-type: image/jpeg
etag: "26b388a32b50e096e9e4ea17b174f730"
last-modified: Fri, 29 Jan 2021 11:22:24 GMT
x-request-id: 562b85a8d1d040a975fd8cf476214553
date: Tue, 16 Feb 2021 15:40:20 GMT
vary: Accept,User-Agent
[...]
$ curl -sD - -H "Accept: image/webp" https://res.cloudinary.com/jon/f_auto/sample.jpg
HTTP/2 200
content-disposition: inline; filename="sample.webp"
content-type: image/webp
etag: "e6cd92587d28654e524f215e4d5a79ed"
last-modified: Fri, 29 Jan 2021 11:22:16 GMT
date: Tue, 16 Feb 2021 15:40:05 GMT
vary: Accept,User-Agent
[...]
$ curl -sD - -H "Accept: image/jxl" https://res.cloudinary.com/jon/f_auto/sample.jpg
HTTP/2 200
content-type: image/jxl
etag: "b376d12f595c5e8802f0ce5a2ef12679"
last-modified: Thu, 28 Jan 2021 19:34:05 GMT
date: Tue, 16 Feb 2021 15:39:48 GMT
vary: Accept,User-Agent
[...]```
|
|
|
|
fab
|
2021-02-16 03:45:33
|
but re convert jpg to png then to jxl
|
|
|
|
Crixis
|
|
fab
but old images archives will remain older formats
|
|
2021-02-16 03:46:23
|
https://tenor.com/view/stepbrothers-will-ferrell-john-c-reilly-sooo-umm-gif-5780009
|
|
|
|
_wb_
|
2021-02-16 03:46:41
|
I assume Cloudflare will also add jxl support once it is available in chrome, they would be silly not to do that
|
|
|
|
fab
|
2021-02-16 03:46:55
|
but cloudflare will reconvert older images
|
|
2021-02-16 03:47:03
|
or that's up to the site
|
|
2021-02-16 03:47:16
|
like newyorktimes like reddit to add support
|
|
2021-02-16 03:47:27
|
so png will get deleted when
|
|
2021-02-16 03:49:11
|
crixis is writing
|
|
|
|
Crixis
|
2021-02-16 03:50:52
|
<@!416586441058025472> you are so extreme, just let slowly vanish in the oblivion old formats, don't kill all for the Greater Good. There is no use in ban jpg or png.
|
|
|
|
_wb_
|
2021-02-16 03:51:03
|
even in the most optimistic scenario, there will be a loooong long tail of clients that will want to have old formats (jpg/png/gif), as well as legacy servers that don't get updated, and old websites, etc
|
|
2021-02-16 03:51:29
|
that's not a big problem though
|
|
2021-02-16 03:51:44
|
big traffic websites will have an incentive to upgrade
|
|
2021-02-16 03:52:16
|
once there is chromium support, we will be in most browsers in a year or two
|
|
|
|
Crixis
|
2021-02-16 03:52:36
|
jxl will slowly make internet more efficient day after day (also more creative i suppose)
|
|
|
|
fab
|
2021-02-16 03:53:09
|
internet has a limit because of the fiber or because of the HDD
|
|
2021-02-16 03:53:21
|
what it was the incentive to support AV1
|
|
2021-02-16 03:53:35
|
companies and google spending less money
|
|
|
|
_wb_
|
2021-02-16 03:53:35
|
when HDR becomes more mainstream, the old formats will become more of a limitation too
|
|
|
|
Crixis
|
|
fab
internet has a limit because of the fiber or because of the HDD
|
|
2021-02-16 03:53:46
|
fiber
|
|
|
|
_wb_
|
2021-02-16 03:54:07
|
bandwidth is generally more costly than storage, though both matter
|
|
2021-02-16 03:54:17
|
but making end-users wait is the most costly thing of all
|
|
|
|
Scope
|
2021-02-16 03:54:29
|
Reddit could have added JXL with a certain chance, I had an friend there who did this technical stuff and he was interested in JXL (after the browser support came out), but unfortunately he moved on to another company
|
|
|
|
Crixis
|
|
Scope
Reddit could have added JXL with a certain chance, I had an friend there who did this technical stuff and he was interested in JXL (after the browser support came out), but unfortunately he moved on to another company
|
|
2021-02-16 03:54:50
|
nooooooooooo sad
|
|
|
|
_wb_
|
2021-02-16 03:54:55
|
a slow loading site means people navigate away, don't click stuff, don't buy stuff
|
|
|
|
fab
|
2021-02-16 03:55:04
|
like telefonic company what they get with jxl and avif
|
|
2021-02-16 03:55:32
|
what they save
|
|
2021-02-16 03:56:17
|
i don't work in that sector so i don't know
|
|
|
|
_wb_
|
2021-02-16 03:56:25
|
you mean like internet providers?
|
|
|
|
fab
|
2021-02-16 03:56:28
|
yes
|
|
2021-02-16 03:56:47
|
they save fiber bandwith storage money
|
|
2021-02-16 03:56:51
|
what they save most
|
|
|
|
_wb_
|
2021-02-16 03:57:06
|
well they charge people for it so they probably don't care that much
|
|
|
|
fab
|
2021-02-16 03:57:43
|
and why they said videos are 90% of fiber bandwith
|
|
2021-02-16 03:58:27
|
that's true or false, or only google and companies interest
|
|
|
|
_wb_
|
2021-02-16 03:59:04
|
video (even just netflix or youtube alone) is a lot of the bandwidth indeed. But nearly every page has images (the median page about 2 MB worth of images), while most pages don't have videos
|
|
|
|
fab
|
2021-02-16 03:59:55
|
so they have the money to buy new fiber
|
|
2021-02-16 04:00:00
|
they do for money
|
|
2021-02-16 04:00:10
|
not for ecologic reasons
|
|
2021-02-16 04:01:08
|
what will happen in 2200 more fiber pollution
|
|
|
|
_wb_
|
2021-02-16 04:01:10
|
google just wants to make the web better / more attractive because basically anything you do on the web allows them to sell ads
|
|
2021-02-16 04:01:31
|
same with facebook or any other big tech company
|
|
|
|
fab
|
2021-02-16 04:01:59
|
but what is true of what i said <@!424295816929345538> <@!321486891079696385>
|
|
|
|
_wb_
|
2021-02-16 04:02:20
|
luckily, as a side effect of that, we do get a better web
|
|
|
|
fab
|
2021-02-16 04:02:37
|
this is too offtopic maybe i will re write in the av1 server
|
|
2021-02-16 04:03:55
|
but if crixis or others want to discuss it here
|
|
|
|
Crixis
|
2021-02-16 04:06:04
|
<@!416586441058025472> I think you are taking the problem from the wrong angle, is not a new format that can reshape o make more sustainable Internet.
|
|
|
|
fab
|
2021-02-16 04:06:44
|
so has fiber really 90% capacity used
|
|
2021-02-16 04:07:08
|
are the cable really busy/polluted with h264 videos
|
|
2021-02-16 04:07:42
|
or maybe i didn't understood this aspect
|
|
2021-02-16 04:09:10
|
how the network strains?
|
|
|
|
Crixis
|
2021-02-16 04:11:35
|
there is not a traffic limits, if one fiber is not sufficient make it 2, the technology of connection will always improve as the technology of codecs. The world could use jpg and png in the future, just jxl is better. No one as to "save" internet.
|
|
|
|
fab
|
2021-02-16 04:12:50
|
ah so it's in general only to save network or bandwith costs both providers and companies
|
|
2021-02-16 04:13:09
|
and have better experience
|
|
|
|
Crixis
|
2021-02-16 04:13:10
|
more for user than company
|
|
|
|
fab
|
2021-02-16 04:13:40
|
in Italy has the companies also this problem
|
|
|
|
Crixis
|
2021-02-16 04:13:58
|
a company with better experience will have more users
|
|
|
|
fab
|
2021-02-16 04:14:06
|
80% of their fiber traffic in a year busy with videos
|
|
2021-02-16 04:14:20
|
like Vodafone
|
|
2021-02-16 04:14:34
|
because the document was for USA
|
|
2021-02-16 04:14:39
|
what about in Italy
|
|
2021-02-16 04:16:03
|
this was obviously intensified by the lockdown
|
|
|
|
Crixis
|
|
fab
80% of their fiber traffic in a year busy with videos
|
|
2021-02-16 04:16:27
|
This is not a problem, av1 will only make you a better experience for the same money, there is't a limit to internet connection, if you pay vodafone it will make more internet lines
|
|
|
|
fab
|
2021-02-16 04:17:57
|
so a problem only for vodafone google india users and people who want more compresssion
|
|
2021-02-16 04:18:21
|
want to save money
|
|
|
|
Crixis
|
2021-02-16 04:19:32
|
yep, I before vp9 could not see Youtube HD
|
|
|
|
fab
|
2021-02-16 04:20:07
|
a connection should go at least 12 mbps
|
|
|
|
Crixis
|
2021-02-16 04:20:16
|
not mine
|
|
|
|
fab
|
2021-02-16 04:20:20
|
1,6 mbit second
|
|
2021-02-16 04:20:37
|
i'm windtre
|
|
|
bonnibel
|
2021-02-16 04:20:49
|
Ha, I've had to like with 112kbps once
|
|
|
|
Crixis
|
2021-02-16 04:20:54
|
Adsl 1,6 Km distant from the node
|
|
|
|
Jyrki Alakuijala
|
2021-02-16 05:13:17
|
in my youth my country was connected to the Internet backbone with a single 64 kbps link
|
|
2021-02-16 05:14:05
|
things are getting better 😄
|
|
|
veluca
I think you meant to send this: https://bugs.chromium.org/p/chromium/issues/detail?id=1178058 😛
|
|
2021-02-16 05:16:56
|
haha, cut-n-paste is difficult 😄
|
|
2021-02-16 05:17:48
|
yes, can we get stars to 77 my favorite number: https://bugs.chromium.org/p/chromium/issues/detail?id=1178058 🙂
|
|
|
|
BlueSwordM
|
2021-02-16 07:31:53
|
So, are there any hidden flags besides those shown by `cjxl -h -v -v` in CJXL?
|
|
|
|
_wb_
|
2021-02-16 07:57:27
|
Don't think so (or maybe you need one more -v, don't remember)
|
|
2021-02-16 07:57:53
|
You can't add flags without also adding help for them
|
|
|
|
spider-mario
|
|
_wb_
when HDR becomes more mainstream, the old formats will become more of a limitation too
|
|
2021-02-16 08:08:30
|
I very much look forwards to HDR becoming more mainstream
|
|
2021-02-16 08:08:37
|
I am already playing with editing some of my photos in HDR 😄
|
|
2021-02-16 08:08:51
|
but I won’t be able to show off the results before software support is there
|
|
2021-02-16 09:37:19
|
it seems that YouTube supports it, including on mobile
|
|
2021-02-16 09:37:29
|
so in the meantime, I can export videos to YouTube, I guess
|
|
2021-02-16 09:37:43
|
not ideal for photos, though
|
|
|
|
_wb_
|
2021-02-17 01:46:31
|
|
|
2021-02-17 01:47:02
|
visualization of the XYB colorspace
|
|
2021-02-17 01:48:39
|
since discord doesn't support jxl (yet) 🙂
|
|
2021-02-17 01:51:53
|
These are 16 values of the luma component (Y), and in each subsquare X is going from green to red horizontally and B is going from yellow to blue vertically
|
|
2021-02-17 01:53:06
|
it is fun to make small jxl files 🙂
|
|
2021-02-17 01:54:17
|
<@!179701849576833024> and I had the idea the other day to organize a contest: create the coolest jxl bitstream that is less than N bytes
|
|
2021-02-17 01:55:50
|
we were thinking to set N to 4 kilobytes, but I think there's a lot of cool stuff that can be done in less than that
|
|
2021-02-17 01:56:04
|
maybe 1 kb is enough
|
|
|
|
paperboyo
|
|
_wb_
maybe 1 kb is enough
|
|
2021-02-17 02:03:28
|
https://youtu.be/W58r7oycUrA?t=556 🙂
|
|
|
eustas
|
2021-02-17 02:07:08
|
We would have added scripts / shaders to allow cool demos in JXL
|
|
2021-02-17 02:07:23
|
At least support WASM
|
|
|
|
Deleted User
|
2021-02-17 02:07:57
|
maybe some assembler 🤣
|
|
|
|
eustas
|
2021-02-17 02:09:38
|
WASM seems to be portable and well supported assembler =))
|
|
|
|
Deleted User
|
2021-02-17 02:10:54
|
flash support would also be nice to have 🙂
|
|
|
|
Crixis
|
2021-02-17 02:12:07
|
just add flash support
|
|
|
|
eustas
|
2021-02-17 02:12:16
|
not supported by browsers anymore...
|
|
|
|
lonjil
|
2021-02-17 02:13:22
|
that's what ruffle is for
|
|
|
|
_wb_
|
2021-02-17 02:14:53
|
challenge: make a cool demo as a 4 kb animated jxl 🙂
|
|
|
|
Deleted User
|
|
_wb_
visualization of the XYB colorspace
|
|
2021-02-17 02:15:59
|
I'm curious what would the same comparison look like with Oklab:
https://bottosson.github.io/posts/oklab/
|
|
|
|
Crixis
|
|
diskorduser
|
|
Crixis
|
|
2021-02-17 02:57:59
|
I get white background on one frame.
|
|
|
|
_wb_
|
2021-02-17 03:02:14
|
|
|
2021-02-17 03:03:19
|
beautiful XYB chessboard
|
|
2021-02-17 03:11:41
|
|
|
2021-02-17 03:11:48
|
or is this one nicer?
|
|
|
_wb_
|
|
2021-02-17 03:56:13
|
|
|
2021-02-17 03:56:41
|
YCbCr
|
|
2021-02-17 03:56:44
|
XYB
|
|
2021-02-17 04:02:01
|
RGB
|
|
2021-02-17 04:02:11
|
|
|
|
|
Crixis
|
2021-02-17 04:39:37
|
what we must see in this pallets?
|
|
|
Fox Wizard
|
2021-02-17 04:42:39
|
<a:RicardoRGB:681616487894876170>
|
|
|
|
_wb_
|
2021-02-17 04:46:42
|
Just visualizations of the different color spaces
|
|
2021-02-17 04:48:48
|
16 values of "luma" (or in case of RGB, just G), and within each subsquare you have horizontally Cb or X or R and vertically Cr or B
|
|
|
|
Scope
|
2021-02-17 04:49:37
|
🇩🇪 <https://t3n.de/news/jpeg-xl-neues-bildformat-2021-1356055/>
But this news seems to be a compilation from outdated information and articles (as on Japanese sites and some other languages)
|
|
|
|
Deleted User
|
|
Fox Wizard
<a:RicardoRGB:681616487894876170>
|
|
2021-02-17 04:50:59
|
Ah yes, the *RGB*icardo
|
|
|
|
_wb_
|
|
Scope
🇩🇪 <https://t3n.de/news/jpeg-xl-neues-bildformat-2021-1356055/>
But this news seems to be a compilation from outdated information and articles (as on Japanese sites and some other languages)
|
|
2021-02-17 04:57:43
|
ugh, I hate how lazy journalists just recycle and rehash outdated info, throw it on a page with some ads and call it 'news'
|
|
2021-02-17 04:59:37
|
at least I'm working on a rather detailed and up to date article on jxl for the also German language IX magazine, so that should help
|
|
|
|
Scope
|
2021-02-17 05:00:48
|
4chan-ners also use the old comparison charts <:PepeHands:808829977608323112> (although not very surprising)
|
|
2021-02-17 05:01:03
|
|
|
|
|
lonjil
|
2021-02-17 05:02:12
|
link the thread so I can dunk
|
|
|
|
_wb_
|
2021-02-17 05:02:14
|
https://tenor.com/view/monica-raymund-gabriela-dawson-eye-roll-ugh-sigh-gif-10924070
|
|
|
|
Scope
|
2021-02-17 05:03:26
|
When I find these threads, they are usually already archived <https://boards.4channel.org/g/thread/80219062>
|
|
|
|
lonjil
|
2021-02-17 05:03:31
|
ah
|
|
2021-02-17 05:03:38
|
well, that makes sense
|
|
|
|
Scope
|
2021-02-17 05:09:13
|
https://google.github.io/brunsli/#brunsli <:SadOrange:806131742636507177>
|
|
2021-02-17 05:14:36
|
At first I thought it was <https://squoosh.app>, but no
|
|
|
|
_wb_
|
2021-02-17 05:17:29
|
ugh
|
|
2021-02-17 05:17:57
|
can we get that offline, please? or update it to produce actual jxl?
|
|
|
|
eustas
|
2021-02-17 05:30:55
|
Surely. Brunsli demo is hosted on github-pages, so I consider it is better to fix the documentation.
|
|
|
|
_wb_
|
2021-02-17 05:31:28
|
We should at least warn that these are not jxl after all
|
|
|
|
eustas
|
2021-02-17 05:31:30
|
As for JXL demo hosting - I'll take a look soon
|
|
|
|
Deleted User
|
|
_wb_
at least I'm working on a rather detailed and up to date article on jxl for the also German language IX magazine, so that should help
|
|
2021-02-17 05:31:46
|
How many languages do you speak, if I may ask?
|
|
|
|
Fox Wizard
|
2021-02-17 05:32:20
|
He's fluent in stroopwafel <:Stroopwafel:624714475941003274>
|
|
|
|
_wb_
|
2021-02-17 05:32:25
|
I wrote the article in English and a translator is now translating it to German, my German is not good enough for that
|
|
2021-02-17 05:33:03
|
My German is worse than my French
|
|
2021-02-17 05:33:25
|
Dutch is my native language
|
|
|
|
Deleted User
|
|
|
_wb_
|
2021-02-17 05:34:46
|
The Belgian variant of Dutch
|
|
|
|
Deleted User
|
2021-02-17 05:37:20
|
Just remember to post the article here so we can try translating it back to english for everyone. 😄
|
|
|
|
_wb_
|
2021-02-17 05:40:07
|
Will take a while, I think it will be in the April issue (which goes to print in March)
|
|
2021-02-17 05:40:55
|
I have a nice new blogpost upcoming next week though
|
|
|
|
Deleted User
|
2021-02-17 11:44:34
|
<@!532010383041363969> any core dev can reply, but I'm mentioning you in particular because you've been tweaking the encoder recently. I don't know if that's in the encoder yet, but better safe than sorry:
https://kornel.ski/deringing/
|
|
2021-02-17 11:45:44
|
Message inspired by my recent lossy text encodes with some ringing around the letters that can (probably) be avoided with this method
|
|
|
|
Jyrki Alakuijala
|
2021-02-18 12:22:17
|
that could work
|
|
2021-02-18 12:22:50
|
in XYB we don't define a max intensity I think, perhaps I'm mistaken
|
|
2021-02-18 12:23:10
|
but for low values, it would work
|
|
|
|
Deleted User
|
|
Jyrki Alakuijala
in XYB we don't define a max intensity I think, perhaps I'm mistaken
|
|
2021-02-18 12:24:52
|
There's no max value, like 255 in JPEG?
|
|
|
|
veluca
|
2021-02-18 12:28:54
|
not really no
|
|
2021-02-18 12:29:13
|
but we do convert to sRGB at some point, so...
|
|
|
|
member102
|
2021-02-18 03:40:31
|
Is there a directional deringer in jxl (a la Daala) ?
|
|
|
Master Of Zen
|
|
member102
Is there a directional deringer in jxl (a la Daala) ?
|
|
2021-02-18 03:41:35
|
CDEF?
|
|
2021-02-18 03:41:55
|
If so, as I know, it's currently disabled
|
|
|
|
member102
|
2021-02-18 03:42:21
|
ok, too slow I guess ?
|
|
|
|
Master Of Zen
|
|
member102
ok, too slow I guess ?
|
|
2021-02-18 03:44:48
|
If I recall that correctly, just not finished yet, by the way I haven't heard CDEF being characterized as slow filter
|
|
|
|
member102
|
2021-02-18 03:47:39
|
I see. Probably a good addition at low bit rates.
|
|
|
|
Deleted User
|
2021-02-18 04:03:25
|
https://discord.com/channels/794206087879852103/805176455658733570/808728747808129114
|
|
2021-02-18 04:04:47
|
Read veluca's and Jon's first answer:
|
|
2021-02-18 04:04:57
|
> AFAIU CDEF operates better with low bitrates, which we didn't really consider a priority - so we have our own filter that works better for detail preservation
|
|
2021-02-18 04:05:04
|
> I assume directional filtering works well in tandem with directional prediction, which we also do not have.
|
|
|
|
member102
|
|
|
_wb_
|
|
There's no max value, like 255 in JPEG?
|
|
2021-02-18 06:39:54
|
No, if the Y values get higher, it just means brighter than what your SDR screen produces 😅
You could make a jxl that encodes the Sun at actual brightness...
|
|
|
Pieter
|
2021-02-18 06:41:19
|
You totally should do that.
|
|
|
Nova Aurora
|
2021-02-18 06:43:02
|
I want it to be original, not just a render...
|
|
2021-02-18 06:43:09
|
get nasa on that
|
|
|
|
Pieter
|
2021-02-18 06:46:07
|
Are the Y values specified in terms of some actual real world brightness?
|
|
|
|
_wb_
|
2021-02-18 06:46:10
|
1.6 billion nits, not sure if our current implementation can handle that without an overflow somewhere
|
|
2021-02-18 06:46:41
|
IIRC we signal how many nits 1.0 means
|
|
2021-02-18 06:49:18
|
For HDR it could e.g. be 4000 while for SDR it could be 200
|
|
2021-02-18 06:50:27
|
(I think we set it to 255 for SDR so it conveniently and confusingly also has the same range as 8-bit ints)
|
|
2021-02-18 06:57:25
|
Sadly we can only signal up to about 65k as the nominal max nits (the limit of a binary16 float), we do not allow +inf in that field
|
|
2021-02-18 06:58:35
|
But even then, that's just what 1.0 means. The actual values can go higher (though they would get clamped at the end, I suppose)
|
|
2021-02-18 06:59:39
|
The perceptual optimization has not been calibrated for the use case of "staring into the sun" though, so your mileage may vary.
|
|
|
|
Nova Aurora
|
|
_wb_
The perceptual optimization has not been calibrated for the use case of "staring into the sun" though, so your mileage may vary.
|
|
2021-02-18 07:01:05
|
has anything? I mean when doing solar astronomy I don't think anyone cares just how bright it is, just the relative differences between the regions
|
|
|
|
_wb_
|
2021-02-18 07:04:01
|
I was joking. Staring directly into the sun is not a recommended thing to do if you want to keep your vision.
|
|
2021-02-18 07:04:32
|
1.6 billion nits is f'ing bright
|
|
2021-02-18 07:05:21
|
Peak brightness of a good HDR is already f'ing bright, and that's just a few 1000s of nits
|
|
|
|
Nova Aurora
|
2021-02-18 07:06:09
|
sadly NASA probably wouldn't approve my request to get hubble images of the sun on the grounds of 'destroying a multi-billion dollar telescope's image sensor.'
|
|
|
|
_wb_
|
2021-02-18 07:11:31
|
Probably not, no.
|
|
|
|
Nova Aurora
|
|
Nova Aurora
sadly NASA probably wouldn't approve my request to get hubble images of the sun on the grounds of 'destroying a multi-billion dollar telescope's image sensor.'
|
|
2021-02-18 07:40:56
|
Speaking of NASA, their rover lands today
|
|
|
|
_wb_
|
2021-02-18 07:55:42
|
I want to get a jxl encoder on Mars some day
|
|
|
|
Nova Aurora
|
2021-02-18 07:59:25
|
Don't most probes simply send back lightly processed data to avoid artifacting on images that cost so much to take?
|
|
|
|
_wb_
|
2021-02-18 08:24:40
|
they do a mix
|
|
2021-02-18 08:25:47
|
current ones use old lossy jpeg most of the time, and when there's something really interesting, they send a jpeg-LS lossless image to avoid artifacts
|
|
2021-02-18 08:26:11
|
bandwidth is an issue in this use case, can't just use lossless all the time
|
|
|
|
bonnibel
|
2021-02-18 08:59:31
|
gotta get one of those nuclear fusion powered monitors so it can accurately replicate the experience of staring into the sun
|
|
|
|
Crixis
|
2021-02-18 09:00:25
|
visual analogy to subwoofer
|
|
|
|
_wb_
|
2021-02-18 09:18:01
|
also need a fine mesh of tiny black holes for those deep blacks with optimal contrast
|
|
|
|
Jyrki Alakuijala
|
2021-02-18 09:26:18
|
tiny black holes are supposedly rather bright
|
|
2021-02-18 09:26:55
|
like bright enough not to fit in float16 😄
|
|
|
|
Crixis
|
|
_wb_
also need a fine mesh of tiny black holes for those deep blacks with optimal contrast
|
|
2021-02-18 09:27:52
|
Vantablack is good
|
|
2021-02-18 09:29:57
|
contrary to big black holes, small not last long, they rapidly evaporate in radiation
|
|
2021-02-18 09:32:12
|
stupid virtual particles
|
|
|
|
Jyrki Alakuijala
|
2021-02-18 09:58:47
|
https://invent.kde.org/documentation/openraster-org/-/merge_requests/4
|
|
2021-02-18 09:59:29
|
I have a personal theory about the structure of the universe
|
|
2021-02-18 10:01:03
|
It is basically that our universe is a black hole in a slightly simpler universe
|
|
2021-02-18 10:01:52
|
it is rotating (antimatter is just matter rotating the opposite direction)
|
|
2021-02-18 10:02:38
|
the birth of the black hole (likely from a merger of two smaller black holes) was the big bang
|
|
2021-02-18 10:03:02
|
I promise not to write more about it here 😄
|
|
|
|
Crixis
|
|
Jyrki Alakuijala
It is basically that our universe is a black hole in a slightly simpler universe
|
|
2021-02-18 10:11:57
|
You know holographic theory?
|
|
|
|
Deleted User
|
|
Crixis
Vantablack is good
|
|
2021-02-18 11:08:25
|
See? I'm not the only one that has thought about Vantablack-enhanced screens 😃
|
|
|
|
Crixis
|
2021-02-18 11:09:37
|
one bottle of 150 ml will cost you around $15, not so much
|
|
|
|
Deleted User
|
2021-02-18 11:09:42
|
Seems like I'm not crazy!
|
|
2021-02-18 11:09:49
|
...or we're both crazy.
|
|
2021-02-18 11:12:08
|
But aren't we all?
|
|
|
|
Crixis
|
2021-02-18 11:15:57
|
need jxl to encode this vantablack
|
|
|
|
spider-mario
|
|
But aren't we all?
|
|
2021-02-18 11:18:30
|
|
|
|
|
_wb_
|
2021-02-18 11:37:50
|
does negative Y in XYB have a meaning? "blacker than black", not just absorbing all photons but ... uh ... even blacker?
|
|
|
|
Crixis
|
2021-02-18 11:50:17
|
in physical meaning I don't think the can be more then absorb all photons and make heat radiation.
Truly the sun is the more black body in the solar system:
1) It adsorb f***ing all external light that come into it (zero reflection)
2) It emits only perfect heat frequencies
It so much hot that his black body radiation are in visible frequencies
Absorb photon without emit heat is against thermodynamic
|
|
2021-02-18 11:57:16
|
Black hole is the only thing more "black", 0 reflection, only minimal radiation, more big, less radiation/mass
|
|
|
|
_wb_
|
2021-02-18 12:44:32
|
https://discordapp.com/channels/794206087879852103/803605943338008586/811931409806655498
|
|
2021-02-18 12:44:58
|
sigh why does it not turn that into a nice quote
|
|
2021-02-18 12:45:18
|
how do you elegantly move a discussion to a different channel in this platform?
|
|
2021-02-18 12:46:11
|
anyway, why Brotli for XMP metadata? Because it is great to compress XML, and also it is nice to reuse a component that is already available
|
|
2021-02-18 12:49:38
|
the internal compression jxl uses: headers are just bit-packed tightly, usually with fields that have variable-length encodings (e.g. not encoded at all if that part of the header is all-default, otherwise 2 bits for the most common values, and e.g. 5 bits for uncommon values and 12 bits for rare values)
|
|
2021-02-18 12:54:06
|
for the image data itself: it's ANS with a fast hybrid symbol encoding (using just raw bits for a configurable amount of least significant bits after a configurable magnitude threshold), with optional lz77 references, and with an option to use simple prefix coding instead of ANS (which is worse but could be useful e.g. for hardware encoding). The context model is a parametrized special-purpose one for AC coefficients, and a Meta-Adaptive one (like in FLIF) for everything else.
|
|
|
Dr. Taco
|
2021-02-18 05:56:58
|
<@!424295816929345538> That PNG is interesting, there actually is data in the vanta part, and you can tell it used to be a JPG
|
|
|
|
Nova Aurora
|
2021-02-18 07:22:46
|
Taken with a phone?
|
|
2021-02-18 07:23:01
|
Then converted to png after the fact?
|
|
|
|
_wb_
|
2021-02-18 07:44:07
|
Maybe accidentally used a 98% opacity black brush in photoshop or something
|
|
|
|
Crixis
|
2021-02-18 08:10:32
|
Vantablack is real!
|
|
|
VEG
|
|
_wb_
anyway, why Brotli for XMP metadata? Because it is great to compress XML, and also it is nice to reuse a component that is already available
|
|
2021-02-19 12:55:32
|
Thanks for the clarification 🙂
|
|
2021-02-19 12:58:08
|
Zstd is a bit superior, but Brotli is already implemented in browsers, and JXL targets to Web, so Brotli makes sense.
|
|
|
|
Scope
|
2021-02-19 01:35:10
|
https://twitter.com/jyzg/status/1167896428900827136
|
|
|
|
VEG
|
|
Scope
https://twitter.com/jyzg/status/1167896428900827136
|
|
2021-02-19 01:48:18
|
I believe that comparison was not fair. Brotli has a built-in dictionary, and Zstd doesn't have it by default, but it can be specified. Having a dictionary is crucial for compressing small pieces of data.
|
|
2021-02-19 01:49:23
|
So, a special dictionary could be created for the JXL metadata, and it would compress it better with this dictionary, much better than with a general purpose dictionary that Brotli has.
|
|
2021-02-19 01:53:54
|
So, to make it fair, at least Brotli's dictionary could be used with Zstd (flexibility of Zstd allows to do it easily).
|
|
|
|
Scope
|
2021-02-19 02:05:57
|
As far as I remember brotli usually beats zstd on most data types if they use the same window size setting (by default Zstandard has much larger window, so it's more efficient in comparisons where their size is not specified), but I think <@!532010383041363969> can answer more about this
|
|
|
|
_wb_
|
2021-02-19 02:11:30
|
the general purpose dictionary of Brotli is quite good already for something like XMP metadata
|
|
|
|
Scope
|
2021-02-19 02:22:54
|
Also, when I was comparing "ZPNG" and "BPNG" (uncompressed PNG + compressor), Brotli was denser (but also slower in decompression, although at such high speeds it is not so important)
Zstandard has since become more efficient, but I don't think that if one of them is properly optimized for the required data, they will be very different and one of them is superior and the other is bad
|
|
|
|
Deleted User
|
2021-02-19 02:27:15
|
https://tenor.com/view/you-dense-you-dense-motherfucker-motherflocker-you-dense-motherflocker-gif-17518444
|
|
2021-02-19 02:27:23
|
:))
|
|
|
|
Jyrki Alakuijala
|
|
Scope
Also, when I was comparing "ZPNG" and "BPNG" (uncompressed PNG + compressor), Brotli was denser (but also slower in decompression, although at such high speeds it is not so important)
Zstandard has since become more efficient, but I don't think that if one of them is properly optimized for the required data, they will be very different and one of them is superior and the other is bad
|
|
2021-02-19 03:26:37
|
All the LZ77 optimizations of zstd can be brought to brotli, but not the other way around. This is mostly because brotli allows context modeling (and more flexible block switching structure).
|
|
|
VEG
Zstd is a bit superior, but Brotli is already implemented in browsers, and JXL targets to Web, so Brotli makes sense.
|
|
2021-02-19 03:28:10
|
Zstd as a format compresses slower, and is worse for streaming (hides more data because of interleaving in the format), but decompresses faster. The encoder has seen more love than Brotli's encoder, especially so for benchmarking uses (fast modes for very large windows)
|
|
|
VEG
I believe that comparison was not fair. Brotli has a built-in dictionary, and Zstd doesn't have it by default, but it can be specified. Having a dictionary is crucial for compressing small pieces of data.
|
|
2021-02-19 03:29:05
|
That does not match my observations. I believe the large corpora (gigabytes) don't benefit from a small static dictionary at all.
|
|
|
VEG
So, to make it fair, at least Brotli's dictionary could be used with Zstd (flexibility of Zstd allows to do it easily).
|
|
2021-02-19 03:30:04
|
Zstd can use Brotli's dictionary, but the addressing is different -- each address takes ~4 bits more. Also, no transforms. Brotli addresses the words in the static dictionary by their dense ID, not by their position. Each distance,length-tuple gives a separate word.
|
|
|
|
VEG
|
2021-02-19 04:29:28
|
OK, clear. Thanks for the explanation.
|
|
|
|
member102
|
2021-02-19 10:32:03
|
Zstd encodes and decodes faster.
|
|
2021-02-19 10:33:06
|
There is a price to pay for the extra compression in Brotli ...
|
|
|
|
_wb_
|
2021-02-19 10:48:39
|
Doesn't matter much for exif/xmp metadata, and in any case speed is configurable and there is also an uncompressed option.
|
|
|
|
spider-mario
|
2021-02-19 10:53:35
|
brotli already decompresses very fast, faster than gzip for example
|
|
|
|
member102
|
2021-02-19 11:26:42
|
True, but statements like "zstd as a format compresses slower" are confusing at best. What matters is not the format but the end user. As for the claim about streaming, it is certainly true but I have yet to find a scenario where it matters.
|
|
|
|
Jyrki Alakuijala
|
2021-02-20 08:12:36
|
yes, we need to get our act together with brotli
|
|
2021-02-20 08:12:52
|
possibly copy over the lz77 engine from zstd there if we cannot improve it otherwise
|
|
2021-02-20 08:13:20
|
(if that is possible within the licenses of the projects, not sure about it)
|
|
2021-02-20 08:13:56
|
zstd has a large variety of parameters tweaked for different conditions
|
|
2021-02-20 08:14:30
|
for each quality it has 4 different input size categories, where brotli's current encoder only divides the input sizes into two classes
|
|
2021-02-20 08:15:12
|
zstd uses 128 MB window, where brotli stops at 16 MB even if it is not needed for br content encoding, people don't find the --large_window options
|
|
2021-02-20 08:15:31
|
brotli's hashing length is chosen smaller than zstd's
|
|
2021-02-20 08:16:14
|
for standardization purposes the format matters more than the current state of implementation
|
|
2021-02-20 08:16:38
|
of course I'm embarrassed of leaving brotli without improvements where zstd has been improved during the last 7 years
|
|
2021-02-20 08:17:18
|
on the other hand, we haven't been idling -- we have been busy with jpeg xl and our investment there has been likely more impactful than refining brotli
|
|
2021-02-20 08:19:18
|
(not only is the hashing length smaller, but zstd's hashing strategies in general are more flexible with the input length and the chosen speed, and the hashing strategy matters a *lot* for lz77 speed/efficiency)
|
|
|
member102
True, but statements like "zstd as a format compresses slower" are confusing at best. What matters is not the format but the end user. As for the claim about streaming, it is certainly true but I have yet to find a scenario where it matters.
|
|
2021-02-20 08:20:21
|
streaming matters a lot in a use case where the data is consumed while someone is waiting -- often there is another slower process such as ICC parsing or JavaScript parsing that is 15x slower than either Brotli or Zstd decompression
|
|
2021-02-20 08:21:02
|
if we can start that process earlier, it can finish earlier
|
|
2021-02-20 08:21:24
|
I don't know bcm and lily
|
|
2021-02-20 08:21:55
|
typically it is best to benchmark with the data and the environment that matters in the use case
|
|
2021-02-20 08:22:36
|
a human is about 1000x more expensive than a computer, and currently most cost in compression systems is coming where humans are waiting
|
|
|
|
fab
|
2021-02-20 08:23:03
|
lily by marcio pais new version is only for the coronavirus test but it did good also for texts
|
|
2021-02-20 08:23:29
|
bcm is by ily murakov he connected 2 weeks ago but he doesn't answer
|
|
|
|
Jyrki Alakuijala
|
2021-02-20 08:23:38
|
that is in practice for lossless compression http content decoding, apk decoding, and possibly other package installs to a lesser degree
|
|
2021-02-20 08:24:13
|
I don't think people should be testing with the coronavirus dna -- it is not representative data for those use cases that matter
|
|
|
|
fab
|
2021-02-20 08:24:14
|
bcm has like 2 gb in 600 mb i did
|
|
2021-02-20 08:24:20
|
and even more
|
|
2021-02-20 08:24:34
|
for some fonts it does 1:5 compression and superfast
|
|
|
|
Jyrki Alakuijala
|
2021-02-20 08:24:42
|
humans are rarely busy-waiting for a 2 GB load
|
|
|
|
fab
|
2021-02-20 08:24:44
|
italian text is efficient
|
|
|
|
Jyrki Alakuijala
|
2021-02-20 08:25:09
|
more often they busy wait for 50 kB or 200 kB, sometimes up to 10 MB of JavaScript
|
|
|
|
fab
|
2021-02-20 08:25:13
|
zstd is good with italian text
|
|
|
|
Jyrki Alakuijala
|
2021-02-20 08:25:48
|
give me a sample of Italian text < 1 MB where zstd wins over brotli
|
|
|
|
fab
|
2021-02-20 08:31:12
|
brotli i liked more on faster speed like speed 1 amd for fonts
|
|
|
|
Jyrki Alakuijala
|
2021-02-20 08:34:58
|
zstd caught up with brotli's faster compression speeds a few years ago already
|
|
2021-02-20 08:35:26
|
when they added the negative qualities or even a bit before
|
|
|
|
fab
|
2021-02-20 08:35:43
|
4,25 KB (4.357 byte) 7z brotli
7std 8,44 KB (8.648 byte)
|
|
|
|
Jyrki Alakuijala
|
2021-02-20 08:35:47
|
probably it would be a good idea to use the same lz77 encoder for both brotli and zstd
|
|
|
|
fab
|
2021-02-20 08:35:50
|
16 kb original
|
|
2021-02-20 08:36:04
|
but brotli i use ultra preset
|
|
|
|
Jyrki Alakuijala
|
2021-02-20 08:36:25
|
yes, brotli's qualities 1-9 have a lot of improvement potential
|
|
|
|
fab
|
2021-02-20 08:36:44
|
i had 860 mb vs 430 mb for fonts
|
|
|
|
Jyrki Alakuijala
|
2021-02-20 08:36:46
|
I think the last improvement I made there in 2016
|
|
|
|
fab
|
2021-02-20 08:36:52
|
i will try another time
|
|
|
|
Jyrki Alakuijala
|
2021-02-20 08:37:26
|
even if you turn off the static dictionary, brotli should win at quality 10 and 11 easily over any setting of zstd
|
|
|
|
fab
|
2021-02-20 08:38:22
|
brotli is way more efficient
|
|
2021-02-20 08:38:30
|
for the megapixel ales software GUI
|
|
2021-02-20 08:38:40
|
67 MB zstd speed 5 brotli is 36 mb
|
|
2021-02-20 08:41:05
|
40,9 mb deflate speed 5
|
|
2021-02-20 08:44:55
|
Fabian25/12/2020
do not USE BROTLI
7Z standard is double efficiency
at 6 mb/s
brotli also 4,4 mb/s
it starts 23 mb/s but it slows down
BROTLI
232 MB (244.310.601 byte)
7ZS 119 MB (124.810.175 byte) ZSTD
I compressed dictionaries
the paq ones
|
|
|
|
Jyrki Alakuijala
|
2021-02-20 08:57:16
|
for very large compression (especially with a lot of duplicates) one needs a very large window size
|
|
2021-02-20 08:57:28
|
ideally gigabytes of window
|
|
2021-02-20 08:57:46
|
however in practice -- outside of benchmarking -- we don't want to compress gigabytes at once
|
|
2021-02-20 08:58:37
|
we want to typically split the input into blocks that are compressed separately -- then when data degrades we don't lose all at once, also we can decode/transmit/etc it in parallel
|
|
2021-02-20 08:59:04
|
the largest production system window that I know is 256 MB
|
|
2021-02-20 08:59:40
|
and it is one without strict latency needs (a backup system)
|
|
|
|
Dr. Taco
|
2021-02-20 04:04:55
|
When JPEG officially accepts JPEG-XL and the standard stuff is all done. Will it be bumped from `0.3.x` to `1.x.x`
|
|
|
|
Scope
|
2021-02-20 04:09:45
|
<:Thonk:805904896879493180>
> WebP was first announced by Google on 30 September in **2010 **as a new open format for lossy compressed true-color graphics on the web
> The supporting libwebp library reached version **1.0** in April **2018**
|
|
2021-02-20 04:30:46
|
Jpeg XL will probably take less time to reach version 1.0, but I don't think it's worth the rush to raise the number to 1.0 without practical stability and implementation of all features
|
|
|
|
_wb_
|
2021-02-20 04:34:49
|
JPEG has done all it can to accept JPEG XL. It's now up to the national bodies of ISO to officially approve it — ANSI, DIN, and all of them.
|
|
|
|
Deleted User
|
|
Dr. Taco
When JPEG officially accepts JPEG-XL and the standard stuff is all done. Will it be bumped from `0.3.x` to `1.x.x`
|
|
2021-02-20 04:36:28
|
IIRC there will be yet another minor version, `0.4.x`, after full bitstream freeze:
https://docs.google.com/presentation/d/1LlmUR0Uoh4dgT3DjanLjhlXrk_5W2nJBDqDAMbhe8v8/edit#slide=id.ga0e56e11b0_0_8
|
|
|
|
_wb_
|
2021-02-20 04:38:57
|
That's when we have implemented all the exotic weird combinations the encoder is not using atm but the bitstream allows.
|
|
|
|
Deleted User
|
2021-02-20 05:07:17
|
E.g. thermal channel, depth channel, raw mosaiced sensor imagery etc.?
|
|
|
|
Crixis
|
2021-02-20 05:21:00
|
... spline, better patch
|
|
|
|
Jyrki Alakuijala
|
|
Scope
Jpeg XL will probably take less time to reach version 1.0, but I don't think it's worth the rush to raise the number to 1.0 without practical stability and implementation of all features
|
|
2021-02-20 05:22:02
|
I consider libwebp 0.2 or so could have been called 1.0, and 0.5-0.6 was more or less free of significant bugs even on encoder side
|
|
2021-02-20 05:22:58
|
of course the lossy quality ramp up was a bit late in webp lossy -- the early versions were too PSNR centric (blurry and pixelized)
|
|
|
|
Scope
|
2021-02-20 05:24:31
|
I also remember that WebP was much slower up to certain versions (especially lossless)
|
|
|
|
Jyrki Alakuijala
|
2021-02-20 05:26:45
|
the few next technical steps for the libjxl: improve android performance, improve memory use, add great APIs for progression, better HDR integration (possibly more a Chrome thing), improve quality of VarDCT at low bpp, continue on security hardening (there are simple tasks we didn't do yet, like using coverage tools to check the completeness of our fuzzing seeds)
|
|
|
|
Scope
|
2021-02-20 05:32:01
|
Major decoding speed optimizations that were planned for the near future have already been applied to desktop platforms?
https://i.imgur.com/y8hEp30.png
|
|
|
|
Deleted User
|
|
Crixis
... spline, better patch
|
|
2021-02-20 05:36:26
|
Encoder theoretically can use splines now because it has the code to remove them from images and encode into bitstream, it just can't detect them
|
|
2021-02-20 05:38:48
|
If you hard-code them before compilation (e.g. for testing purposes), feed spline parameters via command-line parameters and write the code to receive those parameters, or simply write spline heuristics, then *everything else* is ready. Decoder can decode bitstreams with spline data, too.
|
|
2021-02-20 05:42:12
|
Jon was probably talking about the features that both the encoder and decoder completely don't have yet. E.g. raw sensor imagery (before demosaicing) is possible with the bitstream, but the encoder can't encode it and (most importantly) decoder can't decode it.
|
|
2021-02-20 05:44:03
|
We're not at the full bitstream freeze, because if the 0.4 encoder could encode e.g. raw sensor data, current 0.3.2 encoder couldn't decode it at all. We only have "simple" format freeze (thing encoded by 0.2 encoder can be decoded by current 0.3.2 decoder and all later ones).
|
|
|
|
_wb_
|
|
Jyrki Alakuijala
I consider libwebp 0.2 or so could have been called 1.0, and 0.5-0.6 was more or less free of significant bugs even on encoder side
|
|
2021-02-20 05:50:35
|
Weren't there still bitstream changes after that point? I seem to remember animation bitstream changes
|
|
|
|
fab
|
2021-02-20 05:54:36
|
ziemek he said first 0.3.3
|
|
2021-02-20 05:54:44
|
0.4.0 end of march
|
|
2021-02-20 05:54:59
|
in the pdf there is written march 2021?
|
|
|
|
_wb_
|
2021-02-20 05:55:39
|
There are things we can do after 1.0, like extensions for Bayer data - provided we use an encoding that still gracefully decodes (e.g. put RGB in main image, have second G or W or whatever in an extra channel - accurate display requires demosaicing and metadata, but a naive decoder would just show a slightly inaccurate 1:2 image with ignored extra channel
|
|
2021-02-20 05:57:30
|
We still have to implement some blend modes the encoder isn't using, and maybe some combinations of upsampling/blending/noise that will cause the current decoder to say "not implemented yet"
|
|
2021-02-20 05:59:14
|
Nothing major, just stuff we haven't bothered to do yet because the encoder doesn't do it
|
|
2021-02-20 05:59:46
|
The main/tricky currently-unused things like splines etc are already implemented
|
|
|
|
Deleted User
|
|
fab
ziemek he said first 0.3.3
|
|
2021-02-20 06:03:15
|
I never wrote anything about 0.3.3 <:WhatThe:806133036059197491>
I was simply using version numbers as examples
|
|
|
|
lonjil
|
2021-02-20 06:20:37
|
What exactly is "JPEG-compatible Encoding" and is it any better than in terms of quality and size than exact JPEG transcoding?
|
|
|
|
_wb_
|
2021-02-20 06:25:20
|
We haven't really implemented it yet, but the idea is that if you start from pixels, you can encode a JPEG but e.g. also use XYB via a suitable icc profile, the epf, encode DC in a modular-friendly way, etc. So you get something that can still be represented as a JPEG, but it looks a bit better as a jxl (because of epf), and also compresses better as a jxl than an average old jpeg.
|
|
2021-02-20 06:26:42
|
So basically we could in principle make a jxl-aware Guetzli2 that could be useful in the transition period where lots of clients do not support jxl yet
|
|
|
|
lonjil
|
2021-02-20 06:26:56
|
Interesting!
|
|
|
|
Pieter
|
|
|
Scope
|
2021-02-20 06:43:18
|
``` --epf=-1..3
Edge preserving filter level (-1 = choose based on quality, default)```
|
|
|
|
Jyrki Alakuijala
|
2021-02-20 07:07:21
|
both 'gaborish' and epf improve the quality
|
|
2021-02-20 07:07:41
|
gaborish in a higher fidelity class than epf
|
|
2021-02-20 07:08:52
|
gaborish could be implemented on top of normal jpegs, too, at decoding time
|
|
2021-02-20 07:09:13
|
sharpen the quantization matrices a bit, blur after decoding
|
|
2021-02-20 07:09:29
|
I played with this idea at the time we developed knusperli and it works very well
|
|
2021-02-20 07:09:44
|
(for photographic content :-D)
|
|
|
190n
|
2021-02-20 07:54:59
|
i'm about to benchmark jpeg -> jxl lossless transcode on a bunch of photos from my phone, testing enc/dec speed and efficiency on various speed settings. right now my encoding command line is:
```
cjxl <input> <output> -s <speed> --num_threads=12
```
(my cpu is 6c/12t)
are there any additional "no-brainer" flags i should pass that will increase speed or efficiency? i can see various possible arguments in the help output but i'm guessing many don't apply to lossless jpeg conversion
|
|
|
|
_wb_
|
2021-02-20 07:55:43
|
Default is ok, not much point to do slower or faster for jpeg transcode imo
|
|
|
|
190n
|
2021-02-20 07:58:24
|
that's what i was seeing a little of testing on a single file, but i'll still probably try s3 through s8 just for fun. will finish overnight easily.
|
|