|
|
veluca
|
|
_wb_
this is from d0.3 to d30
|
|
2021-02-05 02:14:44
|
pretty amazing how the heuristics manage to produce results that make some sense... 😛
|
|
2021-02-05 02:15:01
|
+1 on overlaying it on the image, would be super useful
|
|
|
_wb_
|
2021-02-05 02:29:26
|
In the debug image itself, or externally?
|
|
2021-02-05 02:29:59
|
I think I will make a little bash script that does that stuff
|
|
|
Crixis
|
2021-02-05 02:59:34
|
Not playable from android
|
|
2021-02-05 03:01:29
|
|
|
|
Fox Wizard
|
2021-02-05 03:03:32
|
Doesn't work for me either <:kekw:758892021191934033>
|
|
2021-02-05 03:04:13
|
Lol that name
|
|
|
Nova Aurora
|
2021-02-05 03:04:28
|
It works in MPV, but not firefox
|
|
|
|
Fox Wizard
|
2021-02-05 03:05:19
|
veryslow and placebo always worked for me though
|
|
2021-02-05 03:05:50
|
<a:FoxClap:807247796079820851>
|
|
|
|
Crixis
|
2021-02-05 03:06:00
|
now we must go blame x264 discord
|
|
|
fab
|
2021-02-05 03:06:32
|
Is there a x264 discord?
|
|
|
|
Fox Wizard
|
|
|
fab
|
2021-02-05 03:06:39
|
ah the format
|
|
2021-02-05 03:07:00
|
discord don't support AV1
|
|
|
|
Fox Wizard
|
2021-02-05 03:07:11
|
Wonder if this one works
|
|
2021-02-05 03:07:32
|
Used HandBrake, because lazy. Placebo, High, RF 0
|
|
|
|
Crixis
|
2021-02-05 03:07:55
|
All work
|
|
|
|
Fox Wizard
|
2021-02-05 03:08:05
|
Same
|
|
2021-02-05 03:08:50
|
Yes, only takes a few seconds anyways
|
|
|
|
Crixis
|
2021-02-05 03:10:40
|
Glitch art
|
|
|
|
Fox Wizard
|
2021-02-05 03:10:42
|
Wonder if it'll work
|
|
2021-02-05 03:11:05
|
Lol. Mine works, but yours doesn't <a:sadd:714292010982441001>
|
|
|
|
fab
|
2021-02-05 03:11:33
|
the one Jon made is better
|
|
|
|
Fox Wizard
|
2021-02-05 03:11:37
|
Maybe this one will break
|
|
|
|
fab
|
2021-02-05 03:11:39
|
with jpeg xl
|
|
|
|
Fox Wizard
|
2021-02-05 03:11:54
|
Yours shows 4:2:0 for me in VLC
|
|
2021-02-05 03:12:42
|
Wonder why your videos break on mobile <:ReeCat:806087208678588437>
|
|
2021-02-05 03:12:50
|
Also, 60 fps movies look... weird
|
|
2021-02-05 03:13:04
|
It's confusing my brain
|
|
|
BlueSwordM
|
2021-02-05 03:30:39
|
Lossless h.264 is not supported by many things.
|
|
|
|
_wb_
|
2021-02-05 03:57:36
|
|
|
2021-02-05 04:08:37
|
|
|
|
Orum
|
2021-02-05 04:08:59
|
that's profile, not color space
|
|
|
|
_wb_
|
2021-02-05 04:11:32
|
taking it to ridiculous bad qualities here, just to get some bigger blocks - but the encoder is currently limited to 64x64, it's not using the even bigger blocks yet (up to 256x256 can be done)
|
|
|
|
Fox Wizard
|
2021-02-05 04:18:16
|
<a:dirtblock:730482612484833341>
|
|
|
lithium
|
2021-02-05 04:21:36
|
A little curious, we can get this encoder improvement in jpeg xl v0.4?,
in my test, lossy modular in some image will increase file size,
i think probably vatdct adaptive quantization can optimize file size.
https://encode.su/threads/3544-JXL-reference-software-version-0-2-released?p=68499&viewfull=1#post68499
https://discord.com/channels/794206087879852103/794206170445119489/806911079842054164
|
|
|
OkyDooky
|
2021-02-05 04:58:40
|
btw\: what's the metric / heuristic to decide which transform (including size) is chosen?
|
|
|
|
_wb_
|
2021-02-05 04:59:47
|
I didn't do that, so cannot really answer that
|
|
2021-02-05 05:00:04
|
It seems to be doing a decent job
|
|
2021-02-05 05:00:11
|
But there's room for improvement
|
|
|
|
OkyDooky
|
2021-02-05 05:00:52
|
yeah, looks good. I was just curious
|
|
|
|
_wb_
|
2021-02-05 05:01:31
|
E.g. we don't take advantage of the possibility of using non-naturally aligned blocks (e.g. a 64x64 block that starts at offset 8, 24 instead of an offset that is a multiple of 64)
|
|
|
|
OkyDooky
|
2021-02-05 05:02:10
|
oh, that is even possible in jxl?
|
|
2021-02-05 05:02:15
|
wow
|
|
|
|
_wb_
|
2021-02-05 05:02:15
|
Also no huge blocks are used yet (128 and 256 square or rectangular)
|
|
|
|
OkyDooky
|
2021-02-05 05:02:18
|
didn't expect that
|
|
|
|
_wb_
|
2021-02-05 05:02:31
|
Yes, floating blocks are possible, the decoder will handle that fine
|
|
2021-02-05 05:02:42
|
Just the encoder is not producing it
|
|
|
|
OkyDooky
|
2021-02-05 05:02:54
|
but I guess there are limits... transforms not crossing "tile boundaries"
|
|
|
|
_wb_
|
2021-02-05 05:02:58
|
Still need to respect the group boundaries though
|
|
2021-02-05 05:03:00
|
Yes
|
|
2021-02-05 05:03:02
|
Exactly
|
|
|
|
OkyDooky
|
2021-02-05 05:03:10
|
Got it
|
|
|
|
_wb_
|
2021-02-05 05:03:47
|
Still, there are quite some arrangements you can make within a group that are not naturally aligned
|
|
2021-02-05 05:04:28
|
Of course a 256x256 block it will have to be naturally aligned since it is a whole tile by itself
|
|
|
|
OkyDooky
|
2021-02-05 05:05:59
|
This is pretty cool ... because it means that this some non-aligned larger block can be used instead of splitting it into smaller ones...
|
|
2021-02-05 05:06:12
|
(in certain cases)
|
|
2021-02-05 05:06:47
|
[Edit](https://discord.com/channels/794206087879852103/794206170445119489/807295975122927686): This is pretty cool ... because it means that some non-aligned larger block can be used instead of splitting it into smaller ones...
|
|
2021-02-05 05:07:35
|
You don't want to rely on luck w.r.t. locations of edges etc
|
|
|
|
veluca
|
2021-02-05 05:08:00
|
I don't think anybody really knows exactly what is going on in that selection heuristic 😄
|
|
2021-02-05 05:08:09
|
I guess I have an approximation
|
|
2021-02-05 05:08:23
|
but it kinda grew in a weird way
|
|
|
|
OkyDooky
|
2021-02-05 05:15:26
|
Without having looked *and* understood the code, I would have expected that butteraugli outputs some kind of "masking level" and you try to start with a large block and only subdivide it if the "masking level" isn't "homogenious" enough within a transform block ... this "masking level" would deal with edges in that flag areas have a lower masking threshold while texture-rich areas have a higher perceptual masking threshold
|
|
2021-02-05 05:15:42
|
(\<--would be my guess)
|
|
2021-02-05 05:16:11
|
[Edit](https://discord.com/channels/794206087879852103/794206170445119489/807298355561627648): Without having looked *and* understood the code, I would have expected that butteraugli outputs some kind of "masking level" and you try to start with a large block and only subdivide it if the "masking level" isn't "homogenious" enough within a transform block ... this "masking level" would deal with edges in that flat areas have a lower masking threshold while texture-rich areas have a higher perceptual masking threshold
|
|
|
|
lithium
|
2021-02-05 05:16:48
|
I understand, thank you 🙂
my target is non-photographic(synthetic), i think i need wait jpeg xl implement this encoder improvement.
|
|
|
|
_wb_
|
2021-02-05 05:50:20
|
https://www.youtube.com/watch?v=gKQXN7cPmuk
|
|
2021-02-05 05:51:36
|
the new visualization + a script to produce videos like this is ready to be merged in the dev repo, so soon in the public repo, in case anyone else wants to make visualizations like these
|
|
2021-02-05 05:52:28
|
could also be a nice debug tool for people who want to work on better block selection heuristics
|
|
2021-02-05 05:53:07
|
(could also do something similar for the adaptive quantization weight selection, btw)
|
|
|
|
veluca
|
|
Without having looked *and* understood the code, I would have expected that butteraugli outputs some kind of "masking level" and you try to start with a large block and only subdivide it if the "masking level" isn't "homogenious" enough within a transform block ... this "masking level" would deal with edges in that flag areas have a lower masking threshold while texture-rich areas have a higher perceptual masking threshold
|
|
2021-02-05 06:12:13
|
we did want to try something like that too - at the moment it's a much simpler heuristic.
|
|
|
|
_wb_
|
2021-02-05 07:40:06
|
For a discord server that is 10 days old, I think this one is quite nice, isn't it?
|
|
|
|
Fox Wizard
|
2021-02-05 09:22:50
|
<a:CatYes:806636752952754186>
|
|
|
Master Of Zen
|
|
_wb_
For a discord server that is 10 days old, I think this one is quite nice, isn't it?
|
|
2021-02-05 09:29:47
|
https://tenor.com/view/dance-kid-club-gif-9152583
|
|
|
|
_wb_
|
2021-02-05 09:51:59
|
Video codec profiles usually have a 444 profile that allows both 444 and 420. Higher profiles tend to be supersets of lower profiles.
|
|
|
|
Master Of Zen
|
|
_wb_
For a discord server that is 10 days old, I think this one is quite nice, isn't it?
|
|
2021-02-05 11:03:51
|
I hope you enjoy our company too <:pepelove:674256399412363284>
|
|
|
|
Orum
|
2021-02-06 02:01:02
|
because lossless requires the 4:4:4 profile
|
|
2021-02-06 02:01:16
|
I didn't invent the profiles 🤷
|
|
|
diskorduser
|
2021-02-06 02:50:09
|
Is jxl always 4:4:4?
|
|
|
lonjil
|
2021-02-06 03:12:55
|
it can do chroma subsampling but by default it doesn't
|
|
|
|
Orum
|
2021-02-06 04:28:35
|
the same command line?
|
|
2021-02-06 04:28:48
|
that's weird then... are you using different versions of the encoder?
|
|
2021-02-06 04:29:00
|
actually, we should probably take this to <#805176455658733570>
|
|
|
|
_wb_
|
|
lonjil
it can do chroma subsampling but by default it doesn't
|
|
2021-02-06 07:42:49
|
Currently cjxl only does chroma subsampling when recompressing an existing jpeg that happened to be chroma subsampled. It is only supported in YCbCr, not in XYB. Chroma subsampling is a crude way to do lossy compression (just throwing away half the image data), and it isn't really useful as a compression technique anymore since jpeg 2000. It only helps for codecs with weak entropy coding (like jpeg and maybe video codecs that need to have hw-friendly entropy coding).
|
|
|
|
lonjil
|
2021-02-06 07:52:25
|
indeed! IIRC even jpeg will sometimes look better at a lower file size without subsampling, so it definitely isn't needed for any modern entropy coding.
|
|
|
Pieter
|
2021-02-06 07:53:46
|
Well the fact that better entropy coding gives better quality than chroma subsampling is really saying that it isn't throwing away half of thr information.
|
|
|
|
lonjil
|
2021-02-06 07:55:51
|
yeah
|
|
2021-02-06 07:57:46
|
a kind of funny thing, some pirate release groups, instead of releasing the official 1080p release of some movie, will take the 4k bluray and downsample only the luma, giving a 444 1080p video.
|
|
|
|
Pieter
|
2021-02-06 07:58:52
|
(and that's expected; even from a pure lossless information theoretical aspect, the highest frequencies contain the least information, and less with increasing resolution, as you get stronger correlation with nearby pixels)
|
|
|
lonjil
a kind of funny thing, some pirate release groups, instead of releasing the official 1080p release of some movie, will take the 4k bluray and downsample only the luma, giving a 444 1080p video.
|
|
2021-02-06 07:59:22
|
Ha, interesting.
|
|
|
|
_wb_
|
2021-02-06 08:02:46
|
Yes, chroma subsampling doesn't throw away half the information, otherwise it would give a compression benefit of 50% while even in weak codecs like jpeg it only gives like 5-10% better compression
|
|
2021-02-06 08:03:40
|
It does throw away half the data though
|
|
|
|
Pieter
|
2021-02-06 08:04:44
|
Fair.
|
|
|
|
_wb_
|
2021-02-06 08:10:13
|
Chroma subsampling is basically the same thing as zeroing 3/4 of the chroma coefficients (in the case of 420). There are better things to do than just zeroing them: e.g. predict them with chroma from luma so the residuals become zero but the reconstructed data remains sharp also in the chroma, or even just quantize them to mostly zeroes but still preserve some of the high frequencies when they have big amplitudes.
|
|
|
|
Pieter
|
2021-02-06 08:12:07
|
Yeah, that makes sense.
|
|
|
|
_wb_
|
2021-02-06 08:12:43
|
In jpeg 2000, chroma subsampling doesn't really help to get better compression
|
|
2021-02-06 08:18:27
|
The main reason why it helps in jpeg is because jpeg's DC predictor is really bad ("left"), and its AC entropy coding is simple (just Huffman), so the overhead per block is significant.
|
|
2021-02-06 08:20:37
|
In video, I suspect they like 420 so much because it helps to reduce hardware cost (half the buffer sizes).
|
|
|
Scope
|
2021-02-06 02:45:03
|
Btw, some images (sources) where the difference at very low bpp between AVIF and JXL can be seen very clearly (I have shown them before, but still)
|
|
2021-02-06 02:45:08
|
|
|
2021-02-06 02:45:14
|
|
|
|
|
_wb_
|
2021-02-06 02:47:17
|
That last one I hadn't seen before - I assume avif's artifacts fit very well with that drawing style
|
|
2021-02-06 02:48:33
|
For the other two, I think jxl will eventually win vs avif, if more effort is spent on an encoder that uses huge blocks etc
|
|
|
|
Scope
|
2021-02-06 02:56:48
|
Also, is it possible to use techniques similar to LCEVC for image formats (a lower resolution image and a separate layer with small important details at a higher resolution)?
<https://youtu.be/t_lBwzttgBo>
|
|
|
|
Master Of Zen
|
2021-02-06 02:58:12
|
Super resolution
|
|
|
Scope
Also, is it possible to use techniques similar to LCEVC for image formats (a lower resolution image and a separate layer with small important details at a higher resolution)?
<https://youtu.be/t_lBwzttgBo>
|
|
2021-02-06 02:58:49
|
As I know it doesn't really work for high fidelity, fine for high appeal video
|
|
|
|
Scope
|
|
|
_wb_
|
2021-02-06 03:01:31
|
You can do it in jxl: make a multilayer image where e.g. the first layer is 2x, 4x or 8x downsampled
|
|
2021-02-06 03:02:04
|
It is not very useful for high fidelity
|
|
2021-02-06 03:02:11
|
For low fidelity it might be nice
|
|
|
|
Master Of Zen
|
|
Scope
|
|
2021-02-06 03:02:14
|
Btw we can see that you use night mode, images are yellow
|
|
|
Jim
|
2021-02-06 03:04:41
|
I feel it would be really useful for data-saving on images that have both text and/or vector graphics along with photographic data. For instance, a photo background saved at medium fidelity and lossless or near lossless layer with text or shapes/vector-type graphics to preserve edges and readability.
|
|
|
|
Scope
|
2021-02-06 03:08:41
|
These are screenshots from the video
And yes, I remembered about LCEVC when I experimented with `--resampling` in JXL
|
|
|
|
_wb_
|
2021-02-06 03:09:20
|
Ah yes <@172952901075992586> that would be useful, quite hard for an encoder to do without side info though (extracting overlaid text if it only gets the flattened image as input)
|
|
2021-02-06 03:10:08
|
But in jxl-aware authoring tools this could be a good option, e.g. store existing jpeg losslessly, add alpha channel and text or logo overlay
|
|
|
|
Jim
|
2021-02-06 03:17:00
|
Most other formats don't support layers - or at least not layers with different settings, so most image editors just didn't bother with it. However, most advanced image editors will still have raster and vector type layers. They could potentially flatten each type and send them to the JXL encoder to be encoded as separate layers.
|
|
|
|
Master Of Zen
|
|
_wb_
Ah yes <@172952901075992586> that would be useful, quite hard for an encoder to do without side info though (extracting overlaid text if it only gets the flattened image as input)
|
|
2021-02-06 03:17:28
|
This reminds of image codec that was banned because it recognized 6 as 8 and corrupted financial data
|
|
|
|
Jim
|
2021-02-06 03:20:40
|
That had to do with poor quality scans of documents where the encoder tried to enhance the poor quality image but ended up causing those problems. Not sure how that is the same as flattening & saving layers separately in image editors.
|
|
|
|
Master Of Zen
|
|
Jim
That had to do with poor quality scans of documents where the encoder tried to enhance the poor quality image but ended up causing those problems. Not sure how that is the same as flattening & saving layers separately in image editors.
|
|
2021-02-06 03:23:40
|
Wasn't that pattern recognition that was causing the error?
|
|
|
|
_wb_
|
2021-02-06 03:30:22
|
Yes, lossy encoders for JBIG2 that used bad metrics to make decisions
|
|
2021-02-06 03:31:01
|
If you look at average error, then a 6 and an 8 can be similar enough
|
|
2021-02-06 03:31:13
|
Which is why looking at avg error is a bad idea
|
|
2021-02-06 03:31:38
|
Yet it is still very common in image and video compression
|
|
|
|
Jim
|
2021-02-06 04:02:50
|
Coming from a marketing background, designers often complained about either having to save a high fidelity image that was very large just so people could read the text or saving at medium fidelity and having smaller text be nearly unreadable and even larger text having the jagged/artifacted edges. I suggested a there should be an image format that could save layers separately like that but the only one that fit the bill at the time was SVG. Unfortunately Photoshop does not save a browser-ready SVG, so it would mean going back and editing every SVG to save about 20% on file size. Not really worth it to have to do that. Would be great if editors could do that with JXL. I would suggest they save the combined raster layers as whatever the export quality is and vector/text layers as lossless by default. They could also add an extra section to layer properties that would allow designers to choose a specific quality for each layer/layer group if they wish.
|
|
2021-02-06 04:03:40
|
I know it really has nothing to do with the encoder other than it support such layering. Most will be on the image editor devs to implement the output. Just a thought though.
|
|
|
|
_wb_
|
2021-02-06 04:13:53
|
This is a good idea for a Photoshop or Gimp export plugin
|
|
2021-02-06 04:16:39
|
Basically an export option to choose between:
- merge layers before export
- keep layers as layers
- merge layers except text layers, keep those as separate lossless layers
(with the default being the last one)
|
|
|
|
Jim
|
2021-02-06 04:25:14
|
Or merge neighboring raster & vector layers and keep vector layers lossless (unless specified in their layer properties).
So you could have a layer setup like:
1. Text/vector
2. Text/vector
3. Raster
4. Text/vector
Which would become:
1. Combined layers 1 & 2 at lossless
2. Layer 3 at export quality
3. Layer 4 at lossless (if pixels are not obscured by above layers)
|
|
2021-02-06 04:26:45
|
And could keep pixels of lower layers empty/transparent that are obscured by above layers to save some space (by default) or keep the layers completely intact (if you want), but would likely have a larger size.
|
|
|
|
Deleted User
|
|
_wb_
Basically an export option to choose between:
- merge layers before export
- keep layers as layers
- merge layers except text layers, keep those as separate lossless layers
(with the default being the last one)
|
|
2021-02-06 04:28:30
|
and a fourth option:
- export layers as pages ;)
|
|
|
|
_wb_
|
2021-02-06 04:55:40
|
Or as animation
|
|
|
|
Deleted User
|
2021-02-06 05:27:05
|
I thought you hated them. ^^
|
|
2021-02-06 05:28:12
|
Try encoding pixel-art animation (e.g. GIF) with something like <:H264_AVC:805854162079842314>. Good luck retaining the pixel-art characteristics.
|
|
2021-02-06 05:31:24
|
The encoder's gonna smooth the crap out of those pixels and the palette goes \*poof\*.
|
|
|
|
BlueSwordM
|
2021-02-06 05:32:41
|
I mean, it doesn't help that it encodes in 4:2:0 by default.
|
|
2021-02-06 05:32:51
|
I'd suspect it would do better with a 4:4:4 output.
|
|
|
|
_wb_
|
2021-02-06 05:51:34
|
I hope 444 avif/av1 will work everywhere
|
|
|
|
BlueSwordM
|
2021-02-06 05:55:19
|
I mean, it already does, and it works quite well.
The issue will be with animations if a hardware decoder is present. 🤔
|
|
|
|
_wb_
|
2021-02-06 06:00:09
|
If it at some point doesn't work anymore on one sufficiently important browser/platform/device combination, we'll effectively be forced to always use 420
|
|
|
|
lithium
|
2021-02-06 06:45:03
|
In vardct q80 -s 7 produce some apparent tiny artefacts on smooth area(blue color word)
|
|
2021-02-06 06:45:23
|
original
|
|
2021-02-06 06:45:34
|
q80_s7
|
|
2021-02-06 06:45:48
|
m_Q80_s9
|
|
2021-02-06 06:47:04
|
original image jpeg q99 444
|
|
2021-02-06 06:51:43
|
cjxl -j -q 80 -s 7 --epf=3 and cjxl -m -Q 80 -s 9 -j -g 3 -E 3 -I 1
|
|
2021-02-06 06:52:35
|
jpeg-xl 0.3 35ad23dd
|
|
|
eaitrosducmnSglR
|
2021-02-07 02:34:55
|
you can embed raster images in svg
|
|
|
|
Pieter
|
2021-02-07 02:37:56
|
<@!111689857503375360> That sounds like djvu
|
|
|
190n
|
2021-02-07 03:01:13
|
you'd need a viewer that supports jxl
|
|
2021-02-07 03:01:31
|
and iirc you have to base 64 encode the image so +33% to the size
|
|
2021-02-07 03:05:03
|
well if your svg is going over a compressed protocol (like http with gzip) it's moot
|
|
|
raysar
|
2021-02-07 04:06:45
|
Question for dev: What is the function conversion between -d and -q param?
|
|
|
|
lonjil
|
2021-02-07 04:50:53
|
That will work afaik
|
|
2021-02-07 04:51:35
|
There is also a "near lossless" setting for modular, but idk how well that works.
|
|
|
|
_wb_
|
|
raysar
Question for dev: What is the function conversion between -d and -q param?
|
|
2021-02-07 07:49:28
|
https://gitlab.com/wg1/jpeg-xl/-/blob/master/tools/cjxl.cc#L567
|
|
|
|
raysar
|
|
_wb_
https://gitlab.com/wg1/jpeg-xl/-/blob/master/tools/cjxl.cc#L567
|
|
2021-02-07 08:14:50
|
great, thank you :)
|
|
2021-02-07 08:18:48
|
The highest quality is -d 0.1, maybe if we ask very nicely we will have acces to more <:BlobYay:806132268186861619>
|
|
|
|
_wb_
|
2021-02-07 08:38:56
|
Would better than d0.1 still make sense?
|
|
2021-02-07 08:41:23
|
It's quite hard to bridge the gap between extremely high quality lossy and full lossless
|
|
2021-02-07 08:43:33
|
Some lossless tricks cannot really be used when doing lossy, like switching up the reversible color transform per group or doing palette.
|
|
2021-02-07 08:44:28
|
So it is easy to get in a situation where the highest quality lossy becomes a larger file than the lossless one
|
|
|
|
Fox Wizard
|
2021-02-07 09:06:00
|
Makes me wonder if there will be a difference if the PNG got optimized
|
|
|
|
lonjil
|
2021-02-07 09:06:03
|
maybe it's something other than the complexity that is also affected by that setting in photoshop
|
|
|
|
_wb_
|
2021-02-07 09:09:58
|
Photoshop is weird and annoying
|
|
2021-02-07 09:10:28
|
It probably put your undo history in a weird proprietary metadata blob or something
|
|
|
|
lithium
|
2021-02-07 09:18:36
|
I guess is Photoshop XMP or some metadata?
|
|
|
|
_wb_
|
2021-02-07 09:22:44
|
Photoshop has 8BIM metadata that can contain a wide and ever changing variety of undocumented garbage
|
|
2021-02-07 09:23:21
|
Or Adobe in general
|
|
2021-02-07 09:25:31
|
I have seen 30 megabyte JPEG files that were 100 kb of JPEG image and the rest was "metadata", a.o. containing something that looked like XML containing a base64 encoded entire Adobe Illustrator file.
|
|
2021-02-07 09:26:48
|
And then you get people complaining that "the image looks different than when I open it in my program"
|
|
2021-02-07 09:30:20
|
I had similar feelings as this guy when I made a psd decoder: https://github.com/zepouet/Xee-xCode-4.5/blob/master/XeePhotoshopLoader.m#L108
|
|
|
|
lithium
|
2021-02-07 09:30:35
|
If you using png , you can consider drop some png chuck(without render), only save SRGB or ICCP chuck.
|
|
2021-02-07 09:33:38
|
I not sure png gAMA chunk is necessary save?
|
|
|
|
_wb_
|
2021-02-07 09:34:49
|
PNG has a bit too many ways to specify color space, and not all software deals correctly with it.
|
|
2021-02-07 09:35:12
|
The gAMA chunk is a particularly confusing one
|
|
|
|
lithium
|
2021-02-07 09:38:42
|
png gamma is mess...
http://morris-photographics.com/photoshop/articles/png-gamma.html
|
|
|
|
Fox Wizard
|
2021-02-07 10:46:18
|
Somehow your image got reduced to 517KB when optimizing it (about 86% smaller) <a:thinkShape:676826305089634304>
|
|
2021-02-07 10:48:55
|
The Photoshop one
|
|
2021-02-07 10:49:07
|
Oh lol
|
|
2021-02-07 10:49:11
|
The compressed one then
|
|
2021-02-07 10:49:30
|
The one that's 3.67 MB :P
|
|
2021-02-07 10:50:37
|
Wonder what will happen when you use the optimized one I sent
|
|
|
|
_wb_
|
2021-02-07 10:54:43
|
Are those two pngs the same pixels? Try `compare -verbose -metric pae first.png second.png null:`
|
|
|
|
Fox Wizard
|
2021-02-07 10:55:34
|
Strange
|
|
2021-02-07 10:55:46
|
It was converted to 8 bit, because it will stay the same quality
|
|
2021-02-07 10:56:42
|
Guess the source was 8 bit or something
|
|
2021-02-07 10:57:02
|
For me the banding is exactly the same
|
|
2021-02-07 10:57:09
|
Even when zoomed in 500%
|
|
2021-02-07 11:07:17
|
Hm, there's a very minor difference when viewing it in Photoshop. Had to zoom in a lot for it to become noticeable
|
|
2021-02-07 11:07:54
|
But only visible in Photoshop though. Browsers show the exact same image for me
|
|
2021-02-07 11:10:32
|
Both images I sent look exactly the same when previewed in browsers and only Photoshop shows me a small difference in banding
|
|
2021-02-07 11:14:39
|
When previewed in browsers they look exactly the same to me :/
|
|
|
|
lonjil
|
2021-02-07 11:15:34
|
Do y'all have monitors that can actually show more than 8 bits?
|
|
|
|
Fox Wizard
|
2021-02-07 11:15:47
|
I do
|
|
2021-02-07 11:16:23
|
Seems like the Windows Photos app can't either
|
|
2021-02-07 11:17:43
|
At least this explains why I couldn't see the difference between a native 8 bit and native 10 bit image, even when zoomed in with visible banding in shadows
|
|
2021-02-07 11:18:15
|
That's kinda <:ReeCat:806087208678588437>
|
|
2021-02-07 11:18:57
|
Wonder why there barely is any support for it :/
|
|
2021-02-07 11:19:24
|
Oh well, another sad thing
|
|
2021-02-07 11:19:38
|
Wonder when 10 bit or 12 bit monitors will be the standard
|
|
2021-02-07 11:19:55
|
Images would look <:PepeOK:805388754545934396> in shadows
|
|
2021-02-07 11:20:12
|
At least when they're 10 bit or higher natively
|
|
2021-02-07 11:20:31
|
~~I just completely made up that word I think~~
|
|
2021-02-07 11:24:29
|
Then I guess lol image viewers that make them look 100% the same
|
|
2021-02-07 11:25:13
|
Not a bad video demonstration though since it shows exactly what you wanted to show :p
|
|
2021-02-07 11:25:34
|
Gotta love it when you press enter and Discord acts like you used shift enter <:PepeOK:805388754545934396>
|
|
|
|
_wb_
|
2021-02-07 01:07:19
|
I do most image processing in 32-bit float when I implement stuff in Cloudinary, for exactly the same reason
|
|
2021-02-07 01:23:45
|
Default ImageMagick is also 16-bit internally, for the same reason
|
|
|
|
Deleted User
|
2021-02-07 02:16:17
|
<@!794205442175402004> Out of curiosity: How would I currently create a JXL with multiple layers if they are exported as separate images for example.
|
|
|
|
_wb_
|
2021-02-07 02:21:15
|
we don't have a cjxl option to take multiple inputs
|
|
2021-02-07 02:21:34
|
APNG input or PSD input could work
|
|
2021-02-07 02:22:32
|
`convert layer*.png multilayer.psd; cjxl multilayer.psd example.jxl` might work
|
|
2021-02-07 02:23:10
|
djxl does not have an option yet to give you back the layers though
|
|
|
|
raysar
|
|
_wb_
I had similar feelings as this guy when I made a psd decoder: https://github.com/zepouet/Xee-xCode-4.5/blob/master/XeePhotoshopLoader.m#L108
|
|
2021-02-07 02:47:18
|
😂
> PSD is not a good format. PSD is not even a bad format. Calling it such would be an
> insult to other bad formats, such as PCX or JPEG. No, PSD is an abysmal format. Having
> worked on this code for several weeks now, my hate for PSD has grown to a raging fire
> that burns with the fierce passion of a million suns.
|
|
|
|
lithium
|
2021-02-07 04:02:18
|
I think -q 100 -s 7 and -q 100 -s 9 can't get best result, need use more flag in this gitlab issue.
https://gitlab.com/wg1/jpeg-xl/-/issues/22#note_503444145
-m -q 100 -s 9 -g 3 -E 3 -I 1 // any
-m -q 100 -s 9 -g 2 -E 3 -I 1 // png pal8
-m -q 100 -s 9 -g 3 -E 3 -I 1 --palette=0 // pixel art
|
|
|
chuni
|
2021-02-07 04:11:52
|
Thanks for the suggestions <@!461421345302118401>, here are the resulting file sizes using your settings:
```
323386 0011-ect.png
226280 0012-ect.png
541195 jxl-s7-0011-ect-any.jxl
512448 jxl-s7-0011-ect.jxl
541195 jxl-s7-0011-ect-pixel.jxl
535301 jxl-s7-0011-ect-png-pal8.jxl
315098 jxl-s7-0012-ect-any.jxl
271958 jxl-s7-0012-ect.jxl
315098 jxl-s7-0012-ect-pixel.jxl
293486 jxl-s7-0012-ect-png-pal8.jxl
448463 jxl-s8-0011-ect.jxl
226940 jxl-s8-0012-ect.jxl
271173 jxl-s9-0011-ect-any.jxl
315376 jxl-s9-0011-ect.jxl
271173 jxl-s9-0011-ect-pixel.jxl
302577 jxl-s9-0011-ect-png-pal8.jxl
186824 jxl-s9-0012-ect-any.jxl
188897 jxl-s9-0012-ect.jxl
186824 jxl-s9-0012-ect-pixel.jxl
179613 jxl-s9-0012-ect-png-pal8.jxl
```
|
|
2021-02-07 04:13:02
|
It does seem to improve s9 results
|
|
2021-02-07 04:13:41
|
Though it does not exactly answer why s7 and s8 would be larger than the original PNG. Though maybe my assumption (wish) that s7 and s8 jxl should also be smaller than PNG for all cases is incorrect
|
|
|
|
lithium
|
2021-02-07 04:19:18
|
if you need smaller png, you can drop some not affect render chunk, only save sRGB and iCCP chunk 🙂
|
|
|
|
BlueSwordM
|
2021-02-07 04:21:49
|
`libpng warning: iCCP: profile 'Photoshop ICC profile': 'RGB ': RGB color space not permitted on grayscale PNG` 🤔
|
|
2021-02-07 04:22:06
|
I have a feeling this may be related to this. I may be wrong.
|
|
|
|
chuni
|
2021-02-07 04:24:11
|
Interesting! I do not see that warning pop up when running cjxl and don't know why it would have that iCCP profile... I can try to figure out how to remove that profile and re-encode as a jxl
|
|
|
|
_wb_
|
2021-02-07 04:24:55
|
PNG is basically gzipped PPM, i.e. it uses the DEFLATE algorithm, which is basically lz77 (distance,length) references encoded with Huffman prefix coding.
|
|
2021-02-07 04:26:20
|
JXL has a very flexible entropy coder based on FLIF's Meta-Adaptive context trees, a hybrid integer representation, a choice between ANS and prefix (though ANS is usually best), and an option to have lz77 references.
|
|
2021-02-07 04:27:21
|
By default, the lz77 stuff is not even tried, because it rarely helps much. Only at speed 9 is it even tried, iirc. (or maybe it is superficially tried at faster speeds, but not with good matching strategies)
|
|
2021-02-07 04:29:24
|
In rare cases though, the lz77 stuff works very well – especially repetitive stuff like ordered dither or halftoning patterns can compress extremely well with lz77, and relatively poorly with the usual approach of MA-ANS.
|
|
2021-02-07 04:29:59
|
Another difference between PNG and JXL is that PNG does things rows by row, while JXL does things in tiles (groups).
|
|
2021-02-07 04:30:42
|
Tiling has the advantage of parallel decode and the option of efficient cropped decode.
|
|
2021-02-07 04:32:11
|
It has the disadvantage (for lossless) that at the tile boundary, predictors cannot "look over the boundary" (otherwise you would lose parallel / cropped decode), so there are more pixels that are poorly predicted.
|
|
2021-02-07 04:33:04
|
Usually that doesn't matter much, but in low-entropy images (non-photographic ones) where prediction works really well, it can make a significant difference.
|
|
2021-02-07 04:33:45
|
The default tile size is 256x256, which is `-g 1`. With `-g 0` you can set it to 128x128, and with `-g 2` and `-g 3` to 512x512 or 1024x1024.
|
|
|
|
BlueSwordM
|
2021-02-07 04:35:44
|
Oh wow.
|
|
2021-02-07 04:35:49
|
I got the best results yet with close to no tiling.
|
|
2021-02-07 04:36:38
|
FLIF: 853,9kB
`cjxl -s9 d 0.0 -g 3` = 827,2kB
|
|
|
|
_wb_
|
2021-02-07 04:37:41
|
FLIF is like PNG: it does no tiling, so it does not suffer from the poorly-predicted tile boundary thing.
|
|
|
|
BlueSwordM
|
2021-02-07 04:39:16
|
Can tiling actually have a speed disadvantage too?
I'm getting higher speeds with 1024x1024 tiles vs 256x256 and 128x128 tiles in lossless -s 9 in the offending images that can be found here:
https://gitlab.com/wg1/jpeg-xl/-/issues/22#note_503444145
|
|
|
|
lithium
|
2021-02-07 04:42:38
|
in lossless compress add --palette=0 flag on pixel art image, probably a good idea?
|
|
|
|
_wb_
|
|
BlueSwordM
Can tiling actually have a speed disadvantage too?
I'm getting higher speeds with 1024x1024 tiles vs 256x256 and 128x128 tiles in lossless -s 9 in the offending images that can be found here:
https://gitlab.com/wg1/jpeg-xl/-/issues/22#note_503444145
|
|
2021-02-07 04:48:41
|
Decode speed: not really (except if bigger lz77 matches can be done, it will probably decode faster).
Encode speed: yes, probably, especially considering that a lot of encode steps in modular are not well parallelized yet
|
|
|
|
chuni
|
2021-02-07 04:49:30
|
Thanks for the awesome in-depth explanation <@!794205442175402004>
|
|
|
|
_wb_
|
|
lithium
in lossless compress add --palette=0 flag on pixel art image, probably a good idea?
|
|
2021-02-07 04:51:36
|
probably not a good idea, but can always try without palette (or allowing larger palettes, i.e. `--palette=10000`) to see if it is better
|
|
|
|
chuni
|
2021-02-07 04:51:51
|
I think that all makes sense. It's not strictly intuitive, but it makes sense why those jxl could be larger than those PNGs
|
|
2021-02-07 04:52:49
|
It does drag down the avg file savings I've been computing for jxl with speed 7 and 8 though compared to optimized PNGs, which can make JXL look a bit worse than it really is
|
|
2021-02-07 04:53:04
|
Though I have not found a case where speed 9 is larger than the PNGs
|
|
2021-02-07 04:54:23
|
|
|
2021-02-07 04:56:05
|
In case you're interested. Each row is an image set, mostly grayscale but some colors. Bottom rows are avgs with and without the outliers
|
|
|
|
_wb_
|
2021-02-07 04:56:27
|
Originally group size was fixed at 256x256. I pushed to make it variable in modular mode to have a better chance at consistently beating PNG. We ended up making the group size 128, 256, 512 or 1024 in modular mode. That way there is still a sensible upper bound on the group size (1 megapixel), but a lot less poorly predicted pixels: about 2k pixels per megapixel with `-g 3` (and 1 totally non-predicted pixel), while with 256x256 groups you have about 8k pixels per megapixels that are poorly predicted (and 16 totally non-predicted pixels).
|
|
|
|
chuni
|
2021-02-07 04:56:29
|
Unfortunately I cannot share the image sets themselves, but just some context for my inquiry and issue report
|
|
|
|
_wb_
|
2021-02-07 04:57:13
|
For non-grayscale images, you should also try adding `-E 3` for better compression and a fairer comparison to FLIF
|
|
2021-02-07 04:59:42
|
I don't think we have lz77 search at the moment that is as good and exhaustive as ZopfliPNG's, but <@!768090355546587137> can tell more about that since he made both ZopfliPNG and some of the lz77 stuff in jxl 🙂
|
|
|
|
lithium
|
|
_wb_
probably not a good idea, but can always try without palette (or allowing larger palettes, i.e. `--palette=10000`) to see if it is better
|
|
2021-02-07 05:00:22
|
Thank you very much, i still waiting jpeg xl 0.3.1 vardct improvement, hope we can meet soon 🙂
|
|
|
|
chuni
|
2021-02-07 05:03:08
|
FWIW, ECT uses ZopfliPNG under the hood with some other logic for picking the best encoding parameters. It gets results within 1% of Zopflipng at 50% of the encode time
|
|
|
|
lithium
|
2021-02-07 07:33:12
|
https://discord.com/channels/794206087879852103/794206170445119489/807683294749130802
I forget this sample, mozjpeg q80 444 and lossy modular Q80,
smooth area still keep smooth(blue color word), and don't have apparent tiny artefacts.
|
|
2021-02-07 07:33:18
|
mozjpeg q80 444
|
|
2021-02-07 07:34:20
|
but mozjpeg q80 444 have another error.
|
|
2021-02-08 11:16:18
|
I guess some image viewer can't correct read icc profile in jxl file?
|
|
|
|
_wb_
|
2021-02-08 11:40:54
|
the original has an Adobe 1998 ICC profile
|
|
2021-02-08 11:42:02
|
looks like it - that's wrong though
|
|
2021-02-08 11:43:13
|
yes, darker is correct here
|
|
2021-02-08 11:43:45
|
the brighter version is what you get if you take the original pixels and misinterpret them to be sRGB
|
|
2021-02-08 11:43:59
|
(i.e. when you just ignore the icc profile)
|
|
2021-02-08 11:44:37
|
afaik all browsers implement RGB ICC profiles correctly
|
|
2021-02-08 11:44:48
|
and none of them implement CMYK ICC profiles correctly
|
|
2021-02-08 11:45:49
|
untagged images (e.g. a JPEG without ICC profile) should be rendered assuming sRGB, which Chrome and Safari do correctly, but Firefox doesn't (it just sends the pixels to your screen, which is wrong if you happen to have e.g. a P3 screen)
|
|
2021-02-08 11:46:42
|
but then there's a bunch of software that handles images but does it incorrectly, like probably gitlab and also discord
|
|
2021-02-08 11:47:44
|
try this test image
|
|
2021-02-08 11:48:09
|
makes it easy to find software that doesn't handle ICC profiles correctly
|
|
2021-02-08 11:48:14
|
red is correct, green is wrong
|
|
2021-02-08 11:48:51
|
there you go, you now know where to complain 🙂
|
|
|
|
Crixis
|
2021-02-08 11:49:52
|
LOL
|
|
2021-02-08 11:50:11
|
preview green
|
|
2021-02-08 11:51:03
|
linux mint, flathub discord
|
|
|
|
_wb_
|
2021-02-08 11:51:06
|
they get away with it because most RGB ICC profiles are quite similar to one another - Rec709, sRGB, Adobe 1998, Display P3, it's all different but not hugely so
|
|
2021-02-08 11:51:39
|
I get the same behavior on MacOS viewing discord in chrome
|
|
|
|
Crixis
|
2021-02-08 11:52:07
|
flathub is a package manager
|
|
|
|
_wb_
|
2021-02-08 11:52:17
|
the preview image discord generates is just downscaling ignoring the icc profile
|
|
2021-02-08 11:52:21
|
slack does the same thing
|
|
|
|
Crixis
|
2021-02-08 11:55:55
|
cool
|
|
|
_wb_
try this test image
|
|
2021-02-08 12:04:06
|
On this lossless transcode is green, VarDCT red
|
|
2021-02-08 12:07:25
|
lossless transcode green is a bug?
|
|
|
|
_wb_
|
2021-02-08 12:07:37
|
how are you viewing the lossless transcoded image?
|
|
2021-02-08 12:08:35
|
it's a viewer bug if you see it in green
|
|
2021-02-08 12:09:33
|
|
|
2021-02-08 12:09:45
|
you need to check one of these boxes when exporting from photoshop
|
|
2021-02-08 12:09:52
|
at least one
|
|
2021-02-08 12:10:26
|
kind of silly that photoshop allows you to uncheck both without warning
|
|
|
|
Crixis
|
|
_wb_
how are you viewing the lossless transcoded image?
|
|
2021-02-08 12:10:31
|
pixbuf
|
|
|
|
_wb_
|
2021-02-08 12:11:08
|
looks like the pixbuf plugin isn't properly taking the profile into account then...
|
|
|
|
Crixis
|
2021-02-08 12:22:49
|
i must open a issue?
|
|
|
|
raysar
|
2021-02-08 01:52:44
|
yes but he add so many feature every time for a free software. 🥰
|
|
|
|
BlueSwordM
|
2021-02-08 02:00:18
|
Isn't XNViewMP closed source though?
|
|
2021-02-08 02:01:18
|
Anyway, I'd prefer donating to other pieces of software/associations, like Xiph and the like.
|
|
|
|
raysar
|
2021-02-08 02:29:56
|
I created a graph to compare -d and -q param in the encoder :
I need to add the mozjpeg and avif quality param to link all encoder for the near same butteraugli quality.
https://docs.google.com/spreadsheets/d/1jW50a3VgyWWvearvEiPf9KJHUR52EGlbDvvF7fFrpvc/edit?usp=sharing
|
|
|
|
diskorduser
|
2021-02-08 02:47:00
|
So cjxl doesn't support reading jxl files? I get error with jxl input file.
|
|
|
|
Deleted User
|
2021-02-08 02:53:16
|
https://tenor.com/view/mind-blown-head-explode-amazing-shocking-wow-gif-19681784
|
|
|
|
lithium
|
|
raysar
I created a graph to compare -d and -q param in the encoder :
I need to add the mozjpeg and avif quality param to link all encoder for the near same butteraugli quality.
https://docs.google.com/spreadsheets/d/1jW50a3VgyWWvearvEiPf9KJHUR52EGlbDvvF7fFrpvc/edit?usp=sharing
|
|
2021-02-08 03:55:02
|
-d flag is target butteraugli, not maxButteraugli,
compare other encoder, you probably need combination use dssim or ssimulacra.
The non-linearities near the just-noticeable-boundary in scale At larger errors (4.0+)
butteraugli becomes less useful. Current versions of butteraugli only extrapolate these values
as multiples of just-noticeable-difference, but the human visual system is highly non-linear and
large extrapolation doesn't bring much value.
source: Jyrki Alakuijala, old version Butteraugli
|
|
|
|
OkyDooky
|
2021-02-08 05:24:17
|
Has anybody tested how JPEG XL's lossless mode compares to JPEG-LS (lossless JPEG variant)?
|
|
2021-02-08 05:24:38
|
So far, I only saw benchmarks that exclude JPEG-LS
|
|
|
|
Scope
|
2021-02-08 05:28:19
|
Yes, I've added it in my comparisons (including new compression options), but JPEG-LS is only good on photographic content and has very fast speed, but is noticeably behind in compression efficiency
|
|
|
|
_wb_
|
2021-02-08 05:31:01
|
We tested it in JPEG, jxl beat it
|
|
2021-02-08 05:35:39
|
|
|
|
|
OkyDooky
|
2021-02-08 05:36:09
|
Ah, cool! Thanks!
|
|
|
|
_wb_
|
2021-02-08 05:36:42
|
Even WebP beats it, if you don't care about more than 8-bit
|
|
|
|
OkyDooky
|
2021-02-08 05:36:45
|
How would I go about referencing that?
|
|
2021-02-08 05:37:09
|
Is it part of some blog article?
|
|
2021-02-08 05:37:16
|
or conference paper?
|
|
2021-02-08 05:37:49
|
Oh, there's even a "JPEG-LS2" ... didn't know it existed
|
|
|
|
_wb_
|
2021-02-08 05:38:18
|
That's just part 2 of jpeg-LS, i.e. some RCT
|
|
2021-02-08 05:38:23
|
wg1m90008-ICQ-Report of lossless encoding experiment (JPEG XS CE 2.1, JPEG XL CE 8.2)
|
|
2021-02-08 05:38:54
|
It's only an internal JPEG document
|
|
2021-02-08 05:38:58
|
Not public
|
|
|
|
OkyDooky
|
2021-02-08 05:39:00
|
OK
|
|
2021-02-08 05:39:03
|
thanks
|
|
|
|
_wb_
|
2021-02-08 05:39:31
|
Input doc wg1m90008 is how we would reference it internally in JPEG
|
|
|
|
OkyDooky
|
2021-02-08 05:41:23
|
Uhm, what are actually the units of this table?
|
|
2021-02-08 05:42:05
|
Bits/Pixel?
|
|
|
|
veluca
|
|
|
_wb_
|
2021-02-08 05:45:58
|
Yes, bpp is bits per pixel
|
|
|
Jyrki Alakuijala
|
|
_wb_
Even WebP beats it, if you don't care about more than 8-bit
|
|
2021-02-09 03:14:44
|
'even WebP' 🙂 careful there, I could get hurt from such dismissal 😛
|
|
|
|
Nova Aurora
|
2021-02-09 03:57:20
|
webp lossless is very good, don't use it as a mark of patheticness.
|
|
2021-02-09 04:24:39
|
|
|
|
|
_wb_
|
|
Jyrki Alakuijala
'even WebP' 🙂 careful there, I could get hurt from such dismissal 😛
|
|
2021-02-09 06:08:55
|
It's just that I often got reactions saying "why didn't you compare to JPEG-LS?", especially in JPEG, because they are still assuming JPEG-LS is one of the best lossless codecs ever made. It is not. It's the best lossless codec _JPEG_ made (before jxl), but it was beat by lossless webp, by flif, and now by jxl.
|
|
|
|
Pieter
|
2021-02-09 06:18:58
|
So include numbers for comparison with JPEG-LS, it accomplishes 3 things:
* Avoids them asking about JPEG-LS
* Teaches them that JPEG-LS wasn't the best lossless codec before.
* Makes JPEG-XL look even better.
|
|
|
|
_wb_
|
2021-02-09 06:20:53
|
Yes, that's what we did 😁
|
|
2021-02-09 06:46:21
|
There is still room for improvement, but I think the jxl bitstream is expressive enough to not have exhausted its potential yet in 10 years, I mean in 10 years the best possible lossless jxl encoder will not have been written yet.
|
|
2021-02-09 06:47:27
|
Even for PNG it took over a decade to make 'best' encoders, and PNG is a ridiculously simple bitstream compared to JXL.
|
|
|
|
lithium
|
2021-02-09 09:46:52
|
A little curious, probably add a image type flag,
(like --ImageType=natural or --ImageType=synthetic), and use different heuristic in vardct mode,
probably can let things become better?
|
|
|
|
_wb_
|
2021-02-09 09:57:36
|
we could do that, for people who like to manually tweak encode settings, but in general we want default encode settings to do a good job, making it not really necessary to manually tweak anything.
|
|
2021-02-09 09:59:47
|
but maybe at some point we'll add encoder heuristics to detect certain kinds of synthetic images and encode some (parts of) images with Modular, and other (parts of) images with VarDCT, perhaps with different block type selection heuristics depending on what kind of image it is.
|
|
2021-02-09 10:08:17
|
The current jxl encoder is in a way just a proof-of-concept encoder that demonstrates that jxl works and can beat other image codecs. Seen from one angle, it's quite good already. Seen from another angle, it still has huge potential for improvement, since there are a lot of possible things that could be done that aren't even tried, that are done in a superficial or simplistic way, or that are done in a quite good but still not quite optimal way. Of the top of my head: splines, patches, encoding using multi-layer, floating blocks, bigger blocks, adaptive quantization, (better) taking into account signaling costs, delta palette (e.g. using it for DC?), better MA learning, etc etc.
|
|
|
|
lithium
|
2021-02-09 10:19:02
|
I get some weird thing in cjxl lossless (--palette),
some image if i add --palette=0 flag, can reduce 1~10kb size,
but some image will increase 1~10kb size,
I think if Filter per scanline like 1.png only have 0, --palette=0 will increase size,
and in my test, png pal8 can't use --palette=0, will increase size
Input file: 1.png | 243005 bytes
Image: 1088x832 pixels | 8 bits/sample | RGB & Alpha | 38365 color(s)
Delta filter: Mixed
Filter per scanline:
0000000000000000000000000000000000000000000000000000000000000000
Chunks: only critical
-m -q 100 --palette=0 -s 9 -g 1 -E 3 -I 1 --num_threads=12
-m -q 100 -s 9 -g 3 -E 3 -I 1 --num_threads=12
|
|
2021-02-09 10:22:37
|
and --palette=0 always a lossless flag?
|
|
|
|
Jim
|
|
_wb_
but maybe at some point we'll add encoder heuristics to detect certain kinds of synthetic images and encode some (parts of) images with Modular, and other (parts of) images with VarDCT, perhaps with different block type selection heuristics depending on what kind of image it is.
|
|
2021-02-09 10:31:49
|
That would be a great idea! I know a lot of people who are not file type savvy that always complain about having to save different images as jpg or png is a pain since they never know which to use. Though that goes along with the suggestion of image editors saving layers differently since most contain both photographic and vector types in the same image... though sometimes there is far more of one than the other and having it detect and pick lossy/lossless automatically would also be great.
|
|
|
|
lithium
|
2021-02-09 10:36:15
|
Not only 0, if png Filter per scanline have much duplicate, --palette=0 can't get size benefit
Input file: 4_01.png | 874607 bytes
Image: 1152x720 pixels | 8 bits/sample | RGB | 160127 color(s)
Delta filter: Mixed
Filter per scanline:
1444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444
Chunks: only critical
|
|
|
|
_wb_
|
|
lithium
and --palette=0 always a lossless flag?
|
|
2021-02-09 10:36:18
|
`--palette=N` means the following:
- **if** the image contains only `N` different (R,G,B,A) colors, make a palette of those colors.
- **if** the image contains only `N` different (R,G,B) colors, make a palette of those colors (and keep A as a separate channel, if there is any).
- for every group (256x256 tiles by default), also see if a palette can be made.
It is lossless whatever the value of `N` is.
|
|
|
|
lithium
|
2021-02-09 10:42:13
|
--palette=0 == --palette=1024 (default: 1024)?
|
|
|
|
_wb_
|
2021-02-09 10:48:17
|
no
|
|
2021-02-09 10:48:25
|
default is --palette=1024
|
|
2021-02-09 10:48:56
|
--palette=0 disables trying to do any palette (except channel palettes, those are controlled with -X and -Y)
|
|
|
|
lithium
|
2021-02-09 10:59:58
|
enable or disable --palette=0 and different(0~3) -g will affect file size 1~10kb(reduce or increase)
|
|
|
|
raysar
|
2021-02-09 05:08:40
|
I made a beautifull 60fps 😄 animate jxl but i can't watch it.
Nomacs, imagemagick viewer and imageglass can't watch animation.
Djxl say "Failed to write decoded image for frame 1/180.
Failed to write decoded image for frame 2/180..."
|
|
|
|
_wb_
|
2021-02-09 05:11:28
|
lol
|
|
2021-02-09 05:13:05
|
what format are you trying to decode it to?
|
|
2021-02-09 05:15:13
|
|
|
2021-02-09 05:16:07
|
I could decode it to PNG frames fine, looks something like <:This:805404376658739230>
|
|
2021-02-09 05:16:50
|
`djxl got.jxl output.png`
|
|
|
|
Jyrki Alakuijala
|
2021-02-09 07:22:29
|
argh, when I optimize integral transforms I now consistently get solutions without 8x8 dct (or with very small participation, like 4 %)
|
|
2021-02-09 07:22:49
|
but I know 8x8 dct generally looks like the best compromise 😄
|
|
2021-02-09 07:23:42
|
the optimization is convinced that 8x16 is equally good or better
|
|
|
|
_wb_
|
2021-02-09 07:28:57
|
How are you optimizing?
|
|
|
|
Jyrki Alakuijala
|
2021-02-09 07:30:39
|
I'm running the nelder mead in tools/optimizer/simplex_fork.py
|
|
2021-02-09 07:31:09
|
if I have a variable, say double kJonIsGreat = 77;
|
|
2021-02-09 07:31:32
|
I just change it into double kJonIsGreat = 77 + atof(getenv("VAR0"));
|
|
2021-02-09 07:31:54
|
and another variable with + atof(getenv("VAR1")); etc.
|
|
2021-02-09 07:32:02
|
currently I'm running 23 variables
|
|
|
|
_wb_
|
2021-02-09 07:32:12
|
Also: At low bpp, does the signaling cost of transform selection become significant? Bigger transforms or a restricted set of transforms can help to reduce signaling cost.
|
|
|
|
Jyrki Alakuijala
|
2021-02-09 07:32:21
|
then I just run the simplex_fork.py with the number of dimension and the size of delta
|
|
2021-02-09 07:32:58
|
I'm not sure, I'll usually only optimize between d0.6 and d12
|
|
2021-02-09 07:33:17
|
thinks will be funky at very low quality, more discrete and more difficult to optimize
|
|
|
|
_wb_
|
2021-02-09 07:33:32
|
The 23 variables are ac strategy heuristic parameters and the objective function is bpp*pnorm?
|
|
|
|
Jyrki Alakuijala
|
2021-02-09 07:33:40
|
yes
|
|
2021-02-09 07:34:03
|
I added some changes to initial quantization, some in ac_strategy and trying to find new parameters to fit the new code
|
|
2021-02-09 07:34:25
|
classically this part of the code I have just hand picked the parameters
|
|
2021-02-09 07:34:37
|
and taken a 10 % hit in metrics while doing that
|
|
|
|
_wb_
|
2021-02-09 07:35:11
|
The visualization might help to hand pick or try new algorithms
|
|
|
|
Jyrki Alakuijala
|
2021-02-09 07:35:12
|
with metrics optimization I get more ringing than I like
|
|
|
|
_wb_
|
2021-02-09 07:35:40
|
Black box optimization can be a bit risky
|
|
|
|
Jyrki Alakuijala
|
2021-02-09 07:35:54
|
I have added statistics of transforms into the benchmark tool
|
|
2021-02-09 07:36:04
|
so I learn about that every iteration of simplex fork
|
|
|
|
_wb_
|
2021-02-09 07:36:27
|
https://youtu.be/sflaIZ29e_Q
|
|
2021-02-09 07:36:43
|
I mean this kind of visualization
|
|
2021-02-09 07:36:59
|
Added a script to produce them
|
|
2021-02-09 07:38:17
|
Ugh the merge request hasn't landed yet, bot couldn't rebase
|
|
|
|
Jyrki Alakuijala
|
2021-02-09 07:43:14
|
yes, it is nice to have these, but I need to the integral transforms into my bones to be able to work with this
|
|
2021-02-09 07:43:31
|
it is too superficial, too little information, not communicating anything about the consequences
|
|
2021-02-09 07:43:41
|
it is just a visualisation of my mistakes 😄
|
|
|
|
_wb_
|
2021-02-09 07:44:00
|
as a movie, yes
|
|
2021-02-09 07:44:37
|
if you look at it frame by frame, carefully and losslessly at 1:1, it might be useful
|
|
2021-02-09 07:54:17
|
frames like this
|
|
2021-02-09 07:55:13
|
when MR 3052 lands, you can get these with `tools/demo_vardct_select.sh input.png frame-%02d.png`
|
|
|
|
Jyrki Alakuijala
|
2021-02-09 08:09:03
|
would be cool if all image compression systems could reuse each others block selection
|
|
2021-02-09 08:09:40
|
if there was an inter-exchange format for the block selection only and ways to extract that from the streams without using the encoder/decoder code itself
|
|
2021-02-09 08:11:52
|
I like to look at images that I cause to have some specific integral transform only, that teaches me more about them than the division itself
|
|
2021-02-09 08:12:43
|
like afv creates a sharper more pixelized look, 4x8 looks sharp and natural etc. dct4x4 looks a bit plastic, 16x16 somewhat blurry etc.
|
|
|
|
_wb_
|
2021-02-09 08:19:38
|
We now divide first, then keep the division but iterate to find adaptive quantization weights, right? In kitten
|
|
|
|
Jyrki Alakuijala
|
2021-02-09 08:19:56
|
first adaptive quantization
|
|
2021-02-09 08:20:04
|
then division
|
|
2021-02-09 08:20:20
|
division uses the max value from the respective adaptive quantization area
|
|
2021-02-09 08:20:40
|
it is all pretty silly code
|
|
|
|
_wb_
|
2021-02-09 08:20:52
|
Wait first adaptive quant just with 8x8 then?
|
|
|
|
Jyrki Alakuijala
|
2021-02-09 08:20:54
|
we have a new variation with 'new_heuristics' but I'm not yet tuning it
|
|
2021-02-09 08:21:08
|
and probably we rework it before tuning
|
|
2021-02-09 08:21:11
|
yes, 8x8
|
|
2021-02-09 08:21:37
|
current decision tree in splitting goes from 64x64 to smaller sizes
|
|
|
|
_wb_
|
2021-02-09 08:21:42
|
Ok but after division, the iterations for the real adaptive quant happen, right?
|
|
|
|
Jyrki Alakuijala
|
2021-02-09 08:21:52
|
I'm thinking of reversing the decision modes from 8x8 to larger transforms
|
|
2021-02-09 08:22:09
|
no further iterations at that stage
|
|
2021-02-09 08:22:22
|
ummm, yes, with slower modes real iterations
|
|
2021-02-09 08:22:36
|
if we run against butteraugli, i.e., kitten mode etc.
|
|
2021-02-09 08:22:52
|
I don't believe that many people will want to run butteraugli in the encoder -- too slow
|
|
|
|
_wb_
|
2021-02-09 08:23:21
|
I might want to try some completely different heuristics at some point
|
|
|
|
Jyrki Alakuijala
|
2021-02-09 08:23:48
|
let's discuss first -- I have some ideas about what is wrong right now
|
|
2021-02-09 08:24:05
|
and what are the main trouble areas and the images to test them with
|
|
|
|
_wb_
|
2021-02-09 08:27:59
|
Like just doing a laplacian or whatever edge detection, then do bin packing to fit blocks from largest to smallest in areas of uniform edginess, in a floating way, and then picking quantweights in some simple way
|
|
|
|
Jyrki Alakuijala
|
2021-02-09 08:29:26
|
we already look at how much quantization error there is, and we estimate the entropy produced
|
|
2021-02-09 08:29:52
|
more brutal approaches would be going backwards in the level of correct analytics
|
|
2021-02-09 08:30:26
|
but out approach is a bit silly -- it worked better at the time when dct32x32 was the largest transform, we need more flexibility now that we are using the 64x64, too
|
|
|
|
_wb_
|
2021-02-09 08:33:58
|
Especially if we want to use the even larger ones too
|
|
|
|
Jyrki Alakuijala
|
2021-02-09 08:42:37
|
yes, indeed, the current approach has come to the limit of its performance in this regard
|
|
|
|
veluca
|
|
_wb_
Like just doing a laplacian or whatever edge detection, then do bin packing to fit blocks from largest to smallest in areas of uniform edginess, in a floating way, and then picking quantweights in some simple way
|
|
2021-02-09 08:43:17
|
we do something similar for selecting the first guess of transform size
|
|
2021-02-09 08:43:27
|
(or I tried something like that at least)
|
|
2021-02-09 08:43:43
|
pretty sure we can do better
|
|
|
|
Jyrki Alakuijala
|
2021-02-09 08:49:16
|
I have disabled that in my current optimization run 😛
|
|
2021-02-09 08:49:42
|
it sabotages the air force chapel image that I try to fix
|
|
2021-02-09 11:22:36
|
banding, ringing, lack of geometry interpolation (fix any two 🙂
|
|
|
|
raysar
|
|
_wb_
`djxl got.jxl output.png`
|
|
2021-02-10 06:35:04
|
maybe it's a bug of windows compilation
|
|
|
|
_wb_
|
2021-02-10 06:37:57
|
Try .png
|
|
2021-02-10 06:38:15
|
We don't have an apng output encoder implemented
|
|
2021-02-10 06:38:23
|
Only input
|
|
2021-02-10 06:39:07
|
Also feel free to open an issue to add apng output, that would be practical
|
|
|
|
raysar
|
2021-02-10 06:57:45
|
ahh that's a trap ! 😅
|
|
2021-02-10 06:59:20
|
The lib can't also read animate jxl for picture viewer for now?
|
|
|
|
_wb_
|
2021-02-10 07:24:18
|
the library supports decoding of animation, but the viewer is probably not implementing it and just stopping when it gets the first frame
|
|
|
mvanderhallen
|
2021-02-10 10:08:45
|
Is there any jxl viewer for mac OS X? 🙂
|
|
|
|
_wb_
|
2021-02-10 10:09:16
|
https://discord.com/channels/794206087879852103/803663417881395200/805499535861350499
|
|
|
|
mvanderhallen
|
2021-02-10 10:12:37
|
Oh, great, thanks! Should have searched the discord as well, not only google 😇
|
|
|
|
lithium
|
2021-02-10 10:25:40
|
thank you <@!111445179587624960> 🙂
In jpeg xl v0.3.1, nomacs can't read this version compressed image,
and look like encoder improvement (integral transform selection) not in 0.3.1?
probably 0.3.2 will merge this encoder improvement?
|
|
|
|
_wb_
|
2021-02-10 10:36:21
|
maybe, depends on how quickly things will move and when we are ready for 0.4
|
|
|
|
lithium
|
2021-02-10 10:39:04
|
I understand, thank you very much 🙂
|
|
|
|
Jyrki Alakuijala
|
2021-02-10 11:15:17
|
Lee, I'm afraid I will be adding some ringing in the next version to improve the low bpp performance
|
|
2021-02-10 11:15:42
|
not much 😇
|
|
2021-02-10 11:15:54
|
I'll work on it later again
|
|
|
|
lithium
|
2021-02-10 11:21:56
|
I understand, thank you very much Jyrki Alakuijala :),
Very much looking forward jpeg xl implement this encoder improvement.
|
|
|
|
Jyrki Alakuijala
|
2021-02-10 11:22:26
|
at d11 we get this improvement (from 0.33 bpp to 0.32 bpp with image fragment):
|
|
2021-02-10 11:22:39
|
base
|
|
2021-02-10 11:22:56
|
opt
|
|
2021-02-10 11:23:36
|
a long term problem we have had with oblique lines is mitigated by now us being more diligent with larger transforms
|
|
2021-02-10 11:24:04
|
but it is still just 'scratching the surface' -- we can do much much better 😄
|
|
|
|
lithium
|
2021-02-10 11:32:24
|
I don't really understand about integral transform selection,
if improvement low bbp quality, it's mean vardct can process better on
image that features high contrast sharp edges and smooth area(cjxl -d 0.5 -s 7)?
|
|
|
|
_wb_
|
2021-02-10 11:37:27
|
That is very high bpp, not low bpp.
|
|
|
|
lithium
|
2021-02-10 11:38:47
|
I using -d 0.5 and -d 1.0 on high quality,
and -q 85 and -q 80 on medium quality.
|
|
|
|
_wb_
|
2021-02-10 11:45:48
|
Makes sense
|
|
2021-02-10 11:47:14
|
Jyrki is making -d 10 and worse look less ugly, so we are less embarrassing compared to avif at low fidelity encoding.
|
|
2021-02-10 11:51:30
|
I wouldn't recommend anyone to use -d 10 or worse. I consider the range d1-d4 the useful range for the web, and lossless or d0.3-d1 the useful range for archival. But people tend to compare things at ridiculously low bpp just to see heavy artifacts, and then judge codecs based on that...
|
|
|
|
lonjil
|
2021-02-10 11:55:40
|
Does Butteraugli even work usefully out to distances that large?
|
|
|
|
fab
|
2021-02-10 11:59:28
|
i'm restoring my images with webp2
|
|
2021-02-10 11:59:31
|
works great
|
|
2021-02-10 11:59:37
|
it deletes all artifacts
|
|
2021-02-10 11:59:47
|
|
|
2021-02-10 12:00:03
|
https://deploy-preview-957--squoosh.netlify.app
|
|
2021-02-10 12:00:11
|
not sure what commit is
|
|
2021-02-10 12:00:45
|
is great also
|
|
2021-02-10 12:04:27
|
some image work
|
|
2021-02-10 12:04:35
|
at least the one at less than q60
|
|
|
|
_wb_
|
2021-02-10 12:04:40
|
Using image encoders as a denoiser, hm <:Thonk:805904896879493180>
|
|
|
|
fab
|
|
|
Crixis
|
|
Jyrki Alakuijala
opt
|
|
2021-02-10 12:08:11
|
Much bigger bloks?
|
|
|
|
Master Of Zen
|
|
_wb_
I wouldn't recommend anyone to use -d 10 or worse. I consider the range d1-d4 the useful range for the web, and lossless or d0.3-d1 the useful range for archival. But people tend to compare things at ridiculously low bpp just to see heavy artifacts, and then judge codecs based on that...
|
|
2021-02-10 12:12:00
|
https://tenor.com/view/he-is-talking-about-me-me-myself-selfish-me-me-me-gif-16343230
|
|
|
|
_wb_
|
2021-02-10 12:14:11
|
Actually a lot of people do that
|
|
2021-02-10 12:14:46
|
It's more fun to drive a codec to where it breaks, than to pixel peep subtle artifacts
|
|
2021-02-10 12:15:41
|
https://c.tenor.com/nD5cv8oodb8AAAAM/reptar-city.gif
|
|
2021-02-10 12:17:14
|
is more fun than
|
|
2021-02-10 12:17:32
|
https://c.tenor.com/d_2-1aIWtaoAAAAM/detective-daffy-investigate.gif
|
|
|
|
Jyrki Alakuijala
|
2021-02-10 12:18:18
|
integral transform selection is like having an opening strategy for a chess game, super non-linear all with advantages and disadvantages
|
|
2021-02-10 12:18:30
|
previously I have focused on d1-d4, make it great there
|
|
2021-02-10 12:18:48
|
unfortunately silly people compare codecs at 0.1 to 0.2 bpp to make the artefacts visible
|
|
2021-02-10 12:18:59
|
I want JPEG XL to be slightly less embarrassing in such comparisons, too
|
|
2021-02-10 12:19:54
|
also, my managers are giving me consistent and continual advice on looking into lower bpp
|
|
2021-02-10 12:20:35
|
I disagree with it from a professional point of view, but I need to respect them, too, and give them some possibility to guide my efforts
|
|
|
|
Master Of Zen
|
|
Jyrki Alakuijala
unfortunately silly people compare codecs at 0.1 to 0.2 bpp to make the artefacts visible
|
|
2021-02-10 12:20:49
|
<:PepeHands:654081051768913941> why so rude)
|
|
|
|
fab
|
2021-02-10 12:21:44
|
wp2 best denoiser
|
|
2021-02-10 12:21:56
|
jxl best file reducer
|
|
|
|
Jyrki Alakuijala
|
2021-02-10 12:22:06
|
because it is silly to do technical comparisons outside the normal operation range
|
|
2021-02-10 12:23:02
|
same kind of ideas: heat the sauna to 800 degrees celsius to see if you can melt aluminium in it -- just to build an opinion if the sauna is comfortable
|
|
|
|
lonjil
|
2021-02-10 12:24:41
|
I think some people actually want to use 0.1bpp.
|
|
|
|
Jyrki Alakuijala
|
2021-02-10 12:25:05
|
people with 16" 8k monitors
|
|
|
|
Master Of Zen
|
|
lonjil
I think some people actually want to use 0.1bpp.
|
|
2021-02-10 12:25:57
|
I like ~d 3 for batch resize + compress for old photos/screenshots
|
|
|
|
Jyrki Alakuijala
|
2021-02-10 12:26:03
|
0.1 bpp 8k monitor is < 420 kB
|
|
|
|
Master Of Zen
|
2021-02-10 12:26:37
|
Having 8k monitor would be great)
I see your point)
|
|
|
|
Jyrki Alakuijala
|
2021-02-10 12:26:56
|
I think people with 8k monitors can afford 1 MB photographs
|
|
2021-02-10 12:27:14
|
currently decent photographs tend to be 4-5 MB
|
|
2021-02-10 12:27:32
|
and they are not 33 MP photos, just 12 MP
|
|
2021-02-10 12:28:04
|
but it is possible that eventually higher pixel densities will lead to lower average bpp
|
|
2021-02-10 12:28:26
|
but also, human vision gets even more non-linear at these resolutions
|
|
2021-02-10 12:28:59
|
it can be that very different modeling than dct will be useful
|
|
2021-02-10 12:29:27
|
also, the 8k video compression I have seen so far is not caring about pixels at all -- I think getting pixels right at 4k may be more useful
|
|
|
|
fab
|
2021-02-10 12:45:01
|
i didn't remember about jpg to jxl decoder
|
|
|
|
Scope
|
2021-02-10 12:57:22
|
I can clearly see the difference with the source at -d 3 and -d 2 if the image is not very high resolution (as well as notice artifacts), with -d 1 this happens much less often, mostly at a lower resolution and not on photographic images.
At very high resolutions or upscales it is possible to use a larger distance, but for me values higher than -d 1 are not very safe.
|
|
|
|
_wb_
|
2021-02-10 01:01:58
|
it all depends on the use case – if you're a high-traffic news site and you have a clickbait article with some bogus stock photo in it, you might want to get the filesize as low as possible to save on your bandwidth bill
|
|
|
|
Scope
|
2021-02-10 01:12:43
|
Yes, but I'm more about local storage, for sites low bpp can also be important, especially for previews or images that see only a few seconds, where the priority will be the minimum size and not annoying artifacts
|
|
|
|
fab
|
2021-02-10 01:22:56
|
surma https://deploy-preview-957--squoosh.netlify.app/
|
|
2021-02-10 01:23:21
|
which commit of webp2 is in deploy preview 957
|
|
|
|
lithium
|
2021-02-10 01:30:34
|
A little curious, why non-photographic image that features high contrast sharp edges and smooth area,
in high bbp(-d 0.5 s 7 and -d 1.0 s7) still have tiny error?, i still can't understand what reason produced this error.
|
|
|
|
_wb_
|
2021-02-10 01:47:58
|
High contrast edges are a worst-case for DCT: you basically cannot do any quantization of the high frequency if you want to get these perfectly right.
|
|
2021-02-10 01:49:23
|
<@179701849576833024> <@532010383041363969> does the Hornuss transform ever get selected?
|
|
|
|
veluca
|
2021-02-10 01:50:09
|
I suppose it can in principle, I didn't really check
|
|
|
|
_wb_
|
2021-02-10 01:52:24
|
At default speed I never see it
|
|
|
|
lithium
|
2021-02-10 01:57:10
|
in jpeg xl v0.2, i report this issue to Jyrki Alakuijala,
|
|
2021-02-10 01:57:12
|
http://encode.su/threads/3544-JXL-reference-software-version-0-2-released?p=68251&viewfull=1#post68251
https://encode.su/threads/3544-JXL-reference-software-version-0-2-released?p=68421&viewfull=1#post68421
|
|