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

on-topic

Whatever else

fab
2021-03-17 07:47:58
why jpeg can't pay the people to write
2021-03-17 07:48:10
that is maybe because is not fully standardized?
Nova Aurora
2021-03-17 07:48:22
paid editing on wikipedia is frowned upon
BlueSwordM
2021-03-17 07:48:43
Also, we can probably do a better job than those paid editors. Paid editors may have a slight bias.
Nova Aurora
 BlueSwordM Also, we can probably do a better job than those paid editors. Paid editors may have a slight bias.
2021-03-17 07:49:00
*"slight"*
cucumber
 veluca the ARM NEON documentation isn't too bad, come on 😄
2021-03-17 07:49:07
SVE intrinsics and NEON intrinsics are on different pages, you can't filter them, after a search you have to go page by page to find what you want (but there are limited results per page), it's nearly impossible to ctrl-f descriptions on a per-page basis, etc
2021-03-17 07:49:15
i'm too spoiled by intel :(
veluca
2021-03-17 07:49:34
to be honest - still have to find a CPU that has SVE 😛
cucumber
 veluca to be honest, we didn't yet really figure out the CLA situation for this kind of contributions, so I'm not sure if it would be possible for you to help at this stage 😦
2021-03-17 07:49:37
aw!
2021-03-17 07:50:04
iirc only fujitsu has SVE support (and SVE alone kind of sucks, it's SVE2 that's great...and not really supported anywhere either!)
fab
2021-03-17 07:50:12
now jpeg xl italy article is first
2021-03-17 07:50:18
when you write jpeg xl for italians
veluca
2021-03-17 07:50:31
I suspect it will be a couple more weeks for the CLA situation to resolve itself
cucumber
2021-03-17 07:50:44
can't wait for that, then 😛
fab
2021-03-17 07:50:44
jpeg xl
veluca
2021-03-17 07:50:58
I think you can contribute to highway though, if that's your kind of thing 😛
cucumber
2021-03-17 07:51:33
what's wrong with highway?
veluca
2021-03-17 07:51:35
JPEG XL as it is is kinda hard to make faster (I've been trying for a while :P)
2021-03-17 07:52:06
some parts that are not really used today can of course be improved, it hasn't been a priority so far
cucumber
2021-03-17 07:52:41
in the same sense as "libaom as it is is kinda hard to make faster" (implying that a departure from the codebase could be vastly improved?)
veluca
2021-03-17 07:53:02
nothing wrong with highway, it's also from our team (used to be part of JPEG XL), but it's more low level than JXL
cucumber
2021-03-17 07:53:15
or in the sense that the coder physically cannot be faster without sacrifices or major algorithmic improvements?
Jyrki Alakuijala
 Scope I prefer minimalism and neutrality, colors and active text elements complicate scripting and logging output, I think this is a job for the GUI or other third party apps
2021-03-17 07:53:16
I'm already wound up from the two-line ASCII JXL logo in cjxl
veluca
 cucumber or in the sense that the coder physically cannot be faster without sacrifices or major algorithmic improvements?
2021-03-17 07:53:50
at least decoder-side, I think we are getting pretty close to the limits of what is possible
2021-03-17 07:54:18
(without sacrificing *something* at least)
cucumber
2021-03-17 07:54:32
thanks
Jyrki Alakuijala
 veluca at least decoder-side, I think we are getting pretty close to the limits of what is possible
2021-03-17 07:54:58
The basic rule of optimization: there is always 30 % more that could be done, but is just not worth it right now.
2021-03-17 07:55:35
I suspect we will be able to eventually use GPUs to help in decoding
2021-03-17 07:55:45
with ~2x speedup
veluca
2021-03-17 07:56:18
probably more 😛
Jyrki Alakuijala
2021-03-17 07:56:22
The difference between: https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_03_16/index.html#clovisfest&JXL=s&JXL=s&subset1 and https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_02_15/index.html#clovisfest&JXL=s&JXL=s&subset1 is delightful
_wb_
 Nova Aurora We don't have a galaxy brain emote in this server?
2021-03-17 08:31:32
You have the power to add emotes, you know that?
Nova Aurora
2021-03-17 08:31:50
<:galaxybrain:821831336372338729>
_wb_ You have the power to add emotes, you know that?
2021-03-17 08:32:09
I did
_wb_
2021-03-17 08:34:13
<:galaxybrain:821831336372338729>
Scope
2021-03-17 08:36:32
I also optimized emotes before adding and they are 6-12% more efficient, better, stronger
Nova Aurora
 Scope I also optimized emotes before adding and they are 6-12% more efficient, better, stronger
2021-03-17 08:37:38
diskorduser
2021-03-18 10:09:11
How do you guys batch convert jpg to jxl? When I tried gnu parallel it doesn't work properly. Some images left unconverted.
fab
2021-03-18 10:35:51
for %i in (C:\Users\User\Documents\LD\*.jpg) do cjxl "%i" "%i.jxl" -q 91.4 -s 9 -m -I 9.3 --num_threads=2
Eugene Vert
2021-03-18 10:35:54
`ls *.jpg | parallel 'cjxl {} ./jxl/{.}.jxl'` for light tasks and `ls *.jpg | parallel -j 1 'cjxl {} ./jxl/{.}.jxl'` for heavy ones works fine for me
fab
2021-03-18 10:35:56
copy this and edit
2021-03-18 10:36:04
for windows
2021-03-18 10:36:14
orum did
2021-03-18 10:36:58
the jxl developer said iterations 1 is the max
spider-mario
2021-03-18 10:58:56
odd that it wouldn’t work properly with parallel, in general it works for me
2021-03-18 10:59:29
``` parallel cjxl '{}' '{.}'.jxl ::: *.jpg ```
2021-03-18 10:59:58
this should work correctly regarding escaping and everything
2021-03-18 11:00:49
if you really must pipe the list of files to parallel, the safest option is `find ... -print0 | parallel -0`
2021-03-18 11:01:18
it separates the file names with `'\0'`, so your file names can even contain newlines and it still works
2021-03-18 11:02:28
(but that should also be true of the `::: *.jpg` option so the advantage is if you need the options that `find` provides)
fab
2021-03-18 11:04:09
parallel is for macs?
spider-mario
2021-03-18 11:09:55
I believe it works on macOS, but it’s also on Linux and Windows (through msys2)
diskorduser
2021-03-18 11:50:46
Thanks Eugene and mario.
Scope
2021-03-18 08:17:12
https://discord.com/channels/794206087879852103/822105409312653333/822200819914899477 Google Translate comments
2021-03-18 08:18:21
2021-03-18 08:18:46
2021-03-18 08:20:08
2021-03-18 08:21:18
2021-03-18 08:21:49
2021-03-18 08:23:19
2021-03-18 08:31:52
2021-03-18 08:34:45
2021-03-18 08:38:55
Nova Aurora
2021-03-18 08:39:44
JXL is patented, but so far all patents are free to use?
2021-03-18 08:40:06
They think this is JPEG2000?
Scope
2021-03-18 08:43:37
However, someone like Microsoft may be able to re-patent some free things (although I think it's mostly to protect themselves from the patent wars, but who knows)
_wb_
2021-03-18 08:54:31
There is no such thing as a guaranteed royalty-free codec that is less than 20 years old
2021-03-18 08:55:27
But with jxl we are pretty confident that it will in fact be royalty-free.
2021-03-18 08:58:49
Google and Cloudinary have patents related to jxl but that is a purely defensive thing. The Apache 2 license means that anyone gets a royalty-free patent grant for those patents, EXCEPT if you claim to have patents on jxl and sue people for it: in that case, you lose that grant.
2021-03-18 08:59:27
That makes it harder for patent trolls to do their thing.
zebefree
2021-03-18 09:00:15
But patent trolls don't sell products, so they don't need a license.
_wb_
2021-03-18 09:01:16
True, real trolls don't use the thing themselves which makes it harder to defend against them
Nova Aurora
2021-03-18 09:01:51
Good ol NPEs
BlueSwordM
2021-03-18 09:02:51
How would it make harder to defend against them though? Wouldn't that make it easier actually, since they're not even using their set of technologies?
Nova Aurora
 BlueSwordM How would it make harder to defend against them though? Wouldn't that make it easier actually, since they're not even using their set of technologies?
2021-03-18 09:04:12
Most patent protection operates on defensive termination, a nuclear option basically saying "If we can't use your patent, you can't use ours to make your own products"
BlueSwordM
2021-03-18 09:04:39
In that case, Google should just buy the patent trolls and shut them down. <:kekw:808717074305122316>
Nova Aurora
2021-03-18 09:04:43
Since NPEs (non-practicing entities, aka most patent trolls) don't make products, they care much less
Nova Aurora Most patent protection operates on defensive termination, a nuclear option basically saying "If we can't use your patent, you can't use ours to make your own products"
2021-03-18 09:10:52
This is also largely how vpx and av1 aren't as bullied as other codecs, MPEG LA would lose the patents controlled by AOM members
diskorduser
2021-03-20 05:56:57
Is there any filter or something which removes detail from images but keeps sharp lines / outlines like avif?
2021-03-20 05:58:03
Something like low fidelity & good appeal filter
improver
2021-03-20 06:08:30
waifu2x for anime but there are various cheaper things for sharpening/denoise (these are the terms you want to use for searching for that stuff)
_wb_
2021-03-20 06:46:44
A so-called bilateral filter also does something like that
2021-03-20 06:47:21
As well as the epf (edge-preserving filter) of jxl
veluca
2021-03-20 07:10:31
you could also do something like a selective gaussian (not too different from EPF), GIMP has it
BlueSwordM
 diskorduser Is there any filter or something which removes detail from images but keeps sharp lines / outlines like avif?
2021-03-20 07:15:21
FXAA <:Poggers:805392625934663710>
Crixis
2021-03-20 07:52:54
Make more strong epf option? (4-5)
2021-03-20 07:53:33
Or your test on this are bad?
veluca
2021-03-20 08:10:02
increasing the epf radius is *not* a good idea, with epf3 it's pretty slow already... but you can definitely increase the amount of smoothing encoder side
2021-03-20 08:10:16
but I'd just suggest doing image editing in GIMP and not with jxl 😛
Deleted User
2021-03-20 08:11:03
We've got enough of AVIF as a beauty filter <:kekw:808717074305122316>
Crixis
2021-03-20 09:18:49
I was thinking about anime but I trust core dev experience
_wb_
2021-03-20 09:25:26
You can always smooth as a preprocessing step instead of doing it as a postprocessing step in the decoder. If you have noisy/grainy images then denoising as a preprocessing step is a better idea than trying to let a compression codec do that
2021-03-20 09:29:41
For anime I think we should at some point try to detect cases where (part of) the image is better done with palette patches (or splines, if we can come up with an encoder for that)
Jyrki Alakuijala
2021-03-22 05:15:36
sometimes adding noise (especially Y noise) as a preprocessing step might be useful too -- it will work as a masking that heuristics in JPEG XL will take into account
2021-03-22 05:15:44
(purely a theoretical viewpoint)
2021-03-23 12:04:27
would be great if this MR saw some support with 777x👍 https://salsa.debian.org/debian/mime-support/-/merge_requests/6
Deleted User
 _wb_ You can always smooth as a preprocessing step instead of doing it as a postprocessing step in the decoder. If you have noisy/grainy images then denoising as a preprocessing step is a better idea than trying to let a compression codec do that
2021-03-23 02:48:55
Yup, I denoised one of my images in Topaz DeNoise AI and its quality improved. https://discord.com/channels/794206087879852103/803645746661425173/816197690693517353
2021-03-23 02:50:03
Instead of trying to encode the noise in the sky with small blocks, now it uses bigger blocks for flat sky areas and it uses those saved bits from the sky on the details in the forest.
2021-03-23 02:54:37
But there's another issue. When I re-enabled `--noise=1`, I discovered that the detected noise was so small it was barely visible (because, well, *I've just run this image through a freakin' denoiser!*).
2021-03-23 03:01:58
And guess what: I've got a solution. It'd look roughly like this: `cjxl denoised.png image.jxl --noise=noisy.png`.
2021-03-23 03:06:27
I suggest that the `--noise` parameter should be updated. Not only should it support `0` (no noise est.) and `1` (est. noise from input file) parameter values, but also filenames of original, non-denoised files. In that case the "main" input file will be used as an encoding source (as usual), but noise will be calculated from the difference between noisy original (supplied via `--noise`) and denoised encoding candidate (the "main" file).
2021-03-23 03:08:21
What do you think of that? That would solve the problem of noise estimation because instead of guessing it, you just need to calculate it from the difference between two images.
2021-03-23 03:14:05
I think you can simply do that already by placing a layer of custom noise above the denoised jxl.
2021-03-23 03:15:09
But I'm not sure if this makes any sense compared to just jusing the noisy original in the first place.
2021-03-23 03:19:45
Though it would be nice if the strength of --noise could be controlled.
But I'm not sure if this makes any sense compared to just jusing the noisy original in the first place.
2021-03-23 03:22:03
I'll quote my own message: > Instead of trying to encode the noise in the sky with small blocks, now it uses bigger blocks for flat sky areas and it uses those saved bits from the sky on the details in the forest. Noisy original is harder to encode, so I'm denoising it before encoding. I've just uploaded the original and now you'll see what I was talking about above.
2021-03-23 03:23:38
Yes, but if you want the noise back, then you have to spend new bits on the noise layer.
fab
2021-03-23 03:24:34
use -m -q 75.58 -P 9 -s 9
2021-03-23 03:24:43
on this image you have
2021-03-23 03:24:49
with 0.3.4
Deleted User
 Yes, but if you want the noise back, then you have to spend new bits on the noise layer.
2021-03-23 03:25:54
But you're talking about the noise layer and I assume you're talking about encoding that noise directly, as pixels. But I'm talking about artificial noise injection provided by JPEG XL (encoder estimates noise intensity, encodes it in the file, decoder gets that info and injects specified amount of noise).
fab
2021-03-23 03:25:57
you first need to convert to png
2021-03-23 03:26:09
jpeg xl will not do miracles with it
BlueSwordM
2021-03-23 03:26:21
Nah, what he wants to do is do it the same way aomenc does by default(which doesn't work well with video, but should work well with intra only images, especially with JXL) - Do the noise estimation. - Denoise conservatively. - Encode. - Add in the noise file/layer.
fab
2021-03-23 03:26:23
the thing it does is estimate a quality
2021-03-23 03:26:27
not estimate noise
2021-03-23 03:26:47
noise 1 don't do anything special than making a parameter a bit more
2021-03-23 03:26:59
/stronger
Deleted User
 fab not estimate noise
2021-03-23 03:28:09
I want to estimate noise, but not from denoised image (because it has no noise), but from the difference between noisy image and denoised image.
2021-03-23 03:45:17
Here is JXL encoded to 640k without denoising. Look at those small blocks in the sky, trying to preserve the noise but failing miserably. And look at the snow, being full of blocks. Ugh.
2021-03-23 03:48:37
And now look at the JXL with the same 640k filesize, but with denoising before encoding. The sky is now clear, so encoder makes use of that: it doesn't encode details there (because there are none) and uses big blocks. That means that areas at the bottom, with more details, can have more bits since the sky was encoded cheaply. The snow is no longer blocky and everything has more details. Nice.
2021-03-23 03:50:19
*(**note:** I had to re-encode those files to JPG on highest quality possible in order to fit just below Discord Free file limits, PNG files would be too big)*
2021-03-23 03:52:35
Open them in two separate browser tabs or, even better, load them both into GIMP as separate layers, flick between them two and enjoy the show 🙂
_wb_
2021-03-23 03:53:24
It might make sense to have an option to just adjust noise directly instead of letting the encoder estimate it...
Deleted User
2021-03-23 04:07:06
I don't feel competent enough to estimate noise from scratch in my images 😜
2021-03-23 04:08:10
I prefer the encoder to do its job and *maybe* tweak its estimates up or down if they're terribly off
_wb_
2021-03-23 04:23:12
the panaroma stitching has some white balance consistency issues in that image, half of the snow looks pink to me
Jyrki Alakuijala
 But there's another issue. When I re-enabled `--noise=1`, I discovered that the detected noise was so small it was barely visible (because, well, *I've just run this image through a freakin' denoiser!*).
2021-03-23 05:05:36
I believe noise should possibly related more to the quantization than just the noise present in the original
Here is JXL encoded to 640k without denoising. Look at those small blocks in the sky, trying to preserve the noise but failing miserably. And look at the snow, being full of blocks. Ugh.
2021-03-23 05:06:45
I have a problem in the 8x8 blocks and the 1,0 and 0,1 coefficients there -- need to fix it, there is occasionally 8x8 pixelization appearing today
2021-03-23 05:06:53
I'll fix it in 3 weeks
diskorduser
2021-03-25 10:58:20
Is cloudinary jxl encoding modular or vardct?
2021-03-25 11:00:48
If I use d_1 instead of q_xx in url, does it mean it's doing vardct?
_wb_
2021-03-25 11:18:04
it does vardct
2021-03-25 11:18:28
you cannot do d_1 in a cloudinary url, but q_90 is the same thing
diskorduser
2021-03-25 11:23:50
I'm using d_1 on cloudinary and it is doing something but the file size is smaller than q_90.
_wb_
2021-03-25 11:25:34
well your default quality is probably not q_90 but something else
2021-03-25 11:27:54
`d_` is an option to choose a default image (the image that gets sent as a placeholder in case of a 404 not found)
diskorduser
2021-03-25 02:58:02
<@!794205442175402004> https://discord.com/channels/794206087879852103/824000991891554375/824640084837531718 How do you convert these codes to jxl file? what is the procedure?
_wb_
2021-03-25 02:59:49
that's the input to `jxl_from_tree`
Master Of Zen
2021-03-29 05:18:24
There is a paper, on what is high resolution photo
2021-03-29 05:18:25
https://www.longwoods.com/articles/images/LW_AG_HighResPhoto.pdf
2021-03-29 05:18:57
And apparently high resolution photos made out of high resolution
Scope
2021-03-30 02:50:48
https://github.com/lucidrains/deep-daze
diskorduser
2021-03-31 06:32:05
https://github.com/ImageMagick/ImageMagick/discussions/3447 I saw this question. Does jxl support Lab colorspace?
lithium
2021-03-31 06:48:06
jpeg xl use XYB color space, i think we probably not necessary use Lab color space?
_wb_
2021-03-31 07:21:13
You could easily make a short icc profile that represents Lab, and use that in any codec. It makes more sense to do that for jxl than for 8-bit-only codecs like jpeg and webp.
2021-03-31 07:22:06
But for perceptual optimization, XYB is likely just as good as Lab, maybe better.
Deleted User
2021-03-31 11:35:14
Y'all probably know that image from Wikipedia, `Comparison_between_JPEG,_JPEG_2000_and_JPEG_XR.png`
2021-03-31 11:35:17
https://upload.wikimedia.org/wikipedia/commons/2/20/Comparison_between_JPEG%2C_JPEG_2000_and_JPEG_XR.png
2021-03-31 11:35:52
Well... I've made an update 😉 (not uploaded anywhere else yet) `Comparison_between_JPEG,_JPEG_2000,_JPEG_XR_and_JPEG_XL.png`
2021-03-31 11:36:00
diskorduser
2021-03-31 02:31:39
I want to test it with avif. Do you have source image?
Deleted User
2021-03-31 02:34:34
I've already done that 😜
2021-03-31 02:35:24
But you'll get the original anyway 😉
I've already done that 😜
2021-03-31 02:38:22
My AVIF encode was done with Squoosh, I haven't tested grain synth yet (that's possible in AV1 but I don't know about AVIF)
lithium
2021-03-31 04:51:32
Europe time April 1, will release jpeg xl 1.0?
_wb_
2021-03-31 04:55:11
That would be a joke
2021-03-31 04:55:31
Next milestone will be 0.4
Scope
2021-03-31 04:57:39
Jpeg XL renamed to AVIF
2021-03-31 05:00:34
Although, it's not a bad idea to rename the discord server for one day <:Thonk:805904896879493180>
Deleted User
 Scope Jpeg XL renamed to AVIF
2021-03-31 05:07:06
And AV1 server renames itself to JPEG XL
_wb_
2021-03-31 05:10:05
It's funnier if AV1 renames to VVC or something
Scope
2021-03-31 05:10:23
Yep
_wb_
2021-03-31 05:11:03
And this one maybe to some alternative silly name
2021-03-31 05:11:10
JPEG 2021
2021-03-31 05:11:17
JPEG 3000
2021-03-31 05:11:25
JPEG XP
2021-03-31 05:11:42
JPEG XXL
Scope
2021-03-31 05:12:23
JPEG MPEG
_wb_
2021-03-31 05:12:35
JpeG2
2021-03-31 05:13:37
DPEG XL, made by the disjoint photographic expert group
Scope
2021-03-31 05:15:36
Jpeg WebAVIF PXL 2
Deleted User
 Scope Jpeg WebAVIF PXL 2
2021-03-31 05:17:28
STOP, YOU'RE SUMMONING A DEMON <:monkaMega:809252622900789269>
_wb_
2021-03-31 05:24:40
HEIXL, with an obligatory 666-byte header that contains an elaborate and quite friendly greeting in UTF-16 in English, French, German, Spanish, Chinese, Japanese and Korean.
2021-03-31 05:25:15
https://c.tenor.com/fYSkC4_o9MgAAAAM/panic-at-the-disco-demon.gif
lithium
2021-03-31 05:26:18
jpeg 2077
zebefree
2021-03-31 05:26:39
Wrapped in a Flash container so that it can be viewed using the Adobe Flash plug-in
Jim
2021-03-31 05:36:57
Our AV1 can rename to AVI
Pieter
 Scope JPEG MPEG
2021-03-31 05:51:32
JPEG/5.0 (Joint Pictures Expert Group; ISO/IEC 10918) GIF/98a (PNG, like TIFF) AVIF/AOMedia1 WebP/2.0 JPEG/XL
fab
2021-03-31 06:39:57
Jay Peg Excel
Nova Aurora
2021-03-31 06:40:32
MPEG XL
Dr. Taco
2021-03-31 06:43:36
Microsoft Office XL
Nova Aurora
2021-03-31 06:45:23
AVCIF (Advanced Video Coding Image Format)
zebefree Wrapped in a Flash container so that it can be viewed using the Adobe Flash plug-in
2021-03-31 06:48:26
Don't forget to bundle decoder in the container, written entirely in https://esolangs.org/wiki/Piet
zebefree
2021-03-31 06:53:14
JPEG NFT: All images are stored on a blockchain, and have an owner and can be sold and traded! And the compression is amazing because every image will compress to a few bytes, i.e. the block number on the blockchain.
Nova Aurora
2021-03-31 06:54:11
And we only need a few exabytes to a store every image ever made!
Scope
2021-03-31 10:32:03
<:Hypers:808826266060193874>
spider-mario
 _wb_ JPEG XP
2021-04-01 10:50:45
followed by JPEG Vista
2021-04-01 10:50:58
oh, or JPEG Millenium?
2021-04-01 10:51:22
abbreviated as JPEG Me because it’s great for selfies
_wb_
2021-04-01 11:07:52
https://c.tenor.com/Yc4OxPwDj9MAAAAM/mr-bean-selfie-selfie.gif
Jyrki Alakuijala
2021-04-01 11:31:15
if you tweet that I'd like to retweet 😄
2021-04-01 12:10:47
JXL context mapping on arbitrary geometry: https://twitter.com/jyzg/status/1377594137990598664
Dr. Taco
2021-04-01 12:59:10
codename JPG Longhorn
Scope
2021-04-01 02:32:11
<@!794205442175402004> <@!532010383041363969> <@!493871605408071681> Also, it would be nice if the WebP team/eclipseo would add CLIC2020 datasets to their comparisons as well (they are free to use and already used by other Google teams) https://storage.googleapis.com/hific/clic2020/visualize.html https://storage.googleapis.com/hific/clic2020.zip
Jyrki Alakuijala
2021-04-01 02:34:04
I'll pass that request on
Scope
2021-04-01 02:39:18
I would also like to see some of the art/anime images, but I have not found any good free to use sets <:PepeSad:815718285877444619>
Jyrki Alakuijala
2021-04-01 02:42:20
Eclipseo's latest repo is used for every run of webp benchmark
2021-04-01 02:42:26
they don't want to change it
2021-04-01 02:43:19
Scope: if you can convince eclipseo, then you get the images automatically added
2021-04-01 02:43:44
I definitely would like to have a few fragments of anime there, too
2021-04-01 02:44:13
even when that is the worst kind of image we can have for JXL artefacts 😛
Scope
2021-04-01 02:48:24
Free images from Studio Ghibli might be a good candidate, if these high-quality sources were not low-quality Jpegs in reality <:SadOrange:806131742636507177>
Jyrki Alakuijala
2021-04-01 03:17:36
you only need 1-3 image for it
Deleted User
2021-04-01 03:20:18
I wonder which settings folks from Eclipseo use
2021-04-01 03:20:41
The first image from CLIC dataset would be especially useful for testing noise synthesis
2021-04-01 03:21:11
https://storage.googleapis.com/hific/clic2020/images/originals/00b64869422e0011ff5bb492e56042cc.png
2021-04-01 03:21:51
Am I right that noise synthesis is enabled by default in `cjxl`?
Scope
2021-04-01 03:21:52
https://eclipseo.github.io/image-comparison-web/report.html (mostly defaults)
2021-04-01 03:54:22
wp2 🤔 <http://compression.cc/leaderboard/image-150/valid/>
veluca
 Am I right that noise synthesis is enabled by default in `cjxl`?
2021-04-01 04:04:53
nope
fab
 Scope wp2 🤔 <http://compression.cc/leaderboard/image-150/valid/>
2021-04-01 05:20:47
when video and the image competitions ends? clic 2021?
Scope
2021-04-01 05:23:31
I don't know, I only searched there for image sets
2021-04-01 05:25:36
And it seems that WebP 2 already uses them for comparisons (if wp2 is not something else)
Deleted User
 veluca nope
2021-04-01 06:18:08
But it should be IMHO. With a small catch, though: if it's enabled not explicitly with `--noise=1`, but by default, it should clamp low noise estimates to zero, so if there's mixed content, e.g. text + photo, noise from the photo doesn't contaminate the text.
veluca
2021-04-01 06:29:34
The noise model is currently too slow on the decoder side for that to be on by default, unfortunately
2021-04-01 06:29:45
At some point we'll make it faster
Deleted User
 veluca The noise model is currently too slow on the decoder side for that to be on by default, unfortunately
2021-04-01 06:34:30
Maybe noise could be enabled by default, but disabled with `--faster_decoding` and/or on lower `-s` efforts (at least until decoder-side speed improvements arrive)?
veluca
2021-04-01 06:42:08
eh, it would need to be enabled at --faster_decoding=-10 at the moment xD
2021-04-01 06:48:44
mh, it's actually only 2x slower, I expected worse
Deleted User
2021-04-01 06:49:15
That's still quite huge.
2021-04-01 06:49:48
But worth it for gradients :)
_wb_
2021-04-01 06:58:35
For gradients?
2021-04-01 07:00:00
We need to do dithering at some point when converting to 8-bit, some gradients have subtle banding just because 8-bit is not quite enough
Scope
2021-04-01 08:40:34
Strange, these two CLIC 2020 data sets are different (with different images): `Training Dataset P ("professional") (1.9GB)` https://data.vision.ee.ethz.ch/cvl/clic/professional_train_2020.zip http://compression.cc/tasks/ `CLIC2020 dataset (6.3GB)` https://storage.googleapis.com/hific/clic2020.zip https://storage.googleapis.com/hific/clic2020/visualize.html
spider-mario
 _wb_ We need to do dithering at some point when converting to 8-bit, some gradients have subtle banding just because 8-bit is not quite enough
2021-04-01 09:00:48
I am a big fan of dithering
2021-04-01 09:02:27
https://www.aes.org/e-lib/browse.cfm?elib=4523 has a nice abstract
2021-04-01 09:02:46
misconceptions: **dispelled**
Deleted User
 _wb_ We need to do dithering at some point when converting to 8-bit, some gradients have subtle banding just because 8-bit is not quite enough
2021-04-02 01:29:42
Yes, but JXL can behave like a conversion to 6 or 7 bit.
2021-04-02 01:30:08
Little bit of banding:
2021-04-02 01:30:22
No banding:
2021-04-02 01:31:33
And the original was dithered. Here is a small part to see the dithering.
diskorduser
2021-04-03 07:15:33
Is the jpeg saved at 100 quality a suitable input for jxl var dct encoding? (not lossless transcode and source image is a developed DNG) or should I use only png/ppm for better jxl encodes?
fab
2021-04-03 07:20:42
jxl quality 100 is lossy
2021-04-03 07:20:48
jpg is only lossy
2021-04-03 07:20:57
jpg is always lossy
2021-04-03 07:21:16
there is a lossless mode, that uses like LOCO things
2021-04-03 07:21:27
but is not included in normal encoders
2021-04-03 07:21:34
and neither squoosh.app supports it
2021-04-03 07:25:39
it don't use loco loco is from jpeg ls if i remember right
2021-04-03 07:25:47
but maybe it was part 2 from jpeg
2021-04-03 07:25:53
i don't remember
diskorduser
2021-04-03 07:25:54
Does jpeg 100 lossy have artifacts which ruins jxl encodes? On which format should I export from Lightroom to further encode it to jxl?
fab
2021-04-03 07:26:07
only png even in topaz
2021-04-03 07:27:07
jpeg 100 you lose 18% of information at least visually
2021-04-03 07:27:31
png lossless will compress better for the size
2021-04-03 07:27:49
png has good lossless algorithm
diskorduser
2021-04-03 07:27:50
18% ? Even with yuv444/ no chroma sub sampling?
fab
2021-04-03 07:28:05
i read even more
2021-04-03 07:28:30
ask scope
2021-04-03 07:29:51
is the same if you encode in paint at jpg quality 100
2021-04-03 07:29:53
is just bad
2021-04-03 07:31:25
https://www.ephotozine.com/articles/jpeg-or-tiff-for-the-best-quality-prints--28996/images/Kayung%20saving%20size%20test%202.jpg
Pieter
 diskorduser Does jpeg 100 lossy have artifacts which ruins jxl encodes? On which format should I export from Lightroom to further encode it to jxl?
2021-04-03 07:31:28
Export to PNG, and then convert to JPEG-XL.
fab
2021-04-03 07:31:58
you can't avoid loss with JPG
Pieter
2021-04-03 07:32:15
JPEG even at 100% quality and no subsampling has losses due to YUV colorspace conversion.
2021-04-03 07:32:19
IIRC
diskorduser
 Pieter Export to PNG, and then convert to JPEG-XL.
2021-04-03 07:32:36
Okay
fab
2021-04-03 07:33:23
http://sequoiagrove.dk/images/jpeg_test/all.bmp
Pieter
2021-04-03 07:37:13
<@263309374775230465> Or do you have input that is more than 8-bit color depth?
diskorduser
 Pieter <@263309374775230465> Or do you have input that is more than 8-bit color depth?
2021-04-03 07:39:33
I think the dng is 10bit ( from smartphone camera)
Pieter
2021-04-03 07:41:11
Can you export at 16-bit PNG?
fab
2021-04-03 07:50:08
ah so topaz uses 8 bit png?
2021-04-03 07:50:25
i didn't know. i thought it used 12 bit or 16 bit png?
2021-04-03 07:50:38
i need an answer from user
improver
2021-04-03 08:19:24
png is always either 16 or 8 bit. iirc theres no 12 bit png
_wb_
2021-04-03 08:55:19
You can just pad the lsb to get to 16 bits. There is even a png chunk to indicate how many msb are significant, iirc.
Pieter
2021-04-03 08:57:37
Is there a way to tell cjxl that only 10 bits are significant?
_wb_
2021-04-03 09:04:07
Yes, --override_bitdepth 10, iirc
2021-04-03 09:04:31
Only really matters for lossless though
2021-04-03 09:05:40
(and does not make a big difference even for lossless, it will do a channel palette to reduce from 16 to 10 bits if only 2^10 values happen to be used in a channel)
diskorduser
 Pieter Can you export at 16-bit PNG?
2021-04-04 04:57:23
Sorry. Imagemagick identify says it's a 16bit dng.
2021-04-04 05:00:08
Image: Filename: IMG_20210404_084404.dng Format: DNG (Digital Negative) Class: DirectClass Geometry: 3472x4624+0+0 Units: Undefined Colorspace: sRGB Type: TrueColor Base type: Undefined Endianness: Undefined Depth: 16-bit Channel depth: Red: 16-bit Green: 16-bit Blue: 16-bit
Pieter
2021-04-04 05:00:43
Ok, and can you export it as a 16-bit PNG?
diskorduser
2021-04-04 05:04:10
Yes
Pieter
2021-04-05 07:18:32
<@794205442175402004> I remember you telling me about some change to the encoding (I think at the time of FUIF? when you were in Sunnyvale last) that permitted some level of parallellism when encoding or decoding across multiple leaves of the context tree. Do you remember that, and/or is that still the case?
_wb_
2021-04-05 07:19:41
That must have been when there was a JPEG meeting in San Jose
2021-04-05 07:20:16
I don't remember exactly what I was talking about then
2021-04-05 07:22:07
The parallelism is per group, since groups are encoded independently (they use separate ANS streams; can use the same MA trees and histograms though, group number is just a property that can be used in a MA tree)
Pieter
2021-04-05 07:22:40
I see.
_wb_
2021-04-05 07:22:40
default group size is 256x256 but in modular mode you can adjust it to 128x128, 512x512 or 1024x1024
Pieter
2021-04-05 07:23:03
That sounds vaguely like what I remember.
2021-04-05 07:23:16
But no parallellism per tree leaf. Perhaps I misremember.
_wb_
2021-04-05 07:23:18
for the jxl art it's usually max group size so everything is a single group
2021-04-05 07:23:27
the tree does get compacted
2021-04-05 07:23:40
<@!179701849576833024> wrote some nice speedups for that
2021-04-05 07:24:52
in the signalling it is just a tree, but then per group/channel it gets specialized (since group number and channel are constants then), and turned into a tree that inspects multiple properties at once and does less branching
Pieter
2021-04-05 07:27:39
Right, makes sense.
veluca
2021-04-05 07:52:20
in some cases we "compile" it down to a lookup table
2021-04-05 07:53:33
this is something that can certainly be done in *more* cases but figuring out the best tradeoff there is not quite easy (and I don't consider this to be on the critical path yet)
Pieter
2021-04-05 07:55:02
But all symbols within each group are in pixel/plane order still, not grouped per leaf?
2021-04-05 07:56:17
I believe what I recall <@!794205442175402004> b_ talking about was grouping per leaf or so.
2021-04-05 07:56:23
But I may misremember too.
veluca
2021-04-05 07:57:38
they are in the same order as always
2021-04-05 07:58:02
the "grouping per leaf" happens in the encoder to build the tree, but when the tree is used it's the simple way
Deleted User
2021-04-05 08:30:03
<@!794205442175402004> while I was looking for exact definition of Paeth, I stumbled upon this PNG file on a Wikipedia article about PNG.
2021-04-05 08:30:17
https://upload.wikimedia.org/wikipedia/commons/8/89/PNG-Gradient.png
2021-04-05 08:31:38
It's just 251 bytes and JPEG XL can't compress it better <:monkaMega:809252622900789269>
2021-04-05 08:31:53
`cjxl PNG-Gradient.png PNG-Gradient.jxl -m -s 9 -g 3 -E 3 -I 1 --palette=1024 -v`
2021-04-05 08:32:42
Jyrki Alakuijala
 fab jpeg 100 you lose 18% of information at least visually
2021-04-05 11:27:32
guetzli goes to 110
_wb_ <@!179701849576833024> wrote some nice speedups for that
2021-04-05 11:30:27
I didn't expect it possible
2021-04-05 11:31:32
Luca's optimization work brought up the idea that we can occasionally change the context trees into LUTs like I did in WebP lossless and Brotli
2021-04-05 11:32:08
We can just choose what are the common ways to codify contexts and make those as LUTs to get similar bulk decoding speeds
2021-04-05 11:32:35
it will require very special trees
Dr. Taco
2021-04-08 05:27:10
Since you can store font characters as tiles and position layers at different points on the canvas, all you need is a way to detect user interaction and you could build a game in a JXL file
monad
2021-04-08 08:31:26
JPEG XL, a next-gen image codec vying to replace JPEG, PNG, GIF, Unity, Unreal, and the Microsoft Windows operating system.
Crixis
2021-04-08 08:36:40
Lol
paperboyo
2021-04-08 09:59:30
https://www.coderelay.io/fontemon.html
Deleted User
2021-04-09 02:04:16
so basically flif is like gone and jpeg xl is the best lossless image compression alg?
2021-04-09 02:04:51
and it's like 1 0 0 % lossless
190n
2021-04-09 02:06:21
if you're in lossless mode yeah it is 100% lossless
Deleted User
2021-04-09 02:06:35
and is the first thing i said also true?
2021-04-09 02:07:00
obviously only accounting for what is publicy available right now
190n
2021-04-09 02:07:36
flif is superseded by jpeg xl
2021-04-09 02:07:49
it's probably the best lossless compression that has a chance of widespread adoption
Deleted User
2021-04-09 02:08:00
ok sick i want to use it for my search engine
2021-04-09 02:08:06
where is the source code?
2021-04-09 02:08:28
also what language is it implemented in, just curious
BlueSwordM
 where is the source code?
2021-04-09 02:08:35
https://gitlab.com/wg1/jpeg-xl Good luck using it in browsers with only Chromium Alpha supporting it behind a switch though
Deleted User
2021-04-09 02:08:54
kms
2021-04-09 02:08:59
forgot about that
2021-04-09 02:09:32
well i could just change the image format on the fly
2021-04-09 02:09:39
when serving the image although that would be taxing
Scope
2021-04-09 02:10:02
https://twitter.com/jyzg/status/1358023796247175169
Deleted User
2021-04-09 02:10:25
i mainly want to use this because i really don't have a lot of storage on my server, only 200gig potentially 700gig
2021-04-09 02:10:40
and it's a search engine so like a lot of stuff is indexed obviosuly lol
2021-04-09 02:10:57
AYYYYYYYYYYYY DAMN STRAIGHT IT'S IN C++
2021-04-09 02:11:06
C wouuuld be more alpha but
2021-04-09 02:11:10
still respectable
BlueSwordM
2021-04-09 02:12:21
Yeah. My idea would be: - mozjpg encoded JPG - Lossless WebP - Lossy JXL for everything else and lossless JXL for those lossless images, and you'll then wait.
Deleted User
2021-04-09 02:13:03
how big is the difference between lossy and lossless jpeg xl?
BlueSwordM
 how big is the difference between lossy and lossless jpeg xl?
2021-04-09 02:13:09
Quite large.
2021-04-09 02:13:36
For most images, JXL VarDCT(lossy) is usually 5-10x smaller than Modular lossless while being visually lossless.
Deleted User
2021-04-09 02:13:58
so there isn't like deep frying going on huh
BlueSwordM
2021-04-09 02:14:10
You can make it deep fry if you want, it's just *hard* vs other standards.
190n
 BlueSwordM Yeah. My idea would be: - mozjpg encoded JPG - Lossless WebP - Lossy JXL for everything else and lossless JXL for those lossless images, and you'll then wait.
2021-04-09 02:14:16
if you want to really flex, transcode all those jpegs losslessly to jxl and convert back to jpeg on the fly for old clients
Deleted User
2021-04-09 02:14:27
right but if i like choose a reasonable compression level
2021-04-09 02:14:28
right
2021-04-09 02:14:36
it'll look pretty much exactly the same
BlueSwordM
2021-04-09 02:14:41
If you choose a reasonable target, you won't be able to tell the difference yes.
Deleted User
2021-04-09 02:15:02
yeah and that is 5-10x smaller compared to lossless jpeg xl which is already way smaller than other formats correct?
BlueSwordM
2021-04-09 02:15:49
No, that's compared to lossless. Vs something like mozjpg in photographic images, the difference is usually 50-70% more efficient.
Deleted User
2021-04-09 02:16:05
yeah exactly that's what i said
2021-04-09 02:16:17
5-10x smaller when lossy compared to lossless xl
2021-04-09 02:16:38
or maybe that way of formulating it is stupid w/e
2021-04-09 02:16:38
well
2021-04-09 02:16:45
sounds fucking amazing i'll look into it
Scope
2021-04-09 02:16:52
It all depends on the required quality and also the type of images (some images will be better encoded in lossless mode)
BlueSwordM
2021-04-09 02:17:08
However, lossless does have many uses. For example, anything that is graphic won't get much smaller than lossy, and will usually look worse.
Deleted User
2021-04-09 02:17:26
wdym "that is graphic"
BlueSwordM
 wdym "that is graphic"
2021-04-09 02:17:33
Text for example.
2021-04-09 02:17:37
Normal screenshots, drawings, etc.
Deleted User
2021-04-09 02:18:18
right but when it comes to for example an anime girl or some shit right, then there is like a lot fo the same colors and not very much like detail ect so lossy will be a lot better
2021-04-09 02:18:46
again obviously depending on the image
2021-04-09 02:18:49
it's a vague question nvm
2021-04-09 02:19:30
oh yeah it's fine if i use this format commerically right?
BlueSwordM
2021-04-09 02:19:39
Absolutely.
2021-04-09 02:19:45
In fact, I'd recommend it.
2021-04-09 02:19:51
The more JXL usage, the better. <:YEP:808828808127971399>
Deleted User
2021-04-09 02:19:56
alright, i'll be sure to mention it in the technologies thingy
2021-04-09 02:19:59
under about
2021-04-09 02:20:01
or some shit
BlueSwordM
2021-04-09 02:20:56
In fact, if you could make a native JXL viewer on Android, that'd be pretty nice, just saying...
Deleted User
2021-04-09 02:21:25
what do you mean by native exactly?
BlueSwordM
 what do you mean by native exactly?
2021-04-09 02:21:46
Currently, there is no software that can decode JPEG-XL on Android natively.
2021-04-09 02:22:05
For example, you can't view JXL pictures in your gallery, or even your web browser.
Deleted User
2021-04-09 02:22:38
well i'm not an android developer exactly
2021-04-09 02:22:38
lol
2021-04-09 02:26:54
2021-04-09 02:26:55
damn
2021-04-09 02:26:56
this shit sucks
2021-04-09 02:27:57
stupid idea? can't you just make a webassembly program that renders the images in the browser?
2021-04-09 02:28:17
but holy fuck that would legitimately fuck all image tags
2021-04-09 02:28:27
...
username
2021-04-09 02:29:36
yeah a webassembly viewer could be made as a polyfill
2021-04-09 02:29:44
or something
Deleted User
2021-04-09 02:29:58
right but then you can't use `<img src="...`
2021-04-09 02:30:11
and that completely fucks everything
2021-04-09 02:31:05
whatever i'll just keep everything as jpeg xl in the server and create a cache of converted jpeg xl -> jpeg, if not cached it'll just convert on the fly
2021-04-09 02:31:34
why hasn't this been like implemented everywhere though i don't get it
BlueSwordM
 why hasn't this been like implemented everywhere though i don't get it
2021-04-09 02:32:24
The base standard has been finalized in January.
2021-04-09 02:32:28
Things take time to make. <:kekw:808717074305122316>
Deleted User
2021-04-09 02:32:45
NO FASTER
2021-04-09 02:32:48
BETTER FILE FORMATS
2021-04-09 02:32:50
NOWWWWWWWWWW
Crixis
2021-04-09 06:00:34
Squoosh use jxl wasm
fab
 NO FASTER
2021-04-09 06:18:41
-q 88.6 -s 6 -Y 4 -P 7 use with this https://ci.appveyor.com/project/EwoutH/jpeg-xl/builds/38612611 then wait for a better encoder and do with it -s 9 -q 44.2 --faster_decoding=3 if you want maximum savings these are the best options
2021-04-09 06:19:38
one could say that faster decoding makes worse quality, right but the encoder could be a lot better and introduce less artifacts
2021-04-09 06:19:44
probably will not happen
2021-04-09 06:20:40
so just do a generic command like -s 7 -q 75 -effort 3 like a chrome/squoosh developers said and not worry about, or use default speed 7 -d 1 or a -d 2
2021-04-09 06:21:39
at the moment is useless to encode at q 70 with jpeg xl, so if you really want to do, use distance and a raw file converted to png (not overly processed)
_wb_
2021-04-09 02:08:47
<@!792428046497611796> could a wikipedia page be made about Jyrki Alakuijala? He's mentioned in https://en.wikipedia.org/wiki/Brotli, https://en.wikipedia.org/wiki/WebP, https://en.wikipedia.org/wiki/Zopfli, https://en.wikipedia.org/wiki/Guetzli, and should probably be mentioned in the jxl article too...
2021-04-09 02:12:44
I'm not sure what the threshold is to make a page about someone or how it gets decided, but it seems like it would make sense for jyrki to get a wikipedia article 🙂
Deleted User
2021-04-09 02:35:59
<@424295816929345538> <@416586441058025472> oh it already exists? I was going to write it myself loool
2021-04-09 03:27:24
oh yeah btw sorry for being lazy and asking but how do i build for webassembly?
2021-04-09 03:28:24
ooor nevermind
2021-04-09 03:29:17
but the webassembly bit in the gitlab is a image viewer correct? or is it for encoding and decoding?
2021-04-09 03:30:21
well or if it's a decoder i could actually just decode to png then update actual src tags with decoded as png
_wb_
2021-04-09 03:38:12
that's not very efficient
2021-04-09 03:38:23
png encoding is likely slower than jxl decoding 🙂
Deleted User
2021-04-09 03:44:48
of course but i will have to make some sort of tradeoff between being able to use this formate for filesystem savings and computing power converting between formats
2021-04-09 03:44:52
although
2021-04-09 03:44:53
...
2021-04-09 03:45:15
it is getting encoded and decoded / whatever on the client side javascript so that does not impact my server
2021-04-09 03:45:16
looooooooool
2021-04-09 03:45:37
or well more spesifically client side "webassembly"
2021-04-09 03:46:16
still, i'm still not sure, is the webassembly bit in the gitlab a encoder/decoder or is it a jpeg image viewer?
2021-04-09 03:46:27
<@!794205442175402004>
2021-04-09 03:47:40
like does it just decode to png or does it decode to raw rgb which can be put in a canvas or somethin
_wb_
2021-04-09 03:47:47
I think you can compile the whole thing with wasm if you want, but what makes most sense is to just decode to pixels
Deleted User
2021-04-09 03:48:05
yeah no but there is a a webassembly compiler flag
2021-04-09 03:48:10
in the cmakelists no?
_wb_
2021-04-09 03:48:18
i haven't actually tried it myself yet
2021-04-09 03:49:04
if you just want a wasm decoder, you can probably just take the one from squoosh or from https://jxl-art.surma.technology/
Deleted User
2021-04-09 03:50:13
wait wtf is that, is that like a graphics shader type of program in the top?
2021-04-09 03:50:44
``` if W-NW > -1 if NW-N > -1 if N > 254 - Set 0 if y > 0 - W + 1 if x > 0 - W + 1 - Set 0 - NW + 0 - Select + 1 ```
2021-04-09 03:50:45
this thing
2021-04-09 03:53:59
but yeah thanks <@!794205442175402004> i'll just use that then
2021-04-09 03:55:21
also the slow loading time is surely only because you are running that shader type program first right?
veluca
2021-04-09 04:24:54
the decoder actually runs that "shader program" (but it's not *that* slow)
fab
 <@424295816929345538> <@416586441058025472> oh it already exists? I was going to write it myself loool
2021-04-09 04:36:07
no is only for chrome canary and you have to set chrome:flags in enabled; a simple integration with the library is not that hard to do getting progressive decode, animation, color management, HDR, alpha blending etc etc to work correctly is something else; this jon said
2021-04-09 04:38:59
to have jxl decoding
Deleted User
2021-04-09 04:39:03
<@416586441058025472> what do you mean only google canary, I'm talking about a wasm decoding
2021-04-09 04:39:14
That will work on every browser that supports wasm
fab
2021-04-09 04:39:17
maybe you meant about the encoder
Deleted User
2021-04-09 04:39:23
No
fab
2021-04-09 04:39:24
i do not how to build with wasm
2021-04-09 04:39:38
those were builds by ewout with appveyor for arch64 windows
Deleted User
2021-04-09 04:39:50
No the wasm thing is supported on every major browser
fab
2021-04-09 04:39:54
also scope and jamaika in doom9 sometimes there are
2021-04-09 04:40:02
wasm is also on squoosh.app
_wb_
 also the slow loading time is surely only because you are running that shader type program first right?
2021-04-09 04:40:46
It's mostly slow because it is first doing a wasm encode in a rather inefficient way. The wasm decode shouldn't be that slow.
Deleted User
2021-04-09 04:41:39
Yeah exactly that's sorta what i thought
veluca
2021-04-09 04:43:42
the sources of squoosh.app are available on github if you want to take whatever they do to get a wasm decoder
2021-04-09 04:44:06
I'm afraid web is not really (or rather, really not :P) my area of expertise 😛
Deleted User
2021-04-09 04:44:54
Yeah no I'll figure it out rather quickly
2021-04-09 04:45:00
I've done wasm before
veluca
2021-04-09 04:45:36
I know we have wasm builds in our CI
fab
2021-04-09 04:45:55
searching jjyri alaiku, jyri alakuijala
veluca
2021-04-09 04:45:58
not quite sure *what* they build
_wb_
2021-04-10 01:50:30
So what are all the pronunciation options?
fab
2021-04-10 01:51:06
punto gekisele punto jota - ekisele dot da. jEiExEl punto gei ix ell
2021-04-10 01:51:22
Either djixel or yixel, I guess (jon wb)
2021-04-10 01:52:35
to be sure ell is wrong in italian should be Elle
2021-04-10 01:53:49
but imagine something like this
2021-04-10 01:53:50
dʒejiksselle
2021-04-10 01:54:01
done with this
2021-04-10 01:54:02
https://easypronunciation.com/en/italian-phonetic-transcription-converter
2021-04-10 01:54:08
is horripilant
2021-04-10 01:54:37
just make similar pronunciation italian and english like i suggested
2021-04-10 01:55:04
punto giksel
2021-04-10 01:55:12
it seems like an auto company
2021-04-10 01:55:17
punto is a car in italian
2021-04-10 01:55:40
fiat punto
2021-04-10 01:59:08
ʤeɪ-ɛks-ɛl english Jay - X - L
2021-04-10 02:03:06
british hasn't open E
2021-04-10 02:03:15
as i learned in internet
_wb_
2021-04-10 02:03:39
Maybe it's j'excelle at lossless or d ≤ 1, yixel at 1 < d < 4, and yucksel at d ≥ 4?
fab
2021-04-10 02:06:57
in french sounds much better
2021-04-10 02:07:16
in italian sounds like a bunch of sillables
2021-04-10 02:12:08
tried
2021-04-10 02:44:20
2021-04-10 02:44:32
2021-04-10 02:45:24
the intonation is bad
2021-04-10 02:45:51
ja peg . jei ix elle 0:31
2021-04-10 02:46:17
only two sillab i said
2021-04-10 02:46:26
https://discord.com/channels/794206087879852103/794206087879852106/830453153446756432
2021-04-10 02:46:32
this is how i say in english
2021-04-10 02:47:03
i fatigued to say in english correctly JPEG
2021-04-10 02:48:13
THIS IS HILARIOUS
2021-04-10 02:55:09
JAY Iɪ XCELLE
2021-04-10 02:55:16
like a name of pope
2021-04-10 02:55:37
a true italian person will say the name not with a flat intonation and true syllable like i said
2021-04-10 02:55:53
but like is a name of pope and with the e as open as possible
2021-04-10 02:56:14
you have to exagerate the pronunciation
2021-04-10 02:56:16
and make gestures
2021-04-10 02:56:29
like Matteo renzi when it does shish
2021-04-10 02:57:09
The other pronunciation are right
2021-04-10 02:57:24
JAPAN FRENCH AND BRITISH/AM are alright
2021-04-10 02:57:47
but of course we can do better
2021-04-10 02:58:00
(matt simons)
2021-04-10 02:59:09
Talking aboutr the song, the video in av1 has target VMAF
2021-04-10 03:01:52
at least is the first video i have seen target vmaf
2021-04-10 03:02:06
at 480p is noticeable
Pieter
 _wb_ Maybe it's j'excelle at lossless or d ≤ 1, yixel at 1 < d < 4, and yucksel at d ≥ 4?
2021-04-10 03:32:37
should be like the Dutch "jeuksel"
_wb_
2021-04-10 03:34:24
Jeuksel in j'oksel
raysar
2021-04-10 07:22:55
We need to ask an artist to create the jixel song 😄
_wb_
2021-04-10 07:29:02
The jixel jingle
Jyrki Alakuijala
2021-04-11 12:28:59
I started a wikipedia article draft for Dr. Jon Sneyers: https://en.wikipedia.org/wiki/Draft:Jon_Sneyers
jzxf
2021-04-11 01:53:14
I hope this isn't too dumb of a question, but where do I go to see the actual in-progress format, the specification documents, and so on? I see the code in the reference application but my understanding is that there's a multipart standard being worked on; where is that located?
_wb_
2021-04-11 02:26:34
https://www.iso.org/standard/77977.html
2021-04-11 02:27:19
But there's ISO's paywall, plus they only have the DIS version since the FDIS still needs to be formally approved
2021-04-11 02:27:39
And there are big differences between DIS and FDIS
jzxf
 _wb_ But there's ISO's paywall, plus they only have the DIS version since the FDIS still needs to be formally approved
2021-04-11 02:38:43
Do you think it makes sense to wait for the FDIS version to be published, then?
_wb_
2021-04-11 02:39:55
Yes
veluca
2021-04-11 03:15:24
*especially* if we find a way to publish the standard openly...
raysar
2021-04-11 04:14:17
what is the risk if the document is hacked? 😄
Deleted User
2021-04-11 05:24:46
I'm not suggesting making a fundraiser for a digital version, copying all the text to Word, re-doing the formatting from scratch and then sharing the whole file on torrents, because that's way too risky, illegal and immoral.
2021-04-11 05:26:11
I definitely won't do this, because Slavic countries, including Poland, are especially known from obeying and protecting intellectual property laws. <@!826537092669767691> can confirm.