|
fab
|
2021-02-25 01:37:01
|
it uses distance 1
|
|
2021-02-25 01:37:11
|
that's something wrong in the command
|
|
2021-02-25 01:42:01
|
ziemek try the command
|
|
2021-02-25 01:47:55
|
is doing
|
|
2021-02-25 01:47:59
|
for %i in (C:\Users\User\Documents\png3\*.png) do cjxl "%i" "%i.jxl" -m -q 94 -s 4 --lossy-palette --palette=0 --colorspace=1 --group-size=1 --predictor=8 --num_threads=2
|
|
2021-02-25 01:48:25
|
very slow i don't know why
|
|
2021-02-25 01:48:45
|
but if the quality is good i can take
|
|
2021-02-25 01:49:58
|
is not encoding
|
|
2021-02-25 01:50:18
|
did big file 2 mb file
|
|
2021-02-25 01:59:28
|
5 photos in 8 mpx in 11 minutes
|
|
2021-02-25 02:13:27
|
with a pdf even the resulting png inflates even converted with xnview in PNG
|
|
2021-02-25 02:13:38
|
from 700 kb to 5,8 MB
|
|
2021-02-25 02:23:23
|
THE problem is not good with album art as it inflates file size
|
|
|
_wb_
|
2021-02-25 02:26:57
|
You are trying interesting combinations of options, no idea what that will do but it is likely going to be really bad for compression
|
|
|
|
fab
|
2021-02-25 02:37:08
|
maybe my eyes have loss of sharpness
|
|
2021-02-25 02:37:21
|
of are in different colour space and i'm editing the image
|
|
2021-02-25 02:37:30
|
but right compression is bad
|
|
2021-02-25 02:38:04
|
maybe i'm too used to jpeg xl
|
|
|
|
Deleted User
|
|
fab
for %i in (C:\Users\User\Documents\png3\*.png) do cjxl "%i" "%i.jxl" -m -q 94 -s 4 --lossy-palette --palette=0 --colorspace=1 --group-size=1 --predictor=8 --num_threads=2
|
|
2021-02-25 02:58:06
|
If you decide to override some defaults, please make sure that it'll be useful for that particular image. And please, use shorter versions of switches where available (for example `-P 8` instead of `--predictor=8`).
|
|
|
|
fab
|
2021-02-25 03:03:29
|
thanks
|
|
2021-02-25 03:03:47
|
you are since many time in av1 server
|
|
2021-02-25 04:01:59
|
resampling 2 does make resolution 2 times less?
|
|
2021-02-25 04:02:17
|
what it does? is there a similar settings in avifenc?
|
|
2021-02-25 04:10:43
|
https://discord.com/channels/794206087879852103/794206170445119489/814398210163343370
|
|
|
|
Deleted User
|
|
fab
resampling 2 does make resolution 2 times less?
|
|
2021-02-25 04:11:06
|
``` --resampling=1|2|4|8
Subsample all color channels by this factor```
Yes, it downscales the image.
And no offence, but I already wrote that and I'll write that again: `cjxl -h -v -v -v` will list you all available encoder options **and their short descriptions**. You can ask a question if an option is so advanced that short description isn't enough to describe it fully.
|
|
|
|
fab
|
2021-02-25 04:13:16
|
i did cjxl -h -v -v
|
|
|
|
Deleted User
|
2021-02-25 04:13:40
|
https://tenor.com/view/yoda-there-is-another-star-wars-jedi-gif-5140031
|
|
|
fab
i did cjxl -h -v -v
|
|
2021-02-25 04:14:23
|
You need level 3 of verbosity (3 * `-v`), not 2.
|
|
|
|
fab
|
2021-02-25 04:14:44
|
but to me resolution looks the same
|
|
2021-02-25 04:14:50
|
i don't see less pixels
|
|
2021-02-25 04:15:07
|
at least with images from reddit
|
|
2021-02-25 04:16:20
|
maybe is the modular who is doing well for those images
|
|
2021-02-25 04:16:51
|
what it means Subsample all color channels by this factor
|
|
|
|
_wb_
|
2021-02-25 04:17:03
|
the encoder subsamples, the decoder will upsample again
|
|
|
|
fab
|
2021-02-25 04:17:04
|
like a blue and a similar color green
|
|
2021-02-25 04:17:25
|
ok
|
|
2021-02-25 04:17:39
|
like 4:4:4
|
|
|
|
Deleted User
|
|
fab
at least with images from reddit
|
|
2021-02-25 04:17:41
|
Can I see those images?
|
|
|
|
fab
|
|
|
Deleted User
|
2021-02-25 04:18:24
|
ยฏ\\\_(ใ)_/ยฏ
|
|
|
|
fab
|
2021-02-25 04:18:26
|
has webp2 the same setting?
|
|
2021-02-25 04:18:40
|
ok
|
|
2021-02-25 04:19:38
|
i will try to customize the parameter first i want to convert
|
|
2021-02-25 04:20:41
|
so it's speed 4 but with these you have half resolution, or is half resolution like different chroma subsampling and then upscaled?
|
|
2021-02-25 04:21:09
|
i don't work in video encoding so i don't know
|
|
2021-02-25 04:28:40
|
ziemek is that command right?
|
|
2021-02-25 04:28:41
|
for %i in (F:\sober\jxl\*.jxl) do djxl "%i" "%i.jxl" --num_threads=2
|
|
2021-02-25 04:29:05
|
ah i should change to png
|
|
2021-02-25 04:29:06
|
trying
|
|
2021-02-25 04:29:23
|
is doing
|
|
|
666666t
|
2021-02-25 10:53:34
|
oof
tried building a newer build of libjxl cause still not exactly packaged my my distro or anything and cmake failed cause i don't have libavif
unfortunately, my distro apparently also doesn't package libavif so i have to build *that* now too :p
|
|
|
Jyrki Alakuijala
|
2021-02-25 10:53:38
|
Good news: I'm about to make a pretty significant improvement on the low bpp now, perhaps 5-10 % (including this kind of anime images, I suppose)
|
|
2021-02-25 10:54:24
|
the main idea is very simple -- currently, when we try out larger transforms, we take the maximum adaptive quantization of the respective area
|
|
2021-02-25 10:54:59
|
I just compute that with a p-norm (with p 4 or 8), and the compromises for large transforms are less strict
|
|
2021-02-25 10:55:11
|
so we get a lot more large transforms
|
|
2021-02-25 10:55:38
|
I have some remaining bugs that cause ringing in some places, but probably can fix it in a day
|
|
2021-02-25 10:56:48
|
(I believe I will need to make 2-3 other similar improvements to get all the way to AVIF category in low bpp performance -- but I have many ideas in storage)
|
|
|
Scope
|
2021-02-25 11:06:44
|
Also, I tried a little `tune=butteraugli`, but through heifenc (maybe this is a heifenc bug), but something happens with colors (eye, face)
Source:
|
|
|
spider-mario
|
|
666666t
oof
tried building a newer build of libjxl cause still not exactly packaged my my distro or anything and cmake failed cause i don't have libavif
unfortunately, my distro apparently also doesn't package libavif so i have to build *that* now too :p
|
|
2021-02-25 11:06:57
|
libavif should be optional; if it isnโt, I messed up something
|
|
|
|
Scope
|
2021-02-25 11:07:10
|
tune=ssim
|
|
2021-02-25 11:07:28
|
tune=butteraugli
|
|
|
BlueSwordM
|
2021-02-25 11:07:47
|
How did you get tune butteraugli working Scope?
|
|
2021-02-25 11:08:11
|
I didn't manage to get it working without patching the CMakelists.txt in aomenc, which made the encoder much slower even while not use the tune.
|
|
|
|
Scope
|
2021-02-25 11:08:40
|
<https://forum.doom9.org/showpost.php?p=1936737&postcount=396>
|
|
|
|
666666t
|
2021-02-25 11:08:41
|
~~heck, looking at it again, there actually are a couple other cmake errors that show up at the start, though it only stops right after the "could not find libavif" bit so not sure~~
|
|
2021-02-25 11:08:49
|
cmake is not my strong pointt ๐
|
|
2021-02-25 11:09:13
|
|
|
|
|
spider-mario
|
2021-02-25 11:09:40
|
looks like the actual error is in highway, but thatโs strange too
|
|
2021-02-25 11:09:51
|
let me check what is on that line 172
|
|
2021-02-25 11:10:24
|
hm, itโs the step that generates the pkgconfig file
|
|
|
|
666666t
|
|
|
spider-mario
|
2021-02-25 11:11:05
|
an โoperation not permittedโ for that sounds weird, I am not sure what could cause that
|
|
2021-02-25 11:11:43
|
my first suspicion would be cmake not being able to write somewhere, but apparently itโs able to write to CMakeFiles/CMake{Output,Error}.log, soโฆ
|
|
|
|
veluca
|
2021-02-25 11:12:51
|
weird things (tm) happen when you have a folder where cmake wants to create a file - maybe it's that
|
|
|
|
666666t
|
2021-02-25 11:13:42
|
maybe
could always try re-cloning the repo and see if cleaning things up like that somehow changes something
|
|
2021-02-25 11:14:07
|
|
|
2021-02-25 11:14:07
|
*woah*
how'd those get in there
|
|
|
|
spider-mario
|
2021-02-25 11:14:46
|
especially, why does it not have permission to remove them
|
|
|
|
666666t
|
2021-02-25 11:14:52
|
~~sudo time~~
|
|
2021-02-25 11:15:17
|
that might explain something, maybe re-cloning is the right way to go :p
|
|
|
|
spider-mario
|
2021-02-25 11:16:35
|
the one time I was almost going to reinstall my arch linux involved some messed up permissions :p
|
|
2021-02-25 11:17:02
|
I had an odd mixture of permissions and owners in my $HOME and wanted to clean that up
|
|
2021-02-25 11:17:20
|
so I ran some `sudo chmod -R` on my $HOME
|
|
|
|
666666t
|
|
|
spider-mario
|
2021-02-25 11:17:41
|
except, `~/.wine` had a symbolic link from z: to /
|
|
|
|
666666t
|
2021-02-25 11:17:45
|
o p e
|
|
|
|
spider-mario
|
2021-02-25 11:17:55
|
which was followed, but just one level (not recursively)
|
|
2021-02-25 11:18:19
|
so it changed the permissions of / itself, but none of the subdirectories (/usr, /etcโฆ)
|
|
|
|
666666t
|
2021-02-25 11:18:34
|
honestly
biggest permissions mess i've ever had to unravel on my system
two words
`sudo pip`
|
|
|
|
spider-mario
|
2021-02-25 11:18:38
|
so the problem was only apparent with `ls -ld /` or `stat /`, not `ls -l /`
|
|
|
|
666666t
|
2021-02-25 11:18:58
|
oof, wack
|
|
2021-02-25 11:27:06
|
ayy, redownloading the repo worked just fine, thank gods :p
|
|
|
|
veluca
|
2021-02-25 11:33:42
|
the worst system mess-up I actually managed to recover from was when I overwrote part of / on an arch install with an arch install for another architecture xD
|
|
|
|
Jyrki Alakuijala
|
2021-02-25 11:53:02
|
what is the lowest distance in VarDCT where AVIF can produce better quality on these anime pics?
|
|
|
|
Scope
|
2021-02-25 11:55:22
|
Depends on the image, I mostly encoded with `avifenc --min 0 --max 30 - 50` , and then the same size with JXL
|
|
2021-02-25 11:59:27
|
Did a little testing, it's roughly `-d 2.5 ... -d 8`
|
|
|
|
Jyrki Alakuijala
|
2021-02-26 12:11:46
|
thank you
|
|
2021-02-26 12:12:24
|
I'll focus the testing around d3 and d5 for now
|
|
2021-02-26 12:13:11
|
what are the exact flags you use with cjxl ?
|
|
2021-02-26 12:15:18
|
similarly interesting what kind of BPP you get with these distances
|
|
|
|
Scope
|
2021-02-26 12:15:42
|
`-s 8 --target_size=x`
|
|
|
|
Jyrki Alakuijala
|
2021-02-26 12:15:43
|
I'm wondering if we overinvest in the DC precision on images where there is not so much AC information
|
|
2021-02-26 12:16:10
|
did you try with progressive dc ?
|
|
|
|
Scope
|
|
|
Jyrki Alakuijala
|
2021-02-26 12:17:57
|
if you feel courageous, you could try looking for kDcQuant and change it
|
|
2021-02-26 12:18:25
|
it is a constant in encoder
|
|
2021-02-26 12:18:44
|
together with progressive dc we can have higher values for dc quantization
|
|
2021-02-26 12:19:07
|
usually we don't need to be careful with it because the photos are a lot of AC info, but perhaps these drawings have less AC bits
|
|
2021-02-26 12:19:24
|
I think it is 1.12
|
|
2021-02-26 12:19:43
|
you can try 0.9 and 1.35 and see what happens
|
|
2021-02-26 12:19:59
|
probably nothing much
|
|
2021-02-26 12:20:43
|
but if it improves the situation, it would be great
|
|
2021-02-26 12:21:09
|
I believe that JXL uses more bits for dc than other codecs especially in low quality
|
|
2021-02-26 12:21:30
|
this constant (and the related heuristics) govern it
|
|
|
|
Scope
|
2021-02-26 12:21:31
|
Now I'm trying to encode these images with -d 3, 4, 5 and see where the noticeable jagged lines are (this is the main thing that visually annoys people in these images)
|
|
|
|
Jyrki Alakuijala
|
2021-02-26 12:21:54
|
yes, this is the main thing I'm committed to fixing ๐
|
|
|
|
Scope
|
2021-02-26 12:24:43
|
And AVIF can handle it well (it removes detail, but it's not as noticeable and annoying, especially for previews)
|
|
2021-02-26 12:25:44
|
-d 3
|
|
2021-02-26 12:26:40
|
-d 4
|
|
2021-02-26 12:27:09
|
-d 5
|
|
2021-02-26 12:27:53
|
Noticeable from -d 3 and higher
|
|
2021-02-26 12:28:56
|
-d 3
|
|
2021-02-26 12:29:12
|
-d 5
|
|
2021-02-26 12:30:08
|
-d 3
|
|
2021-02-26 12:30:19
|
-d 5
|
|
2021-02-26 12:31:12
|
(upper part, glasses)
|
|
|
|
Jyrki Alakuijala
|
|
Scope
And AVIF can handle it well (it removes detail, but it's not as noticeable and annoying, especially for previews)
|
|
2021-02-26 12:34:05
|
Yes, I acknowledge this and observe the same thing. I hope to reduce the gap on this kind of material. I am not sure if we can completely close it. AVIF's and JPEG XL's filtering and prediction are different, and they have different benefits. I consider that the main difference today is JPEG XL favoring smaller integral transforms, which do not interpolate geometry as well as larger transforms.
|
|
2021-02-26 12:35:11
|
is the situation worse if you leave out -s 8
|
|
2021-02-26 12:35:38
|
our rd optimization is rather stupid for low qualities
|
|
2021-02-26 12:36:02
|
and doing a more thorough job at the wrong thing can be harmful
|
|
2021-02-26 12:36:39
|
we (roughly speaking) try to produce a constant amount of error without regard to how many bits we are saving
|
|
2021-02-26 12:36:53
|
it is not real rd optimisation, more just d optimization
|
|
2021-02-26 12:37:33
|
we have some hacks around it that add some r into rd, but it is pretty weak
|
|
|
|
Scope
|
2021-02-26 12:39:01
|
Hmm, I'll try the default speed as well
And for me, such compression is not very needed, but I communicate with some people who own sites with anime and art images and they need a minimum preview size without noticeable artefacts (and AVIF looks good for that)
|
|
|
|
Jyrki Alakuijala
|
2021-02-26 12:41:14
|
yes, easier for me if JXL works for this use case, too
|
|
2021-02-26 12:41:24
|
also, some photographs are in this direction, too
|
|
2021-02-26 12:41:56
|
with distinct simple geometry and not much other features
|
|
2021-02-26 12:42:39
|
AVIF is improving in the photography area (by bringing JXL's butteraugli into its tuning options)
|
|
|
|
Scope
|
2021-02-26 12:43:12
|
Also, not a photo, but https://discord.com/channels/794206087879852103/794206170445119489/814634518191276122
|
|
|
|
Jyrki Alakuijala
|
2021-02-26 12:43:13
|
so, it is fair for us to improve in simple geometry
|
|
|
|
Scope
|
2021-02-26 12:46:47
|
(eye and face color)
|
|
|
|
Jyrki Alakuijala
|
2021-02-26 12:48:12
|
I see a difference in the shadow crossing over the eye
|
|
2021-02-26 12:48:24
|
ssim version removed the shadow
|
|
2021-02-26 12:49:11
|
I observe the eye little less saturated, but better with the shadow
|
|
2021-02-26 12:49:24
|
for face, I don't observe a change in color -- please help me
|
|
|
|
Scope
|
2021-02-26 12:49:45
|
Sometimes colors change noticeably in some places (this happens in JXL too, especially with strong compression and also I noticed now with tune=butteraugli), it's easier to notice when switching
|
|
2021-02-26 12:50:27
|
Or a past example https://discord.com/channels/794206087879852103/803645746661425173/814002782776328242
|
|
2021-02-26 12:51:05
|
<https://slow.pics/c/fGLgux2b>
|
|
2021-02-26 12:51:27
|
https://cdn.discordapp.com/attachments/803645746661425173/814147238288687144/unknown.png
|
|
2021-02-26 12:54:41
|
https://discord.com/channels/794206087879852103/794206170445119489/814659696035102780
And here, not only the shadow changes, but the white eyeball itself became closer to the face color
|
|
2021-02-26 12:59:09
|
The color of the face may not have changed (just some details have disappeared), but the eye is noticeably different
<https://slow.pics/c/IEurzq4m>
|
|
|
|
Jyrki Alakuijala
|
|
Scope
The color of the face may not have changed (just some details have disappeared), but the eye is noticeably different
<https://slow.pics/c/IEurzq4m>
|
|
2021-02-26 10:29:28
|
I agree that this doesn't look good -- but also it is the first iteration of AVIF experimenting with butteraugli. It can be something like they are using a local palette here for quantization and go too far after the one-shot correction approach.
|
|
|
|
Scope
|
2021-02-26 04:01:45
|
Yep, I'm just pointing out
|
|
|
|
fab
|
2021-02-28 03:22:21
|
missing tools to fit in discord 8mb limit so not really good
|
|
2021-02-28 03:22:42
|
|
|
2021-02-28 03:23:09
|
|
|
|
|
Deleted User
|
2021-02-28 05:57:37
|
Are patches helpful in photographic content?
|
|
|
|
_wb_
|
2021-02-28 06:02:13
|
They can be
|
|
2021-02-28 06:02:35
|
E.g. dots are encoded as tiny patches
|
|
2021-02-28 06:03:00
|
Like the stars in a night sky
|
|
2021-02-28 06:03:35
|
But dot detection is different from patch detection
|
|
|
|
Deleted User
|
2021-02-28 06:04:35
|
For example, this photo:
https://discord.com/channels/794206087879852103/803950138795622455/815644859889221682
|
|
2021-02-28 06:06:08
|
*Maybe* there could be some dots, but I doubt that patches will do any job there...
|
|
|
Pieter
|
2021-02-28 11:51:46
|
Question: is XYB also used for lossless compression of RGB input? That seems hard to do.
|
|
|
|
Deleted User
|
2021-03-01 12:26:33
|
``` -c 0..2, --colortransform=0..2
0=XYB, 1=None, 2=YCbCr```
|
|
2021-03-01 12:26:37
|
``` -C K, --colorspace=K
[modular encoding] color transform: 0=RGB, 1=YCoCg, 2-37=RCT (default: try several, depending on speed)```
|
|
2021-03-01 12:28:20
|
VarDCT can't be used for lossless, so you have to use Modular for that. `-c` are lossy transforms (lossy in terms of rounding errors) and `-C` are lossless (fully reversible) ones.
|
|
2021-03-01 12:32:18
|
https://wiki.multimedia.cx/index.php/YCoCg
|
|
2021-03-01 12:32:33
|
> In contrast to YCbCr, this colorspace isn't based on the human vision model. This colorspace was invented to use similar encoding techniques as YCbCr but with frames in RGB colorspace. It is possible to losslessly transform from RGB to YCoCg when using 2 more bits for YCoCg representation than for RGB. E.g., it is possible to losslessly transform a pixel from a 30-bit RGB frame into a pixel in a 32-bit YCoCg 4:4:4 frame and back. This assumes that each R, G, and B component will have 10 bits of information which Y will have 10 bits and Co and Cg will each have 11 bits.
|
|
|
|
Pieter
|
2021-03-01 12:56:30
|
Oh, I should just have --help'ed ๐
|
|
2021-03-01 12:56:32
|
Thanks!
|
|
|
|
Deleted User
|
2021-03-01 12:59:03
|
You're welcome!
|
|
|
|
Pieter
|
2021-03-01 12:59:45
|
Ah, I see. This is only listed with --help --verbose.
|
|
2021-03-01 01:00:14
|
I'm familiar with YCoCg; FLIF used that too, I think.
|
|
|
|
Deleted User
|
2021-03-01 01:00:14
|
And just in case you don't know: `-h -v -v -v` (triple verbosity) shows you all switches available (anyone please correct me if I'm wrong and there are more verbosity levels).
|
|
2021-03-01 01:00:55
|
Yes, there are some switches that single verbosity level (`-h -v`) or even double verbosity doesn't show.
|
|
|
|
Pieter
|
2021-03-01 01:03:50
|
What is RCT?
|
|
2021-03-01 01:04:15
|
Reversible Color Transform?
|
|
|
|
Scope
|
2021-03-01 01:05:58
|
https://discord.com/channels/794206087879852103/803645746661425173/812370330433749032
|
|
|
|
Pieter
|
2021-03-01 01:06:34
|
Oh, thanks.
|
|
2021-03-01 01:44:08
|
So you could combine XYB colorspace with YCoCg transform? Or is YCoCg specific to RGB?
|
|
|
|
Deleted User
|
2021-03-01 02:24:33
|
YCoCg directly involves RGB in calculations:
```Co = R - B;
tmp = B + Co/2;
Cg = G - tmp;
Y = tmp + Cg/2;```
|
|
2021-03-01 02:27:29
|
I don't know if it can be reworked for XYB (probably not, because XYB already decorrelates luminance and chrominance on its own), and even if it could, it wouldn't make any sense because of that exact same reason (there's nothing to decorrelate if it's already decorrelated ๐)
|
|
|
|
Pieter
|
2021-03-01 02:28:35
|
Right, I understand. Performing the same transform on XYB instead of RGB wouldn't have the same meaning, but YCoCg isn't a color space, it's a reversible transformation that I suspect can be done on any triplet of numbers.
|
|
2021-03-01 02:28:57
|
So I wonder if it's technically possible in JPEG-XL; not whether it makes sense ๐
|
|
|
|
Deleted User
|
2021-03-01 02:35:26
|
It's possible if you forcefully treat XYB as RGB, but AFAIK in JPEG XL both encoder and bitstream don't allow any other inputs for YCoCg than RGB.
Core devs are probably sleeping now ๐ so I'm giving my best answer on their behalf.
|
|
|
|
Pieter
|
2021-03-01 02:37:41
|
Sure, I'm just idly wondering.
|
|
|
|
Deleted User
|
2021-03-01 02:39:26
|
Ah yes, the shower thoughts.
|
|
2021-03-01 02:39:34
|
https://tenor.com/view/think-emoji-thinking-in-thought-rotate-gif-8083088
|
|
2021-03-01 02:45:36
|
By the way, can I get the XYB ICC profile? I'd like to play around with it in GIMP...
|
|
|
|
_wb_
|
|
Pieter
So I wonder if it's technically possible in JPEG-XL; not whether it makes sense ๐
|
|
2021-03-01 06:17:41
|
It is possible in (lossy) modular mode to do XYB and then do further RCTs like YCoCg. It's probably not useful to do that though (it would be re-correlating instead of decorrelating)
|
|
|
By the way, can I get the XYB ICC profile? I'd like to play around with it in GIMP...
|
|
2021-03-01 06:19:34
|
|
|
2021-03-01 06:19:58
|
That's an image with an XYB-like ICC profile
|
|
|
|
Deleted User
|
2021-03-01 06:29:55
|
Can I have the .icc file?
|
|
|
|
_wb_
|
2021-03-01 06:31:34
|
`convert foo.jpg foo.icc` will extract it
|
|
|
|
Deleted User
|
|
_wb_
`convert foo.jpg foo.icc` will extract it
|
|
2021-03-01 06:37:49
|
Thanks for the image, GIMP also does the trick!
(`Image`->`Color management`->`Save color profile to file...`)
|
|
2021-03-01 06:38:26
|
And here's the profile itself ๐
|
|
|
_wb_
|
|
2021-03-01 07:13:30
|
How was that image made?
|
|
2021-03-01 07:18:40
|
Because it seems like the `Convert to color profile` option is broken in GIMP. I can convert to sRGB, but when I try to convert to XYB, it behaves like if I pressed `Assign color profile` instead, come on <:ReeCat:806087208678588437>
|
|
|
|
_wb_
|
2021-03-01 07:34:08
|
<@179701849576833024> made that image
|
|
|
|
veluca
|
2021-03-01 08:36:16
|
It's an ICC profile that only has a mA2B chunk (or the other way round? I never remember...), you can use it to convert in one direction but not in the other - the reverse direction was written in plain old C++
|
|
|
|
_wb_
|
2021-03-01 08:46:06
|
I didn't know that existed
|
|
2021-03-01 08:46:37
|
Would a bidirectional one be much bigger?
|
|
|
|
spider-mario
|
2021-03-01 09:02:45
|
the A2B chunk is ~364 bytes iirc, so I suspect that adding the B2A chunk would add roughly as much
|
|
|
|
fab
|
2021-03-01 12:48:46
|
the discord where you did the talk was nederland or nerdland
|
|
|
Fox Wizard
|
|
|
_wb_
|
2021-03-01 01:15:14
|
nerdland, which is Dutch-speaking Belgian so there are also probably people there from The Netherlands ๐
|
|
|
|
fab
|
2021-03-01 01:26:38
|
is the server english?
|
|
2021-03-01 01:26:48
|
i want to join
|
|
|
|
_wb_
|
2021-03-01 01:28:57
|
no, it's Dutch
|
|
2021-03-01 01:29:14
|
https://nerdland.be/
|
|
2021-03-01 01:29:23
|
there's a discord link at the bottom
|
|
2021-03-01 01:29:41
|
but probably not very useful if you don't speak dutch ๐
|
|
|
|
Jyrki Alakuijala
|
2021-03-01 06:49:48
|
I'd love to learn every success or lack of success with the XYB ICC
|
|
2021-03-01 06:53:01
|
I think no one yet compared an XYB colorspace jpeg at similar filesize to classic YUV JPEGs
|
|
2021-03-01 06:53:20
|
if someone compares them, I'd like to learn about the impressions
|
|
2021-03-01 06:54:00
|
probably biggest differences if there are reds, browns or blue sky with some white clouds on it
|
|
2021-03-01 06:54:51
|
I believe that JPEGs should be ~15 % better in XYB, but I have no evidence about it
|
|
2021-03-01 06:54:56
|
it is fresh from the oven
|
|
2021-03-01 06:55:15
|
I believe less than 10 jpeg images have been converted to XYB so far
|
|
|
|
BlueSwordM
|
2021-03-01 06:56:06
|
Well, I know what feature I should throw in the AV2 feature basket. Native XYB support. ๐
|
|
|
|
Jyrki Alakuijala
|
2021-03-01 06:56:38
|
and backport it to AVIF, AV1 and VP9 and WebP ๐
|
|
2021-03-01 06:57:47
|
and while at it to h264, 265 and 266
|
|
2021-03-01 06:58:09
|
(well, at least consider it, if it actually "works" with jpeg)
|
|
|
|
Deleted User
|
2021-03-01 06:59:42
|
Just give me x264 with grain synth and XYB and I'm sold. Is it just me, or x264 encodes really are sharper than those in any H.265 encoder or even AV1?
|
|
2021-03-01 07:00:15
|
IMHO those new video codecs are blurry and resource-hungry, so I don't like them
|
|
2021-03-01 07:01:06
|
Why is AV1 optimizing for stupid PSNR and doesn't have x264's psy-tuning?
|
|
2021-03-01 07:02:00
|
x264 still is the sharpest encoder out there and it's sad it didn't influence current codecs' encoders
|
|
|
|
Jyrki Alakuijala
|
2021-03-01 07:03:18
|
I think we should be able to make av1, jpeg xl, vp9 and many others to be sharper than x264
|
|
2021-03-01 07:03:27
|
we just need different tuning approaches
|
|
|
|
BlueSwordM
|
|
Just give me x264 with grain synth and XYB and I'm sold. Is it just me, or x264 encodes really are sharper than those in any H.265 encoder or even AV1?
|
|
2021-03-01 07:06:08
|
Well, that's because you haven't seen proper HEVC or AV1 encodes yet.
|
|
2021-03-01 07:06:24
|
I can make them as sharp as a blade if you want to ๐ก ๐ช
|
|
|
|
Deleted User
|
2021-03-01 07:12:16
|
Sharp as *Blade*, eh?
|
|
2021-03-01 07:12:17
|
https://i.redd.it/viewl4k7vn801.jpg
|
|
|
|
Scope
|
2021-03-01 07:13:40
|
VMAF also likes some blurring
|
|
|
|
Pieter
|
|
https://i.redd.it/viewl4k7vn801.jpg
|
|
2021-03-01 07:17:13
|
I too like living dangerously.
|
|
|
|
Jyrki Alakuijala
|
|
Scope
VMAF also likes some blurring
|
|
2021-03-01 07:51:08
|
I thought VMAF liked sharpening (never used it)
|
|
|
|
BlueSwordM
|
|
Jyrki Alakuijala
I thought VMAF liked sharpening (never used it)
|
|
2021-03-01 07:55:10
|
Yes, but the default VMAF models mainly measures 2 things: compression artifacts and scaling artifacts.
Essentially, it gives a certain subjective score at a certain viewing distance and other parameters(3x monitor distance for 1080p, and 1,5x TV distance for 4k).
|
|
|
|
Scope
|
2021-03-01 07:55:46
|
I mean it gives higher points to a more plastic, smoother picture (but in a different direction than PSNR) than for example SSIM
|
|
|
|
_wb_
|
2021-03-01 07:58:58
|
As far as I understand, VMAF for still images boils down to PSNR/SSIM + natural scene statistics (which is normally typically used for no-reference metrics)
|
|
2021-03-01 08:24:27
|
Ah I see your second article is published, <@!321486891079696385>!
|
|
2021-03-01 08:24:28
|
https://chipsandcheese.com/2021/02/28/modern-data-compression-in-2021-part-2-the-battle-to-dethrone-jpeg-with-jpeg-xl-avif-and-webp/
|
|
2021-03-01 08:24:52
|
|
|
2021-03-01 08:25:12
|
https://tenor.com/view/spinal-tap-11-eleven-gif-20021413
|
|
2021-03-01 08:28:59
|
"what matters in the end are 4 things: image quality, efficiency, and speed."
|
|
2021-03-01 08:29:28
|
https://tenor.com/view/matthew-mc-conaughey-all-right-count-counting-fingers-gif-7221052
|
|
2021-03-01 08:43:46
|
typo: " I would like this 2nd part on an opinion"
|
|
2021-03-01 08:44:31
|
probably "I would like to end this 2nd part" or something was meant
|
|
2021-03-01 08:46:19
|
The title is a bit similar to that of my recent blogpost ๐
|
|
2021-03-01 08:46:22
|
https://cloudinary.com/blog/time_for_next_gen_codecs_to_dethrone_jpeg
|
|
|
|
BlueSwordM
|
2021-03-01 08:46:40
|
Yeah, I had noticed that when you posted it. If only I had posted it before you did. <:ReeCat:806087208678588437>
It does not matter in the end though. ๐
|
|
|
|
_wb_
|
2021-03-01 08:49:00
|
I don't mind, as long as we can ATTACK AND DETHRONE ~~GOD~~ JPEG
|
|
2021-03-01 08:53:37
|
that Final Fantasy battle menu layout style still makes me chuckle
|
|
|
|
Scope
|
2021-03-01 08:59:25
|
|
|
2021-03-02 03:46:43
|
https://twitter.com/CVEnew/status/1366595457330331649
|
|
2021-03-02 03:49:23
|
https://www.openwall.com/lists/oss-security/2021/03/01/3
|
|
|
|
Jyrki Alakuijala
|
2021-03-02 10:35:07
|
we are in the process of improving on this
|
|
2021-03-02 10:35:32
|
on one hand we are in the 'evaluation mode' still, just about to move to production mode
|
|
2021-03-02 10:37:23
|
looking back we probably allowed people to integrate it into system too early, but it is also good to be able to gather some experience on how systems work together
|
|
|
Crixis
|
2021-03-02 10:38:30
|
Fake it until make it?
|
|
|
|
Jyrki Alakuijala
|
2021-03-02 10:39:17
|
now we are at a stage where the fuzzing is being done and we are improving its completeness (like doing coverage analysis of fuzzing and having specialized encodings that create more effective fuzzing seeds)
|
|
2021-03-02 10:39:57
|
I believe that in the next version we will be able to get our security processes into a better shape
|
|
2021-03-02 10:43:01
|
I suspect we will not yet go into a mode where we will provide specific security fixes to old releases but will ask clients to just migrate to a new version
|
|
2021-03-02 10:50:16
|
I think we are at the point where we need to proceed carefully and consult our security experts on what is the correct way forward
|
|
|
|
_wb_
|
2021-03-02 10:55:11
|
In my opinion, if you integrate with a 0.x library with static linking, you have to realize that there might still be security issues and static linking means that you have to update every time such an issue is fixed โ dynamic linking at least allows to update the library without having to update the applications that use it. Either way, if you are using libjxl in production environments in a non-sandboxed way, there is some risk that malicious bitstreams can make it crash (and potentially that could lead to exploits).
|
|
|
|
Jyrki Alakuijala
|
|
Crixis
Fake it until make it?
|
|
2021-03-02 10:55:37
|
We are running parallel efforts in image quality, density, progressive rendering, HDR compatibility with Chrome, security, JPEG1 recompression improvements, layers, and *supporting Anime*
|
|
|
|
_wb_
|
2021-03-02 10:56:14
|
That's a risk in all software that processes potentially malicious data.
|
|
|
|
Jyrki Alakuijala
|
2021-03-02 10:57:00
|
Jon, I'll get our side of the JPEG XL team on top of this -- let's take the input from the security community without being defensive and reflect seriously on it, they are the good guys
|
|
|
|
_wb_
|
2021-03-02 10:57:07
|
Of course
|
|
|
|
Crixis
|
|
Jyrki Alakuijala
We are running parallel efforts in image quality, density, progressive rendering, HDR compatibility with Chrome, security, JPEG1 recompression improvements, layers, and *supporting Anime*
|
|
2021-03-02 10:58:01
|
A completely secure implementation without optimized anime encoding give you nothing in 2021
|
|
|
|
_wb_
|
2021-03-02 10:59:46
|
I hope we can get to a 1.0 version soonish, which is a way to say "we don't really expect there to be security issues left to be found, but if something is still found, it will be 'big news' and we'll roll out a fix asap"
|
|
2021-03-02 10:59:52
|
we're not there yet
|
|
|
|
Crixis
|
2021-03-02 11:00:33
|
there will be others JPEG1 recompression improvements in the future?
|
|
|
|
_wb_
|
2021-03-02 11:04:04
|
JPEG1 recompression does have some degrees of freedom in the encoder for improvement โ of course not in the actual data that gets encoded, but it does have freedom in how exactly things get encoded. The DC encoding is basically like lossless encoding of a small image (that happens to be in YCbCr color space in the case of JPEG recompression), and there is certainly room for improvement there.
|
|
2021-03-02 11:05:18
|
Also in the AC encoding there are some encoder freedoms in how the context modeling is configured, how contexts are clustered, how the symbols are encoded (which hybriduint config), etc
|
|
2021-03-02 11:06:32
|
In the case of 444, chroma from luma can also be used, and I do not know if the way we do that is optimal already
|
|
|
|
Jyrki Alakuijala
|
|
Crixis
there will be others JPEG1 recompression improvements in the future?
|
|
2021-03-02 11:06:32
|
JPEG1 recompression is not a huge priority
|
|
2021-03-02 11:07:18
|
there are possible improvements, but I consider it is better to get the people to migrate fully if possible
|
|
|
|
_wb_
|
2021-03-02 11:07:41
|
Agreed that it's not a big priority โ just being able to get something smaller than the original JPEG is the main feature that is needed. And since it's reversible, later encoder improvements can always be applied later.
|
|
|
|
Jyrki Alakuijala
|
2021-03-02 11:07:42
|
the improvements are incremental -- perhaps a 2x in decoding speed and perhaps 2 % in density
|
|
|
|
_wb_
|
2021-03-02 11:10:32
|
Yes, I think it's better to get software to have full jxl support than to rely on "we'll store the jpeg as jxl to save disk space but otherwise we'll pretend it's a jpeg", which may have the effect that software devs get lazy and rely on the legacy path instead of implementing proper jxl support
|
|
|
|
Jyrki Alakuijala
|
2021-03-02 11:13:26
|
I believe that once we have the option -- i.e., jpeg xl is supported by browsers -- the world will follow
|
|
|
bonnibel
|
2021-03-02 11:16:14
|
here's hoping my phone will stay supported for long enough to receive an update letting the camera store everything in jxl instead of heic ๐ค
|
|
|
Jim
|
|
Jyrki Alakuijala
I believe that once we have the option -- i.e., jpeg xl is supported by browsers -- the world will follow
|
|
2021-03-02 11:28:18
|
Once the major photo editors (for design, photography, and storage), graphics libraries (for server support), and browsers (for websites) support XL, there will be little need for JPG anymore. Obviously support will continue for quite a while as many websites will still continue to have old JPG files lying around. Many will not have the technical skill or capacity to go back and convert all old JPGs to JPEG XL or will not have the available time. I see JXL taking over on major sites fairly quickly (next couple years once sufficient support is achieved). Smaller sites will transition over this decade but it will likely be approaching 2 decades before we start seeing the majority of JPGs become JXLs.
|
|
|
|
_wb_
|
2021-03-02 11:34:10
|
Yes, there will be a very, very long tail of .jpg even in the most optimistic scenarios
|
|
|
|
Jim
|
2021-03-02 11:59:20
|
As far as AVIF, I feel it's use will be limited to only a few sites that are diehard fans and video sites (YouTube, Vimeo, Netflix, etc).
I am not sure if the keyframes' binary data of an AV1 can be pulled directly into an AVIF (some have described it as such but I have no confirmation). If so, that would make AVIF a perfect solution for video snapshots since they could be pulled directly from the video. Even if they have to be re-encoded as AVIF it would still be a good fit for them even with the longer encode times.
|
|
|
|
_wb_
|
2021-03-02 12:03:22
|
I suspect av1 keyframes can just be wrapped in an avif without real re-encoding. That's only useful for full-res movie stills though, not for something like youtube thumbnails...
|
|
|
|
Jim
|
2021-03-02 12:07:02
|
I figured since the really early days some browsers actually used the AV1 decoder to decode an AVIF as if it were a single frame of video, but i was not 100% sure it was acting directly as a keyframe.
However, it would be trivial to pull the full-res still then downsize for thumbnails. Small images (like the ones you see hovering over the timeline of a YT video) take fractions of a second to encode in AVIF and since the quality is very similar to the video it would be a great representation.
|
|
|
|
_wb_
|
2021-03-02 12:11:16
|
If you downscale, it doesn't matter much what the original codec was
|
|
|
|
Jim
|
2021-03-02 12:11:17
|
But for websites like Instagram, Pinterest, Flickr, G Photos, etc, it would not make sense to go with AVIF because of the smoothing effect and long encode times. JXL would be a much better fit with better quality and faster encoding.
|
|
|
_wb_
If you downscale, it doesn't matter much what the original codec was
|
|
2021-03-02 12:16:22
|
True, you could go with any image format. But adding additional file formats really just adds additional complexity. Having the full-res AVIF available would make sense to just use AVIF for all the images produced, especially since the representation would be extremely similar.
|
|
2021-03-02 12:17:32
|
Using other codecs has a larger potential of producing an image that does not fully match the video, especially those with higher compression.
|
|
|
|
Jyrki Alakuijala
|
|
_wb_
If you downscale, it doesn't matter much what the original codec was
|
|
2021-03-02 12:20:29
|
depends -- some codecs have poor low frequency or mid frequency performance
|
|
|
|
Jim
|
2021-03-02 12:29:22
|
Granted, it will likely be a while before AV1 is used universally. Hardware vendors are not enthusiastic about supporting it outside of decoding yet just like with VP9 due to the slow speed of encoding. Once the hardware gets fast enough and/or the encode speed increases dramatically, hardware encoding will start getting supported.
YouTube doesn't even use VP9 universally. For the largest channels they do, but I uploaded a VP9 last year and it transcoded as VP9 but this year when I did it transcoded as h264, so they may be starting to phase out VP9? Not sure. Only a few videos have been transcoded as AV1 so far.
|
|
|
|
Jyrki Alakuijala
|
|
Jim
Granted, it will likely be a while before AV1 is used universally. Hardware vendors are not enthusiastic about supporting it outside of decoding yet just like with VP9 due to the slow speed of encoding. Once the hardware gets fast enough and/or the encode speed increases dramatically, hardware encoding will start getting supported.
YouTube doesn't even use VP9 universally. For the largest channels they do, but I uploaded a VP9 last year and it transcoded as VP9 but this year when I did it transcoded as h264, so they may be starting to phase out VP9? Not sure. Only a few videos have been transcoded as AV1 so far.
|
|
2021-03-02 12:36:08
|
That is interesting -- do you have statistics on it?
|
|
|
|
_wb_
|
2021-03-02 12:47:07
|
It would make sense to transcode cheaply to h264 in general and only use more expensive codecs when the expected viewcount will justify it
|
|
2021-03-02 12:48:42
|
I'm also dreaming of something like that for Cloudinary, where we adapt encode effort settings depending on expected views
|
|
|
|
Jyrki Alakuijala
|
2021-03-02 12:48:59
|
isn't cheap coding to vp9 an option?
|
|
|
|
_wb_
|
2021-03-02 12:49:54
|
I would think vp9 is cheap enough, but iirc it is significantly more expensive to encode than h264
|
|
2021-03-02 12:53:33
|
e.g. for h264 we could encode realtime with a single worker instance, while for vp9 we need to add some more latency and split the input in chunks that can be distributed over multiple worker instances in order to produce an output stream without interruptions
|
|
2021-03-02 12:54:14
|
for av1 we can do the same with just some more latency and even more worker instances
|
|
2021-03-02 12:55:24
|
but we're not even using hardware for h264 encoding, I assume youtube would do that in hardware very cheaply
|
|
|
|
Crixis
|
2021-03-02 01:07:12
|
youtube encode first h264 hw, next 10 minute (less for big channels) h264 sw
|
|
2021-03-02 01:07:39
|
the hw version is horrible
|
|
|
|
_wb_
|
2021-03-02 01:12:47
|
hw encoders tend to take so many shortcuts... it's OK if it's for a high-quality encode, but for dense compression hardware encoding is probably not such a good idea (except if low-latency and low-cpu-cost is also desired, like for videoconference)
|
|
2021-03-02 01:14:07
|
I don't think it will be different with av1: people are saying not to worry about the speed of software encode because hardware encode will fix that, but I doubt hardware encoders will reach the same kind of results as software encoders
|
|
2021-03-02 01:16:06
|
until there are hardware encoders that use hw-implemented neural nets for psychovisual optimization, or something like that
|
|
|
|
Jyrki Alakuijala
|
|
Crixis
the hw version is horrible
|
|
2021-03-02 01:30:17
|
it is funny how noobies get totally excited about hardware encoding and how experienced people already want to run away screaming ๐
|
|
|
|
Crixis
|
|
Jyrki Alakuijala
it is funny how noobies get totally excited about hardware encoding and how experienced people already want to run away screaming ๐
|
|
2021-03-02 01:44:42
|
Instant, low energy encoding, sound good
|
|
|
|
Jyrki Alakuijala
|
2021-03-02 02:07:48
|
people also somehow can think that hardware can achieve more than software
|
|
|
|
Crixis
|
2021-03-02 02:12:12
|
trully sw is only more versatile hw
|
|
|
|
_wb_
|
2021-03-02 02:14:19
|
Hw can try many things at the same time. But it is hard to make hw also pick the best of them ๐
|
|
|
lonjil
|
2021-03-02 02:15:29
|
Supposedly, the h264 hw encoder on the newest Nvidia graphics cards is about as good as x264..
|
|
|
|
BlueSwordM
|
|
lonjil
Supposedly, the h264 hw encoder on the newest Nvidia graphics cards is about as good as x264..
|
|
2021-03-02 03:00:14
|
That's not exactly true though.
|
|
2021-03-02 03:00:40
|
If you don't look closely and encode easy content, yes, Turing+ h.264 is pretty good.
|
|
|
|
lonjil
|
2021-03-02 03:01:07
|
What? Nvidia's marketing material lied to me? *gasp* can't believe it
|
|
|
|
BlueSwordM
|
2021-03-02 03:02:41
|
I mean, it is an upgrade over Pascal, that is for sure.
Anyway, I won't talk about it too much until the video encoder article actually gets written. Until then, I have to be careful until I carry a lot of evidence against Nvidia's marketing and slightly shady video post processing.
|
|
|
|
Jim
|
|
Jyrki Alakuijala
That is interesting -- do you have statistics on it?
|
|
2021-03-02 03:28:50
|
I don't really have enough useful statistics. Obviously not a big channel, I hardly post stuff. I think only 2 of my videos ever encoded as VP9. All others were h264.
|
|
|
|
spider-mario
|
2021-03-02 03:35:43
|
could it also depend on characteristics of the initial upload?
|
|
2021-03-02 03:35:52
|
e.g. codec, bitrate, resolution, etc.
|
|
|
OkyDooky
|
2021-03-02 03:38:05
|
Maybe non-hd videos go through a different process. But getting a vp9 encode most certainly has to do with channel size / number of views ...
|
|
|
|
Jim
|
|
spider-mario
could it also depend on characteristics of the initial upload?
|
|
2021-03-02 03:44:31
|
Doubt it, I've uploaded videos as both h264 and vp9 and it didn't seem to change anything. The vast majority of mine get encoded to h264. I'm sure if I was a larger channel they would all be vp9.
|
|
|
|
Deleted User
|
|
Crixis
A completely secure implementation without optimized anime encoding give you nothing in 2021
|
|
2021-03-02 03:53:36
|
I don't really like anime, but I had to follow suit because people started posting their JXL-encoded anime pics, so, well... I had to use them in comparisons.
|
|
|
|
Crixis
|
2021-03-02 03:54:11
|
no anime no new format
|
|
|
|
BlueSwordM
|
2021-03-02 04:32:34
|
People.
|
|
2021-03-02 04:32:44
|
Every new single encode on Youtube is encoded as VP9 and h.264.
|
|
2021-03-02 04:34:21
|
Youtube is the one who decides to do 2 things:
1. Which person watching gets which stream(even though a VP9 copy is available, Youtube may choose not to show it to you)
2. If they decided to reencode with higher quality VP9 settings if it gets popular enough(popular channels get the higher quality VP9 copies from the start, at the cost of higher processing time).
|
|
|
|
lonjil
|
2021-03-02 05:08:36
|
There are videos on YouTube that don't have a VP9 encode.
|
|
2021-03-02 05:09:27
|
I know because I downloaded 4000 videos with the format filter set to webm, and some of the videos errored with "no matching format".
|
|
|
|
_wb_
|
2021-03-02 05:16:07
|
so annoying that Exif is basically a small embedded TIFF file
|
|
2021-03-02 05:16:23
|
I kind of hate TIFF
|
|
2021-03-02 05:16:33
|
it's almost as bad as PSD
|
|
2021-03-02 05:17:14
|
(was just working a bit on https://gitlab.com/wg1/jpeg-xl/-/issues/111)
|
|
|
lithium
|
2021-03-02 05:17:20
|
in YouTube some low click(view) rate video, only have h264,
and some video will use av1.
|
|
|
|
paperboyo
|
|
_wb_
it's almost as bad as PSD
|
|
2021-03-02 05:33:39
|
Wanted to figure out transparency and layering once and someone recommended this instead: https://github.com/gco/xee/blob/master/XeePhotoshopLoader.m#L108. Good read ๐ .
|
|
|
|
Jyrki Alakuijala
|
2021-03-03 01:50:38
|
what language is .m here?
|
|
|
Ringo
|
2021-03-03 01:52:02
|
I think it's Objective-C
|
|
2021-03-03 01:53:29
|
yeah it is
|
|
|
|
Jyrki Alakuijala
|
2021-03-03 01:53:33
|
Thanks
|
|
|
|
spider-mario
|
2021-03-03 03:29:05
|
yes, the NS in NS* classes stands for NeXTSTEP
|
|
2021-03-03 03:29:14
|
which evolved into Cocoa (Foundation Kit + Application Kit + Core Data)
|
|
|
Nova Aurora
|
|
spider-mario
yes, the NS in NS* classes stands for NeXTSTEP
|
|
2021-03-03 04:29:31
|
https://tenor.com/view/obi-wan-star-wars-memories-name-ben-kenobi-gif-4100026
|
|
|
|
spider-mario
|
2021-03-03 04:41:34
|
I remember that ~10 years ago, I was vaguely seduced by the idea of targeting GNUstep (http://gnustep.org/) and Mac OS together using Renaissance (http://www.gnustep.it/Renaissance/)
|
|
2021-03-03 04:41:38
|
not sure what went through my mind
|
|
|
|
il1kesonic
|
|
|
fab
|
2021-03-04 08:59:57
|
how to install this?
|
|
2021-03-04 09:00:00
|
https://github.com/mirillis/jpegxl-wic
|
|
2021-03-04 09:00:07
|
old computer without avx2 support
|
|
2021-03-04 09:00:12
|
max sse4.1
|
|
|
diskorduser
|
2021-03-04 09:23:58
|
make life easy. use leenox
|
|
|
|
fab
|
2021-03-04 03:51:44
|
how useful is -q 89.8 -s 7 -P 11 with current build of jpeg xl (stable) do anyone need such setting?
|
|
2021-03-04 03:51:57
|
do we need to update build
|
|
2021-03-04 03:52:05
|
because i need there are security issues
|
|
2021-03-04 03:52:12
|
also i need better vardct compression
|
|
2021-03-04 03:53:58
|
does predictor automatically chooses lossy modular or i need to specify -m ?
|
|
|
doajc_blogger
|
2021-03-04 03:55:49
|
<@416586441058025472>: Do you still need jpegxl-wic? I compiled it in 64 bits for my Core 2 Quad PC and I can post a copy here.
|
|
|
|
fab
|
2021-03-04 03:57:18
|
yes thanks
|
|
2021-03-04 03:57:33
|
as i understood it doesn't need compiling
|
|
2021-03-04 03:57:42
|
is only a setup you should make
|
|
2021-03-04 03:57:46
|
with inno setup
|
|
2021-03-04 03:57:58
|
thanks send
|
|
2021-03-04 03:58:09
|
has it sse4.1
|
|
|
|
doajc_blogger
|
|
|
fab
|
2021-03-04 03:58:56
|
how to install?
|
|
|
|
doajc_blogger
|
2021-03-04 03:59:09
|
Yes, it has SSE 4.1. I'll see how to install it.
|
|
2021-03-04 03:59:26
|
It looks like you just have to extract it and run "jpegxl_wic_setup.exe".
|
|
|
|
fab
|
2021-03-04 03:59:39
|
the three files will be registered and copied?
|
|
2021-03-04 03:59:55
|
|
|
|
|
doajc_blogger
|
2021-03-04 04:00:08
|
I believe so. I think the thumbnail handler was the one that was harder to set up.
|
|
2021-03-04 04:01:12
|
Some images don't work for some reason. I think it's kind of random but it's usually high-res images.
|
|
2021-03-04 04:01:47
|
This only lets the Windows Photo Viewer open JXL files. You need the thumbnail handler to see thumbnails.
|
|
|
|
fab
|
2021-03-04 04:02:37
|
and the thumbnails handler how to do
|
|
2021-03-04 04:03:06
|
it's loading
|
|
|
|
doajc_blogger
|
2021-03-04 04:03:10
|
|
|
2021-03-04 04:03:18
|
Put this somewhere, maybe in C:\Windows\system32, and register it with regsvr32 in an Administrator command prompt.
|
|
|
|
fab
|
2021-03-04 04:03:54
|
it's loading even if i uninstalled the sasha
|
|
|
|
doajc_blogger
|
2021-03-04 04:04:25
|
What's the sasha?
|
|
|
|
fab
|
2021-03-04 04:06:16
|
it works
|
|
2021-03-04 04:06:40
|
uninstall the winthumb sasha one
|
|
2021-03-04 04:06:43
|
use only mirillis
|
|
2021-03-04 04:07:24
|
still lossless jpeg recompressor isn't supported by mirillis
|
|
2021-03-04 04:07:39
|
and i think it decoded back to png
|
|
2021-03-04 04:07:47
|
jxl hasn't native jxl support
|
|
|
|
doajc_blogger
|
2021-03-04 04:07:49
|
Oh, you mean the GitHub user saschanaz?
|
|
|
|
fab
|
2021-03-04 04:07:55
|
yes from gecko dev
|
|
|
|
doajc_blogger
|
2021-03-04 04:08:01
|
I didn't know there was another winthumb implementation.
|
|
|
|
fab
|
2021-03-04 04:08:13
|
maybe he did a fork
|
|
2021-03-04 04:08:17
|
of an original
|
|
2021-03-04 04:08:57
|
also all images get loaded or a pixelated one when it's slow
|
|
2021-03-04 04:09:03
|
so no really alternative
|
|
|
|
doajc_blogger
|
2021-03-04 04:09:05
|
So does the mirillis WIC installer I sent do thumbnails?
|
|
|
|
fab
|
2021-03-04 04:09:08
|
in progressive loading
|
|
2021-03-04 04:09:09
|
yes
|
|
|
|
doajc_blogger
|
2021-03-04 04:09:46
|
I'll have to try it again.
|
|
|
|
fab
|
2021-03-04 04:10:15
|
if you uninstall all the two and reinstall it will be worse, slower system thanks to traces in the register
|
|
2021-03-04 04:11:40
|
RESUME
|
|
2021-03-04 04:11:41
|
it works
still lossless jpeg recompressor isn't supported by mirillis
and i think it decoded back to png
libjxl hasn't native jxl support
also all images get loaded or a pixelated one when it's slow
so no really alternative
in progressive loading
|
|
2021-03-04 04:11:46
|
.....
|
|
2021-03-04 04:11:48
|
END
|
|
|
|
_wb_
|
|
fab
how useful is -q 89.8 -s 7 -P 11 with current build of jpeg xl (stable) do anyone need such setting?
|
|
2021-03-04 06:32:19
|
The -P 11 probably doesn't do anything in that case. Why do you have such weird encode options?
|
|
|
fab
jxl hasn't native jxl support
|
|
2021-03-04 06:34:33
|
What does that mean?
|
|
2021-03-04 06:35:16
|
Libjxl decodes jxl to pixels or encodes pixels to jxl.
|
|
|
|
Scope
|
2021-03-04 06:38:03
|
RESUME
Because Fabian likes this kind of weird stuff, and the typical encoding settings are boring
.....
END
|
|
|
|
fab
|
2021-03-04 07:05:54
|
that i mean
|
|
2021-03-04 07:06:07
|
so nobody has already encoded in modular
|
|
2021-03-04 07:06:14
|
what about vardct
|
|
2021-03-04 07:06:47
|
other than for test or for lossless recompression did you convert to JXL?
|
|
2021-03-04 07:07:10
|
do you consume jxl bitstreams?
|
|
|
_wb_
What does that mean?
|
|
2021-03-04 07:08:14
|
no it decodes fine but not lossless recompressor as XNVIEW
|
|
2021-03-04 07:08:50
|
I meant libjxl in the second sentence
|
|
|
|
BlueSwordM
|
|
fab
so nobody has already encoded in modular
|
|
2021-03-04 07:10:11
|
Modular is mainly used for very low file size encoding and lossless.
VARDCT is mainly used for everything else.
|
|
2021-03-04 07:10:31
|
And yes, I converted everything lossless into JXL lossless since the savings in space are nice over WebP for the things I have.
|
|
|
|
fab
|
2021-03-04 07:11:10
|
what you downloaded lossless on internet?
|
|
|
|
BlueSwordM
|
|
fab
what you downloaded lossless on internet?
|
|
2021-03-04 07:11:28
|
I take my own game screenshots and screencaptures in PNG that I then compress with JXL.
|
|
|
|
fab
|
2021-03-04 07:11:33
|
the type of picture scope uses
|
|
2021-03-04 07:11:41
|
or a bit different
|
|
|
|
BlueSwordM
|
2021-03-04 07:11:50
|
Mainly video game screenshots.
|
|
|
|
fab
|
2021-03-04 07:12:27
|
ah
|
|
2021-03-04 07:12:42
|
but i read it decodes jxl to png then to pixels
|
|
2021-03-04 07:12:49
|
like there are further step
|
|
2021-03-04 07:13:37
|
or maybe is when you encode a jxl input
|
|
|
|
BlueSwordM
|
2021-03-04 07:13:38
|
No, no further steps.
PNG > Pixels > JXL > JXL Image.
|
|
|
|
fab
|
2021-03-04 07:14:06
|
jxl image can you convert?
|
|
2021-03-04 07:14:44
|
this you need to decode in png or another format
|
|
|
|
BlueSwordM
|
2021-03-04 07:14:49
|
That is not currently possible if I recall correctly.
|
|
|
|
fab
|
2021-03-04 07:14:58
|
how is called? pgm?
|
|
2021-03-04 07:15:00
|
pnn?
|
|
|
|
BlueSwordM
|
|
fab
pnn?
|
|
2021-03-04 07:15:37
|
Currently, the way of doing it is: JXLDEC > Pixels > PNG > Pixels > JXLENC > JXL image.
|
|
|
|
fab
|
2021-03-04 07:16:07
|
|
|
|
BlueSwordM
Currently, the way of doing it is: JXLDEC > Pixels > PNG > Pixels > JXLENC > JXL image.
|
|
2021-03-04 07:16:52
|
great
|
|
|
|
Scope
|
2021-03-04 08:06:52
|
๐ค
https://twitter.com/TessaMero/status/1367532231309234176
|
|
|
|
_wb_
|
2021-03-04 08:09:58
|
Yes, AMA tomorrow!
|
|
|
|
Crixis
|
2021-03-04 08:11:51
|
<@!794205442175402004> make a Q&A on this discord, but only about memes
|
|
|
|
_wb_
|
2021-03-04 08:16:23
|
About memes?
|
|
2021-03-04 08:17:52
|
https://c.tenor.com/UuDQL5n7OoEAAAAM/laugh-funny.gif
|
|
|
|
Pieter
|
2021-03-04 08:18:27
|
https://tenor.com/view/mob-psycho100-no-effect-memes-powers-gif-7757184
|
|
|
|
_wb_
|
2021-03-04 08:26:56
|
I know nothing about memes
|
|
2021-03-04 08:27:12
|
https://c.tenor.com/HUwwJuv6CNAAAAAM/jon-snow-kit-harrington.gif
|
|
|
|
fab
|
2021-03-04 08:56:24
|
what is the discord link <@!111445179587624960>
|
|
2021-03-04 08:58:39
|
i logged with google at meetup but on firefox it blocked
|
|
2021-03-04 08:58:47
|
it doesn't load
|
|
|
|
Scope
|
2021-03-04 08:58:59
|
https://www.meetup.com/mediadevs/events/276198511/
|
|
|
|
fab
|
2021-03-04 08:59:43
|
now i see
|
|
|
Dr. Taco
|
2021-03-04 09:34:40
|
I really hate that Meetup hides online links. I get that it's to prevent spammers, but it's really lame
|
|
|
|
Nova Aurora
|
2021-03-04 09:48:11
|
Will it be in this disocrd or it's own?
|
|
|
|
fab
|
2021-03-05 09:09:22
|
other discord you need to click participate
|
|
2021-03-05 09:09:30
|
but not add into calendar
|
|
2021-03-05 09:09:41
|
there is a discord gg link
|
|
|
|
_wb_
|
2021-03-05 01:51:59
|
<@179701849576833024> <@811568887577444363> I am going to try to put exif/xmp outside the jbrd and in the main container
|
|
|
|
veluca
|
|
|
fab
|
2021-03-05 03:09:42
|
how to have avif in windows photo viewer on windows 7?
|
|
2021-03-05 03:09:55
|
with thumbnail previews
|
|
2021-03-05 03:14:28
|
does mirillis action has AV1 encoding recording of the screen? or only decoding? since which version?
|
|
2021-03-05 03:14:50
|
question for cloudinary
|
|
2021-03-05 03:15:19
|
1) can you look at the bitstream and distinguish if is lossless vardct, vardct or even modular?
|
|
2021-03-05 03:16:00
|
2) can modular be encoded with floating partitioning (similar to wp2 or even better)? have you ideas about it? or it works in the DCT space?
|
|
2021-03-05 03:16:17
|
3) do you plan to add EXIF to libjxl ?
|
|
2021-03-05 03:17:16
|
4) when animation support, will they show to windows photo viewer, is there a risk windows explorer can crash on older computers? i heard novomesk helped it, is it true?
|
|
2021-03-05 03:52:42
|
this are the settings i used for old images
|
|
2021-03-05 03:52:59
|
cavif rs 0.6.6 94.8 -s 5
-q 88 -s 5 --epf=3 jxl 0.3
|
|
2021-03-05 03:53:12
|
cavif honestly i use automatic
|
|
2021-03-05 03:53:16
|
i'll compare file sizes
|
|
2021-03-05 04:17:50
|
SOMEBODY
|
|
2021-03-05 04:17:52
|
i need help
|
|
2021-03-05 04:17:53
|
-j -P 0 -g 5 -E 2 -s 3 -m
|
|
2021-03-05 04:18:04
|
i want to try a custom setting
|
|
|
|
BlueSwordM
|
2021-03-05 04:18:57
|
Wait, what are you trying to compress Fabian? Because these are some random settings you have. ๐
|
|
|
|
fab
|
2021-03-05 04:19:27
|
g 5 i want to keep
|
|
2021-03-05 04:19:33
|
i want to do lossy modular
|
|
2021-03-05 04:19:36
|
with 0.3.0
|
|
|
|
_wb_
|
2021-03-05 04:19:43
|
1) Yes
2) Modular does not use DCT, VarDCT can use floating partitioning (but the encoder doesn't do that atm)
3) Yes, I am currently working on it. We will have both the option to do uncompressed and compressed Exif and XMP.
4) Obviously there is always a risk that windows explorer can crash. That is not related to JPEG XL ๐
|
|
|
|
fab
|
2021-03-05 04:20:13
|
thanks
|
|
|
|
BlueSwordM
|
|
_wb_
1) Yes
2) Modular does not use DCT, VarDCT can use floating partitioning (but the encoder doesn't do that atm)
3) Yes, I am currently working on it. We will have both the option to do uncompressed and compressed Exif and XMP.
4) Obviously there is always a risk that windows explorer can crash. That is not related to JPEG XL ๐
|
|
2021-03-05 04:20:24
|
In that regard, can JPEG-XL in any speed preset use non-square partitioning in VARDCT mode?
|
|
|
|
fab
|
2021-03-05 04:20:27
|
so after 2 hour
|
|
2021-03-05 04:20:37
|
you will be speaking in discord cloudinary
|
|
2021-03-05 04:20:47
|
ok
|
|
2021-03-05 04:21:11
|
should i use mute microphone and not blasting copyright sounds?
|
|
2021-03-05 04:21:19
|
i think yes
|
|
|
|
Crixis
|
2021-03-05 04:22:23
|
When cjxl next version?
|
|
|
|
fab
|
2021-03-05 04:22:59
|
is doing
|
|
2021-03-05 04:23:05
|
failed to compress
|
|
|
|
Crixis
|
2021-03-05 04:23:25
|
I'm wating for low bpp and anime encoding
|
|
|
|
fab
|
2021-03-05 04:23:27
|
|
|
2021-03-05 04:23:50
|
can i set two times five?
|
|
2021-03-05 04:23:56
|
i want low sizes
|
|
2021-03-05 04:24:03
|
if you have same build try
|
|
|
|
Crixis
|
2021-03-05 04:24:05
|
I don't think g 5 exist
|
|
|
|
fab
|
2021-03-05 04:24:08
|
all jpeg xl people
|
|
|
|
_wb_
|
|
BlueSwordM
In that regard, can JPEG-XL in any speed preset use non-square partitioning in VARDCT mode?
|
|
2021-03-05 04:24:24
|
I think at speed 3 it only does 8x8. At faster speeds it does other things, iirc.
|
|
2021-03-05 04:24:43
|
-g 3 is max
|
|
|
|
fab
|
2021-03-05 04:25:04
|
can i set palette 0
|
|
2021-03-05 04:25:12
|
or it doesn't nothing
|
|
2021-03-05 04:25:19
|
do i need lossy palette to do anything
|
|
|
|
_wb_
|
2021-03-05 04:25:35
|
Build with debug (./ci.sh opt) if you want to get more informative errors
|
|
|
|
fab
|
2021-03-05 04:25:43
|
and i will change to predictors 5
|
|
|
|
_wb_
|
2021-03-05 04:26:00
|
Setting palette to 0 disables trying to find cases where palette can be done
|
|
|
|
Crixis
|
2021-03-05 04:27:44
|
@Fabian you tested -s 7 -m -Q 75?
|
|
2021-03-05 04:28:22
|
And -s 7 -d 2?
|
|
|
|
fab
|
2021-03-05 04:29:25
|
for %i in (C:\Users\User\Documents\F\*.jpg) do cjxl "%i" "%i.jxl" -j -P 5 --palette=0 -I 5 -s 3 -m --mquality=75 --num_threads=2
|
|
2021-03-05 04:29:27
|
done
|
|