|
Orum
|
2021-05-05 10:40:06
|
sure, 1 sec
|
|
|
fab
|
2021-05-05 10:40:20
|
<@!179701849576833024> effort 6 is speed 9 or effort 0 is speed 9
|
|
2021-05-05 10:40:30
|
you added it do squoosh
|
|
|
|
veluca
|
2021-05-05 10:40:48
|
you're assuming I remember 😛 but higher effort = slower IIRC
|
|
|
|
fab
|
2021-05-05 10:41:56
|
can jake archibald check
|
|
2021-05-05 10:42:14
|
no i had a 600 geekbench computer
|
|
|
improver
|
2021-05-05 10:42:16
|
or image is small
|
|
|
|
fab
|
2021-05-05 10:42:20
|
only hd
|
|
2021-05-05 10:42:23
|
not full hd
|
|
2021-05-05 10:42:32
|
full hd is always slower
|
|
2021-05-05 10:42:42
|
at s9
|
|
|
lithium
|
2021-05-05 10:42:54
|
you can concurrent cjxl instance
|
|
|
_wb_
That's a strange ssimulacra score, maybe caused by color space issues? The non-jxl ssimulacra assumes all input to be sRGB
|
|
2021-05-05 10:48:44
|
I think i find a problem, why djxl create a SRGB chunk on my png?
|
|
2021-05-05 10:48:49
|
Input file: bt_LLd_00a.png | 231563 bytes
Image: 480x720 pixels | 8 bits/sample | RGB & Alpha | 35665 color(s)
Delta filter: Mixed
Chunks: iTXt, tEXt
Input file: bt_LLd_00a_s9.png | 284559 bytes
Image: 480x720 pixels | 8 bits/sample | RGB & Alpha | 48157 color(s)
Delta filter: Mixed
Chunks: sRGB, zTXt
|
|
2021-05-05 10:55:32
|
bt_LLd_00a.png => cjxl -d 0.5 -s 9 => djxl to bt_LLd_00a_s9.png
|
|
2021-05-05 10:56:24
|
I understand SRGB mean, just don't know why new version djxl create this
|
|
2021-05-05 10:57:32
|
old djxl don't create SRGB
|
|
|
Petr
|
2021-05-05 10:58:56
|
Yup, `-d 0.5` means lossy.
|
|
2021-05-05 10:59:48
|
Use `-d 0.0` or `-q 100` for lossless.
|
|
|
Crixis
|
2021-05-05 11:00:12
|
or `-m`
|
|
|
_wb_
|
2021-05-05 11:10:18
|
djxl adds an sRGB chunk to make it clear that it is sRGB (without any tagging there is software that assumes the PNG is in display space)
|
|
|
|
lithium
|
2021-05-05 11:17:08
|
probably can keep jxl file icc profile behavior?
like if icc profile exist(adobe icc profile),
use this icc profile, if icc profile not exist, don't create SRGB,
keep default setting?
|
|
|
|
paperboyo
|
2021-05-05 11:22:58
|
My 2gr:
- if ICC present > keep ICC
- if (all possible flavours of) sRGB (both ICC-based and eg. DCF-tagged) > set sRGB chunk
- not sure what it should do when the source has no profile
|
|
2021-05-05 11:26:56
|
(Adobe, strangely, even for the second option **removes** any indication that an image is sRGB (https://github.com/adobe-photoshop/generator-core/issues/392#issuecomment-338714281). They cite some “arguments”. I think the strongest argument is: by spec, untagged PNG is sRGB, but this isn’t supported in practice: default Firefox. So I just think Adobe did that because they never learned how to write sRGB chunk)
|
|
|
|
lithium
|
2021-05-05 11:49:01
|
oh sorry, i think not srgb issue...
but have some strange thing,
i tested three pattern,
strip_original and non_strip_djxl png
non_strip_original and strip_djxl png
strip_original and strip_djxl png
I get three different ssimulacra score...
"ssimulacra": "0.51099064"
"ssimulacra": "0.21239742"
"ssimulacra": "0.35523892"
|
|
2021-05-05 11:54:31
|
ssimulacra will detect Invisible pixel?
I using pingo -s0 and -strip to strip metadata
|
|
2021-05-05 12:13:13
|
I diff original.png and original_strip.png
|
|
2021-05-05 12:13:28
|
"bt_LLd_00a_original.png":
"maxButteraugli": "0.000000",
"maxButteraugli_jxl": "0.0000000000",
"9Norm": " 0.000000",
"dssim": "0.000000",
"ssimulacra": "0.54378114"
"bt_LLd_00a_strip.png":
"maxButteraugli": "0.000000",
"maxButteraugli_jxl": "0.0000000000",
"9Norm": " 0.000000",
"dssim": "0.000000",
"ssimulacra": "0.51647917"
|
|
2021-05-05 12:15:34
|
ssimulacra_main -v original png and djxl d0.5 s9 png
|
|
2021-05-05 01:25:48
|
oh, i forget this.
ssimulacra_main version
jpeg xl 9e9bce86 and jpeg xl ab7c5e9b
|
|
2021-05-05 01:50:45
|
about ssimulacra this situation is expected?
And about vardct quality, -d 0.5 s8 and s9 is great,
but -d 1.0 and -d 1.9 still is not expected quality,
probably have some plan to improve those distance quality on next sync?
Edit: remove wrong data.
|
|
|
|
Deleted User
|
2021-05-05 03:32:53
|
Will it be possible to do "encrypted enhancement layer", just like JPEG XT does?
https://jpeg.org/downloads/jpegxt/IEEE_MM-preprint-AA-TE.pdf
|
|
2021-05-05 03:33:16
|
|
|
2021-05-05 03:33:55
|
|
|
|
monad
|
2021-05-05 03:41:40
|
What practical use case is there for encrypting just part of an image?
|
|
|
|
Deleted User
|
2021-05-05 03:53:06
|
For censoring sensitive information. Without the key you only get the extremely low-quality blurred preview.
|
|
|
Scientia
|
2021-05-05 03:53:12
|
Uhh maybe medical stuff
|
|
2021-05-05 03:53:39
|
Maybe artists will use it (hope not)
|
|
|
raysar
|
2021-05-05 03:54:23
|
that's cool technology :+1:, i vote to modify the bitstream to add it 😁
|
|
|
|
_wb_
|
2021-05-05 04:01:02
|
This can be done in principle via JUMBF metadata in the jxl container
|
|
|
|
monad
|
|
Scientia
Uhh maybe medical stuff
|
|
2021-05-05 04:15:45
|
In what context?
|
|
2021-05-05 04:20:34
|
The social media example seems the most practical and I can imagine this being a seamless experience for users, but in a social media context you have a high likelyhood of sensitive information being leaked anyway. Even if you label your images to indicate they're encrypted, people often screenshot to save and reshare images, at which point details of the encrypted regions are lost.
|
|
|
|
fab
|
2021-05-05 04:21:09
|
if you are still interested in wp2 i used q 43.6 4 pass vary chroma effort 10
|
|
2021-05-05 04:21:17
|
in fact is too slow
|
|
2021-05-05 04:21:33
|
i didn't finish
|
|
2021-05-05 04:21:37
|
firefox crashed anyway
|
|
2021-05-05 04:22:49
|
with webp i used something like q 53, 2 pass random matrix 5 filter sharpness
|
|
2021-05-05 04:23:05
|
pre process pseudo random dithering
|
|
2021-05-05 04:23:32
|
spatial noise shaping 29
|
|
2021-05-05 04:23:43
|
segment 4 partitions 2
|
|
2021-05-05 04:23:53
|
i don't remember correctly
|
|
2021-05-05 04:24:03
|
anyway it should in theory make quality worse
|
|
2021-05-05 04:24:10
|
but better appeal
|
|
|
|
_wb_
|
|
monad
The social media example seems the most practical and I can imagine this being a seamless experience for users, but in a social media context you have a high likelyhood of sensitive information being leaked anyway. Even if you label your images to indicate they're encrypted, people often screenshot to save and reshare images, at which point details of the encrypted regions are lost.
|
|
2021-05-05 04:25:06
|
One use case I can imagine is a photographer who gives you a usb stick with the photos after a photo shoot, where you get low-res previews of everything but the high-res ones only if you pay for them, or something.
|
|
|
|
Orum
|
2021-05-05 04:25:37
|
seems easier just to give people a separate image entirely
|
|
|
|
monad
|
2021-05-05 04:26:48
|
But the photographer needs your public key.
|
|
|
|
fab
|
2021-05-05 04:26:50
|
i'm not sure even on wp2 quality
|
|
|
|
monad
|
2021-05-05 04:26:56
|
Seems inconvenient.
|
|
|
|
fab
|
2021-05-05 04:27:11
|
but i don't think i used more than 43.6
|
|
2021-05-05 04:27:16
|
43.8 seems unlikely
|
|
|
|
Deleted User
|
|
monad
But the photographer needs your public key.
|
|
2021-05-05 04:27:29
|
Public key? JPEG XT probably uses symmetrical password.
|
|
|
|
fab
|
2021-05-05 04:27:59
|
i did go for 32 kb in a 1280x720 with torso image
|
|
|
|
monad
|
2021-05-05 04:28:02
|
I was just going off what the PDF you linked said.
|
|
|
|
Deleted User
|
|
_wb_
One use case I can imagine is a photographer who gives you a usb stick with the photos after a photo shoot, where you get low-res previews of everything but the high-res ones only if you pay for them, or something.
|
|
2021-05-05 04:28:04
|
The best thing that images can be encrypted *partially*. The rest is in high quality, only some parts are blurry. But yeah, your scenario can also make sense.
|
|
|
monad
I was just going off what the PDF you linked said.
|
|
2021-05-05 04:28:27
|
Seems like I'll have to re-read it more carefully...
|
|
|
|
_wb_
|
2021-05-05 04:31:39
|
I don't know if there are any practical tools for this, or if it's even further than the brainstorming stage
|
|
|
|
monad
|
2021-05-05 04:32:21
|
If you use a symetric password, you have have to distribute the password anyway, at which point you might as well distribute the data to those people whom it's intended for.
|
|
|
|
_wb_
|
2021-05-05 04:32:36
|
From my point of view, it's just a metadata blob that happens to contain an encrypted image
|
|
2021-05-05 04:33:54
|
Maybe the password fits in a text message but the data itself is several gigabytes and somewhat inconvenient to distribute on-demand
|
|
2021-05-05 04:34:23
|
But yes, I dunno if there is a big use case for this stuff
|
|
|
Pieter
|
2021-05-05 04:37:01
|
It's very annoying to deal with that at the image layer I think
|
|
2021-05-05 04:37:21
|
As it means all layers above need to deal with mixed secret/nonsecret data
|
|
|
|
Scientia
|
2021-05-05 04:59:19
|
I think it's only good for certain use cases
|
|
2021-05-05 04:59:33
|
And even then it is probably done better by third party software
|
|
2021-05-05 04:59:45
|
To be completely honest
|
|
|
|
lithium
|
2021-05-05 05:10:06
|
continue this discuss,
https://discord.com/channels/794206087879852103/794206170445119489/839499361871986758
I compare libjpeg and jpeg xl on non-photographic image,
libjpeg q90 444 and jpeg xl -d 1.0 -s7 ~s9,
jxl -d 1.0 -s7 and jpeg q90 have near quality,
not great quality have some tiny noise, but still look not bad.
use jxl -d 1.0 -s9 can increase quality(need verification).
if compare jxl -d 1.9|-q 80 -s7 and jpeg q80,
jxl have much noise, jpeg q80 also have much noise,
but sometime i think jxl is compress specific area too radical,
jpeg compress that area also have noise, but look okay(still in bad zone but acceptable),
jxl process dark red area is better than jpeg,
I guess jxl -d 1.45|q 85 probably is non-photographic image lower quality limit(need verification)?
|
|
|
|
Scientia
|
2021-05-05 05:16:00
|
I think s9 on vardct can reduce quality maybe
|
|
2021-05-05 05:16:11
|
It's not fully optimized
|
|
|
|
Orum
|
2021-05-05 05:40:22
|
yeah, it didn't look any better than s7 to my eyes
|
|
2021-05-05 05:40:34
|
and in some areas it seemed even worse
|
|
|
|
fab
|
2021-05-05 06:44:30
|
the efficiency of webp2 and jpeg xl is the same
|
|
2021-05-05 06:45:49
|
i'll show you what parameter use
|
|
2021-05-05 06:45:52
|
to get same quality
|
|
2021-05-05 06:45:57
|
same butteraugli distance
|
|
2021-05-05 06:46:01
|
same file size
|
|
2021-05-05 06:46:40
|
|
|
|
|
Orum
|
2021-05-05 06:47:20
|
squirrel
|
|
|
|
fab
|
2021-05-05 06:47:33
|
|
|
2021-05-05 06:48:07
|
|
|
2021-05-05 06:48:16
|
|
|
2021-05-05 06:48:19
|
effort 4 wp2
|
|
|
Nova Aurora
|
|
|
fab
|
2021-05-05 06:49:12
|
then original
|
|
2021-05-05 06:49:14
|
|
|
2021-05-05 06:49:31
|
you'll see that at high quality for text are similar
|
|
2021-05-05 06:51:13
|
jxl quality though is higher
|
|
2021-05-05 06:57:37
|
can i ask a thing
|
|
2021-05-05 06:57:45
|
can modular use gaborish=1
|
|
2021-05-05 06:57:55
|
96.523 -s 8 P 9 --epf=1 --gaborish=1
--nearlossless=15 with pingo
--palette= -s 9
--palette= - s 6
-d 4.018 -s 9
|
|
2021-05-05 06:58:00
|
want to do that
|
|
2021-05-05 07:00:18
|
then all the commands with latest jpeg xl
|
|
2021-05-05 07:05:18
|
i'd say visually by default jpeg xl is best at
|
|
2021-05-05 07:05:20
|
-q 79.64 -s 4 --epf=3
|
|
2021-05-05 07:05:49
|
at 93.2 96.2 dark areas retention could be better
|
|
2021-05-05 07:07:06
|
the wallpaper i'm using is a png from a modular jxl
|
|
2021-05-05 07:07:18
|
modular jxl sounds bad as a name
|
|
2021-05-05 07:07:31
|
i have not tried the build
|
|
|
|
Scientia
|
|
fab
the efficiency of webp2 and jpeg xl is the same
|
|
2021-05-05 07:07:32
|
Very bold claim to make fabian
|
|
|
|
fab
|
|
Scientia
Very bold claim to make fabian
|
|
2021-05-05 07:08:05
|
you're right
|
|
|
|
lithium
|
|
Orum
squirrel
|
|
2021-05-05 07:22:27
|
oh, that is my fault, i should remove that...
|
|
2021-05-05 07:25:18
|
but i just find some quality improve on -s8, -s9 too risk, maybe -s8 is a safe value?
|
|
|
|
fab
|
|
|
Scientia
|
|
lithium
but i just find some quality improve on -s8, -s9 too risk, maybe -s8 is a safe value?
|
|
2021-05-05 07:39:16
|
S7 is the safe default
|
|
2021-05-05 07:39:40
|
On modular s9 is the best usually and isn't unsafe
|
|
2021-05-05 07:39:51
|
But vardct s7 is safer
|
|
|
|
_wb_
|
2021-05-05 07:50:04
|
-s 8 is ok
|
|
2021-05-05 07:50:41
|
At least for photos it should be consistently somewhat better than -s 7
|
|
|
|
lithium
|
2021-05-05 07:51:59
|
for non-photographic image, -s8 will have some risk?
|
|
|
|
_wb_
|
2021-05-05 07:54:17
|
Well -s 8 will do more psychovisual optimization, which _should_ make it better distribute bits to where you see it most, but it might in some cases not really help
|
|
2021-05-05 07:55:25
|
The faster the speed setting, the closer it is to libjpeg-style quality setting, which means less perceptual tuning and more just setting quantization amounts.
|
|
2021-05-05 07:56:44
|
Which is usually worse, but in exceptional cases where the perceptual tuning makes a bad decision on a part of the image you particularly care about, it might be better to do something more 'uniform'
|
|
2021-05-05 07:59:46
|
I think wombat and squirrel are very good and well-tested encoder settings that will give great speed/quality/density trade-offs. Kitten is also good if you don't care about the extra encode time (it is still very fast compared to some other codecs).
|
|
2021-05-05 08:00:50
|
Faster than wombat I don't think you really need for vardct (for lossless it is useful though, if it's just for temporary files or something)
|
|
2021-05-05 08:01:50
|
Tortoise vardct is mostly just slower and maybe better but that's questionable.
|
|
2021-05-05 08:03:24
|
TL;DR: for vardct I think -s 6,7,8 are the best at reaching good trade-off points between speed and compression
|
|
2021-05-05 08:06:01
|
For modular atm only -s 3 has a good trade-off, the other speeds are still slower than they could be (but that requires improvements in the encoder heuristics/algorithms that are not trivial)
|
|
|
|
lithium
|
2021-05-05 08:11:08
|
s7 to s8 Butteraugli, Butteraugli_jxl, 9Norm, dssim, ssimulacra,
Those score have positive change, but to s9, i see some score will not keep positive.
I think will choose -s8.
I see some quality improve in jpeg xl 9a8f5195,
-d 0.5 is great now, but -d 1.0 still have some issue,
probably have some quality improve in next sync?
|
|
|
|
fab
|
2021-05-05 08:17:24
|
i still don't see the quality good at q 93.2 q 96.2 and less than q 75.9 e3 q 76.7 e 5
|
|
2021-05-05 08:17:33
|
effort not speed
|
|
2021-05-05 08:17:43
|
so maybe s 5 s8 they are
|
|
2021-05-05 08:17:59
|
q 93.2 q 96.2 i use only at speed 9
|
|
2021-05-05 08:18:34
|
with the commit before it was q 90.33 the limit
|
|
2021-05-05 08:18:46
|
for a good looking image
|
|
2021-05-05 08:19:43
|
(75) 87.1 to 90.33
|
|
|
|
lithium
|
2021-05-05 08:26:21
|
About vardct mode i have some issue, on non-photographic image,
compressed image some smooth area will create not exist noise on -d 1.0 and lower,
only -d 0.5 can avoid this issue(i can find some tiny, but it is hard to see),
-epf=3 will work this situation?
Thank you for teaching me <@!794205442175402004> 🙂
|
|
2021-05-05 08:35:58
|
Actually i get this situation on jpeg xl 0.2
|
|
|
lithium
About vardct mode i have some issue, on non-photographic image,
compressed image some smooth area will create not exist noise on -d 1.0 and lower,
only -d 0.5 can avoid this issue(i can find some tiny, but it is hard to see),
-epf=3 will work this situation?
Thank you for teaching me <@!794205442175402004> 🙂
|
|
2021-05-06 06:56:39
|
Answer: -epf=3 not work in this situation.
|
|
2021-05-06 07:25:04
|
example: high contrast sharp edges and smooth have gradient area, on jpeg xl -d 1.0 s7 or s8,
compressed image will increase some random distribution tiny noise,
libjpeg q90 444 can't process very well in this case,
but if i compare libjpeg q90 444 and jpeg xl -d 1.0 -s7 in this case,
random distribution tiny noise is too annoying...
|
|
2021-05-06 07:33:57
|
my expected quality is
d 1.0 will lost some detail, good area.
d 1.0 ~ d 1.45 good area.
d 1.45 ~ d 1.9 okay area.
d 1.9+ risk area, can see error.
|
|
2021-05-06 10:55:36
|
upload some test sample on gitlab,
(include jxl, jpeg, avif, webp)
|
|
|
|
veluca
|
2021-05-06 01:04:12
|
how big is that color profile?
|
|
2021-05-06 01:04:19
|
well, no, even still
|
|
2021-05-06 01:04:23
|
can you file a bug?
|
|
|
|
_wb_
|
2021-05-06 01:04:48
|
yes that is strange even if the color profile is 2 megabytes
|
|
|
Scope
|
2021-05-06 04:05:59
|
> jpeg-xl-040eae81-mingw64-avx2
> jpeg-xl-040eae81-mingw64
<https://encode.su/threads/3564-JXL-version-0-3-released?p=69598&viewfull=1#post69598>
|
|
|
|
fab
|
2021-05-06 04:25:15
|
Thanks
|
|
2021-05-06 04:25:42
|
Jxl and wp2 dont work in galaxy s4
|
|
2021-05-06 04:26:02
|
Only wp2 returns error
|
|
|
diskorduser
|
|
fab
Jxl and wp2 dont work in galaxy s4
|
|
2021-05-06 04:59:15
|
What. Can you explain it
|
|
|
|
fab
|
2021-05-06 05:00:30
|
Squoosh app
|
|
|
|
diskorduser
|
2021-05-06 05:01:08
|
On which browser?
|
|
|
|
fab
|
2021-05-06 05:04:52
|
Chrome galaxy s4
|
|
2021-05-06 05:05:27
|
Maybe the architecture is too old
|
|
2021-05-06 05:05:47
|
Do you had success with your Phone
|
|
2021-05-06 05:06:44
|
I tried also lossless effort 1 4
|
|
|
|
diskorduser
|
2021-05-06 05:20:56
|
I will check it
|
|
|
fab
Maybe the architecture is too old
|
|
2021-05-06 05:21:37
|
What's your image dimensions? Megapixels?
|
|
2021-05-06 05:29:02
|
It get errors too
|
|
|
|
Scope
|
2021-05-06 06:29:18
|
https://discord.com/channels/794206087879852103/805176455658733570/839897942172631080
|
|
|
Troc
|
2021-05-07 09:54:08
|
I'm using Firefox Nightly with Jx,l enabled in the settings but it doesn't work.
|
|
2021-05-07 09:54:40
|
I made an HTML that links to a local picture and it works with any other type of picture.
|
|
2021-05-07 10:01:48
|
This white line is also super irritating.
|
|
2021-05-07 10:02:24
|
Was this a pointless venture?
|
|
2021-05-07 10:04:06
|
<@!794205442175402004> I'm not sure if it's fine to ping you, is it?
|
|
2021-05-07 10:17:22
|
Appears to work on that website. I'll have to check something.
|
|
2021-05-07 10:25:25
|
However how do I remove the very annoying white line?
|
|
2021-05-07 10:28:11
|
Also, why does Firefox Nightly not display pictures in HTML?
|
|
2021-05-07 10:29:33
|
|
|
2021-05-07 10:30:14
|
Brave on the other hand displays the jpg but not the jxl. Should Firefox Nightly not display both?
|
|
2021-05-07 10:33:31
|
<!DOCTYPE html>
<html>
<body>
<img src="C:\Users\datam\Downloads\logo.jxl" alt="logo">
<P>asdg</p>
<img src="C:\Users\datam\Pictures\Red Sonja - Age of Chaos 001-000 - Copy.jxl" style="height:210px;width:240px; alt="Red Sonja: Age of Chaos Coverart">
<P>asdg</p>
<img src="C:\Users\datam\Pictures\output.jpg" style="height:210px;width:240px;>
</body>
</html>
|
|
2021-05-07 10:34:03
|
If that's not how it works, how come it works in Brave?
|
|
2021-05-07 10:34:21
|
Some browsers can use local path and others can't?
|
|
|
|
fab
|
2021-05-07 10:38:01
|
In theory d 2.913 -s 3 and similar settings should be already enough for jxl
|
|
|
|
Troc
|
2021-05-07 10:38:02
|
I changed the permission for localuri but still error.
|
|
|
|
fab
|
2021-05-07 10:38:16
|
But I havent pc
|
|
2021-05-07 10:38:45
|
When i have i will See how more i can compress
|
|
2021-05-07 10:39:00
|
Without comparing to wp2
|
|
|
|
Troc
|
2021-05-07 10:40:42
|
No change.
|
|
|
|
fab
|
2021-05-07 10:45:20
|
I know how to develop a script
|
|
2021-05-07 10:45:52
|
Basically you input 0.678 with simulacro from 06052021
|
|
2021-05-07 10:46:36
|
And i wait for Next build then i do 1.7 d s 4
|
|
2021-05-07 10:46:50
|
And that s p norm
|
|
2021-05-07 10:47:29
|
The encoder i will use 06052021
|
|
|
|
Troc
|
2021-05-07 10:47:31
|
I found that I can embed from other websites but not local path or Discord.
|
|
2021-05-07 10:47:51
|
Meaning I'm not sure where I would upload stuff I want to embed into html.
|
|
2021-05-07 10:49:04
|
Also is there a way to edit Firefox themes? I have a lovely theme except on nightly, it has a really irritating white line between the tabs and bookmark bar.
|
|
|
|
improver
|
2021-05-07 10:49:08
|
don't use '\\'
|
|
2021-05-07 10:49:27
|
even file:// needs forward slashes
|
|
2021-05-07 10:49:45
|
and yeah don't give full paths without file://
|
|
|
|
Troc
|
2021-05-07 10:50:07
|
<img src=file:///C:\Users\datam\Pictures\Red Sonja - Age of Chaos 001-000 - Copy.jxl" alt="Red Sonja: Age of Chaos Coverart">
VS
<img src=file:///C:/Users/datam/Pictures/Red Sonja - Age of Chaos 001-000 - Copy.jxl" alt="Red Sonja: Age of Chaos Coverart">
|
|
|
|
improver
|
2021-05-07 10:51:01
|
i think there may be some restrictions about absolute directories too to prevent reading and exporting private system files like `/etc/passwd`
|
|
2021-05-07 10:51:21
|
better not use absolute paths at all and just put all the images in same dir
|
|
|
|
Troc
|
2021-05-07 10:51:45
|
Where do I put this Chrome css?
|
|
|
|
improver
|
2021-05-07 10:52:00
|
css?
|
|
2021-05-07 10:52:07
|
oh. different thing
|
|
2021-05-07 10:57:16
|
I'm aware. <https://bugzilla.mozilla.org/show_bug.cgi?id=1558299> has more details
|
|
2021-05-07 10:58:11
|
also <https://developer.mozilla.org/en-US/docs/Archive/Misc_top_level/Same-origin_policy_for_file:_URIs>
|
|
|
|
Troc
|
2021-05-07 10:58:29
|
Alright, now I will just select the chrome css in tab editor.
|
|
2021-05-07 11:00:52
|
Why can't I just very very simply open the Black Gold theme I downloaded from the Firefox web thing and edit it? Why's this got to be such cancer?
|
|
2021-05-07 11:01:24
|
Where is it even?
|
|
2021-05-07 11:02:03
|
It's so fun when basic things work fine but every time you stray off the area you're supposed to be in it becomes a slog.
|
|
|
|
fab
|
2021-05-07 11:04:03
|
|
|
2021-05-07 11:04:25
|
I wrote some random settings to test encoder
|
|
2021-05-07 11:04:44
|
Settings that will make jpeg xl perform worse
|
|
|
|
Troc
|
|
improver
also <https://developer.mozilla.org/en-US/docs/Archive/Misc_top_level/Same-origin_policy_for_file:_URIs>
|
|
2021-05-07 11:05:09
|
I do not understand this.
|
|
2021-05-07 11:05:26
|
Nothing seems to do anything.
|
|
2021-05-07 11:05:55
|
Why is there not an option in the Themes section of Addons to just open the theme in a script editor
????
|
|
2021-05-07 11:07:36
|
It was in Picture, which I feel should be acceptable based on it being a default Windows folder that exists in every install.
|
|
2021-05-07 11:08:18
|
Also putting it in C:Users:my name still outputs nothing. Only broken pictures.
|
|
2021-05-07 11:10:33
|
It's also fun that Firefox Nightly says it's the fastest and most secure yet changed into my actual language which isn't the language of any website I use or my Windows install.
|
|
|
|
improver
|
|
Troc
Why is there not an option in the Themes section of Addons to just open the theme in a script editor
????
|
|
2021-05-07 11:10:36
|
ehh no that's not related to chrome css thingy
|
|
|
|
Troc
|
2021-05-07 11:10:43
|
It got that info from somewhere.
|
|
|
|
improver
|
2021-05-07 11:11:09
|
chrome css discussion should probably go to off-topic anyway
|
|
|
|
Troc
|
2021-05-07 11:11:21
|
|
|
2021-05-07 11:12:13
|
|
|
2021-05-07 11:13:44
|
Pretty idiotic that I can't view pictures from my own PC in my own HTML on my own Browser.
|
|
2021-05-07 11:16:49
|
I found the theme I like on Github too, but the format is not css. There's some Json files and some XPI files.
|
|
|
|
Crixis
|
2021-05-07 11:25:11
|
Xpi is an extension if i remember
|
|
|
|
Troc
|
2021-05-07 11:26:39
|
I would love to delete this white line because it's seriously activating my autism but I have no idea how to edit a theme. Someone on Reddit said that it was really easy, he just had to edit theme.
|
|
2021-05-07 11:28:07
|
The smart phone shaped tabs are also really annoying me. I would like to make them into squares.
|
|
2021-05-07 11:29:22
|
Are there any solutions that I can understand or do I just lug this browser into garbage and go back to using the regular one?
|
|
2021-05-07 11:34:44
|
https://www.reddit.com/r/firefox/comments/fo3j8l/remove_white_1px_white_line_after_address_line/
|
|
2021-05-07 11:36:06
|
I don't understand this because there is not ::after in this userChrome.css that I downloaded.
|
|
2021-05-07 11:38:08
|
This is the JSON for my theme I downloaded from Github. It doesn't have ::after either, so logically I shouldn't have this issue, right?
|
|
|
|
Petr
|
2021-05-07 11:38:51
|
This discussion really should continue in <#806898911091753051>…
|
|
|
|
Troc
|
|
|
_wb_
|
2021-05-07 12:59:35
|
I'm about to upload the final FDIS text of part 2 (file format) to the ISO document system
|
|
|
|
improver
|
2021-05-07 01:00:35
|
any actual changes from DIS?
|
|
2021-05-07 01:00:59
|
or rather.. differences from current implementation
|
|
|
|
_wb_
|
2021-05-07 01:05:24
|
differences are either already in the implementation or are in things that weren't implemented yet anyway
|
|
2021-05-07 01:05:58
|
so no problems
|
|
|
KAGAMI
|
2021-05-07 06:15:31
|
A format question: does JXL build on top of one of ISOBMFF/HEIF/MIAF or it has nothing to do with them? My understanding is that they are irrelevant but want to make sure
|
|
|
|
_wb_
|
2021-05-07 06:17:01
|
The raw codestream is not using any container (files starting with 0xFF0A)
|
|
|
|
veluca
|
2021-05-07 06:17:15
|
the JXL *container format* builds on top of ISOBMFF (which doesn't necessarily mean much imho...)
|
|
2021-05-07 06:17:31
|
HEIF also builds on top of ISOBMFF
|
|
|
|
_wb_
|
2021-05-07 06:18:29
|
The container is isobmff based, that is, it uses the chunk mechanism of 4 bytes size, 4 bytes fourcc code, payload. It does not use any miaf/heif stuff though.
|
|
2021-05-07 06:19:26
|
AVIF is based on HEIF which is based on MIAF which is based on ISOBMFF
|
|
|
|
KAGAMI
|
2021-05-07 06:19:53
|
Thanks! Turns out I had no idea about containers 😁
|
|
|
|
_wb_
|
2021-05-07 06:20:30
|
We try to avoid them
|
|
2021-05-07 06:20:43
|
At least on the web, raw codestream should be ok
|
|
|
|
Deleted User
|
|
_wb_
AVIF is based on HEIF which is based on MIAF which is based on ISOBMFF
|
|
2021-05-07 06:21:07
|
No wonder the overhead is larger than 10 JXL artworks. ^^
|
|
|
|
_wb_
|
2021-05-07 06:29:13
|
Nearly 500 bytes worth of container wrapping paper to say "hi everyone, I am an avif image with an alpha channel".
|
|
|
|
Deleted User
|
2021-05-07 09:01:26
|
Even literally putting the caption "hi everyone, I am an avif image with an alpha channel" as an ASCII string would be shorter...
|
|
|
|
monad
|
2021-05-07 09:06:07
|
harkens "The only photograph of Neil Armstrong on the Moon"
|
|
|
kbeckmann
|
2021-05-07 09:48:06
|
Hi! Sorry if this is kind of out of the blue, but has anyone attempted to implement a JXL decoder/renderer in HDL such as VHDL, Verilog, chisel, nMigen etc?
|
|
|
|
veluca
|
2021-05-07 09:49:19
|
Not as far as I know! (So probably not)
|
|
|
|
kbeckmann
|
2021-05-07 09:49:28
|
alright, cool.
|
|
|
|
veluca
|
2021-05-07 09:49:38
|
I could see quite a few interesting challenges in trying that
|
|
|
|
Pieter
|
2021-05-07 09:50:05
|
i can imagine some of the inner algorithms being vhdl-amenable
|
|
2021-05-07 09:50:20
|
but most of it not really
|
|
|
|
veluca
|
2021-05-07 09:50:32
|
I would start accelerating only transforms and filters (the more conventional parts), then probably AC coefficient decoding
|
|
|
|
kbeckmann
|
2021-05-07 09:50:35
|
i'm currently in the process of doing a last-minute submission for the efabless open source asic multiproject and was thinking of cool ways to generate art with very few resources and a friend pointed my way here.
|
|
|
|
veluca
|
2021-05-07 09:50:46
|
Ehhhhh
|
|
2021-05-07 09:51:18
|
The way you generate jxl art is perhaps the least hardware friendly component of jxl ever
|
|
|
|
kbeckmann
|
2021-05-07 09:51:54
|
i see. i haven't looked into the inner workings yet,was hoping to get some understanding of the complexity by looking at some existing HDL :).
|
|
|
|
veluca
|
2021-05-07 09:52:19
|
Unless you have a fixed tree, I guess... But I'd leave that as the last part I would try to implement in hardware xD
|
|
|
|
kbeckmann
|
2021-05-07 09:53:27
|
i am extremely limited.. i have 300x300 um of space on a 5 layer 130nm technology. and we don't really have any ram at all, just flipflops basically. i might be able to hold a small command list buffer that can be updated in realtime from a risc-v management core.
|
|
|
|
veluca
|
2021-05-07 09:53:28
|
To give you an idea: you need to evaluate a decision tree per pixel, and the pixels are 100% serially dependent in tiles of size from 128x128 to 1024x1024 depending on the file
|
|
|
|
kbeckmann
|
2021-05-07 09:54:03
|
ah i see.. so not really like a fragment shader.
|
|
|
|
veluca
|
|
kbeckmann
i am extremely limited.. i have 300x300 um of space on a 5 layer 130nm technology. and we don't really have any ram at all, just flipflops basically. i might be able to hold a small command list buffer that can be updated in realtime from a risc-v management core.
|
|
2021-05-07 09:54:30
|
My hardware knowledge is not enough to distinguish that sentence from complete gibberish 🤣
|
|
|
|
kbeckmann
|
2021-05-07 09:54:41
|
sorry :). it's basically nothing.
|
|
|
|
veluca
|
2021-05-07 09:54:42
|
No, not at all
|
|
|
|
kbeckmann
|
2021-05-07 09:54:58
|
thanks for your explanation nonetheless!
|
|
2021-05-07 09:55:28
|
i might still write an FPGA implementation for this, sounds like a very cool algorithm.
|
|
|
|
veluca
|
2021-05-07 09:55:40
|
(I am curious though - but I never had time to look into hardware and/or FPGA)
|
|
|
|
kbeckmann
|
2021-05-07 09:56:06
|
it's very approachable now with the open source fpga tools and cheap development boards you can find.
|
|
|
|
veluca
|
2021-05-07 09:56:36
|
Ah, that's not the problem - the problem is that, in the end, there's only 24 hours in a day :P
|
|
|
|
kbeckmann
|
2021-05-07 09:56:45
|
haha yes for sure...
|
|
|
|
veluca
|
2021-05-07 09:57:18
|
Anyway, if at some point you want to try accelerating parts of JXL, I'd be happy to give you more insight in the format :) not today though :)
|
|
|
|
kbeckmann
|
2021-05-07 09:57:42
|
awesome, thanks. i might come back in a few weeks with more questions. nice talking to you!
|
|
|
|
_wb_
|
2021-05-07 09:59:02
|
A hw encoder for cameras would be interesting. Encoders can choose to only do hw friendly stuff, of course.
|
|
|
|
Pieter
|
2021-05-07 10:01:17
|
and it can use a fixed tree
|
|
|
|
_wb_
|
2021-05-07 10:01:23
|
A hw decoder of the full codec, I don't think it is really feasible. Parts of it, like the inverse transforms after entropy decoding, yes. But not the whole thing.
|
|
2021-05-07 10:02:07
|
Yes, fixed tree, prefix coding, simple block selection strategy, etc.
|
|
2021-05-07 10:04:18
|
Then again maybe software encode is fast enough if the camera has a decent cpu available anyway
|
|
|
|
veluca
|
2021-05-07 10:04:36
|
I do think that AC entropy decoding might be doable in hardware - if so, vardct decoding would be significantly faster... Modular mode, eh
|
|
2021-05-07 10:05:11
|
Although, it would need some pretty big caches
|
|
2021-05-07 10:06:36
|
I think CPU + GPU is a good way to get a very good encoding performance, a GPU can very likely speed up most of the encode bottleneck - it is pretty simple to parallelize on a GPU
|
|
|
|
necros
|
2021-05-08 05:24:34
|
re all, where can I get latest win binary?
|
|
2021-05-08 05:39:14
|
<@456226577798135808>Thanx man
|
|
|
|
raysar
|
2021-05-08 05:41:24
|
ok i update with your link
|
|
2021-05-08 05:44:22
|
Scope add also the lastest binary: https://encode.su/threads/3564-JXL-version-0-3-released?p=69598&viewfull=1#post69598
|
|
|
|
lithium
|
2021-05-08 07:36:37
|
I update some vardct quality issue for non-photographic image(drawing),
if need more information, please let me know 🙂
https://gitlab.com/wg1/jpeg-xl/-/issues/147#note_569956192
|
|
|
|
fab
|
2021-05-08 12:42:49
|
Q 94.13 s 5 epf 2 g 2 i 0.13 p 4 intensity 464
|
|
2021-05-08 12:43:16
|
To d 1.053 s 3
|
|
2021-05-08 12:43:56
|
Like jxl encoder is only one who can do stuff as this
|
|
2021-05-08 12:44:57
|
Like we ll See better generation loss
|
|
2021-05-08 12:45:05
|
Resistance
|
|
2021-05-08 12:45:32
|
And better quantization in the style of wp2
|
|
2021-05-08 12:46:03
|
In Next two commits
|
|
|
|
lithium
|
2021-05-08 06:14:02
|
<@!794205442175402004> Unfortunately... just really don't want to believe this,
You are right, it is xyb issue...
I tried cjxl -q 80 -s 7 -c 1, issue is fixed, but file size increase too much.
|
|
|
|
_wb_
|
2021-05-08 06:19:37
|
Well we don't have any decent encoder for non-XYB, and probably you still want to do some kind of color transform, which could be done via custom XYB matrix, via ICC profile, or doing the old YCbCr.
|
|
2021-05-08 06:19:59
|
Also not sure if that is really it
|
|
|
|
lithium
|
2021-05-08 06:20:17
|
oh, but -c 1 will produce new issue.
|
|
|
|
_wb_
|
2021-05-08 06:21:14
|
Could be -q 80 with -c 1 boils down to something that is just higher quality than default -q 90 and bigger, but not better than default -q 95 or whatever
|
|
2021-05-08 06:23:44
|
Point is there are a lot of things an encoder _could_ do, but the question is if we want to try to get the general default behavior to be good enough for various image content types, or if we want to do special presets to do things differently for e.g. photo vs non-photo
|
|
2021-05-08 06:24:21
|
I think we want to aim to have a "no human needed" approach where the default works for any image content
|
|
|
|
lithium
|
2021-05-08 06:26:45
|
I think use -c 1 isn't a good solve, will increase too much file size and produce new issue.
|
|
|
|
_wb_
|
2021-05-08 06:28:39
|
Yes it will certainly not solve the issue right now
|
|
|
|
lithium
|
2021-05-08 06:29:21
|
I just never thought XYB have issue,
probably have some chance to fix this issue?
|
|
|
BlueSwordM
|
2021-05-08 06:31:08
|
At this ultra small size, is this even fair though?
|
|
2021-05-08 06:31:16
|
Like, you're comparing a tiny image.
|
|
2021-05-08 06:31:42
|
The one that's most interesting is the red band.
|
|
|
|
lithium
|
|
BlueSwordM
At this ultra small size, is this even fair though?
|
|
2021-05-08 06:33:02
|
I also testing full version image, that just a sample 🙂
|
|
|
|
veluca
|
2021-05-08 06:33:43
|
don't do -c 1 vardct 😄
|
|
|
|
_wb_
|
2021-05-08 06:44:52
|
I don't think XYB has an issue, it's a great colorspace for perceptual compression. Just not completely sure if for artificial images that might use pure RGB colors (like #ff0000 red etc), it might be better to stay in RGB (or RGB-ish like SubtractGreen or something).
|
|
|
|
lithium
|
2021-05-08 06:46:48
|
probably like vardct ycocg?
|
|
|
|
veluca
|
2021-05-08 06:47:08
|
I don't think xyb is the issue here
|
|
2021-05-08 06:47:16
|
our heuristics, on the other hand...
|
|
|
|
_wb_
|
2021-05-08 06:48:19
|
We need to come up with heuristics other than repetition to subtract a modular thing from the image before doing vardct
|
|
|
|
lithium
|
|
veluca
I don't think xyb is the issue here
|
|
2021-05-08 06:48:37
|
ok, i understand, i will test other parameters.
|
|
|
|
_wb_
|
2021-05-08 06:48:43
|
Could get hard lines a lot better that way, potentially
|
|
|
|
diskorduser
|
2021-05-08 06:49:07
|
How about adding presets like webp encoder... ( One for photo and another for non photo)
|
|
|
|
_wb_
|
2021-05-08 06:49:30
|
I don't particularly like presets
|
|
2021-05-08 06:49:38
|
It's good for manual encoding
|
|
2021-05-08 06:50:08
|
Not if you are encoding 5000 images per second like we do at Cloudinary 😅
|
|
2021-05-08 06:50:28
|
Also, images can be a mix of several things
|
|
|
|
fab
|
2021-05-08 06:50:34
|
What you think of what i suggested
|
|
2021-05-08 06:50:57
|
|
|
2021-05-08 06:51:21
|
Is this possible in this month
|
|
2021-05-08 06:51:28
|
May
|
|
2021-05-08 06:51:43
|
Or it requires too effort to develop
|
|
|
|
Scope
|
2021-05-08 06:53:46
|
I think it's good to have an encoder with default settings for any content, but if someone needs a little more quality for a certain type of content, also have that option
|
|
|
|
fab
|
2021-05-08 06:55:22
|
I want to know how many time need to improve
|
|
2021-05-08 06:55:27
|
Jyrki
|
|
|
|
lithium
|
|
BlueSwordM
At this ultra small size, is this even fair though?
|
|
2021-05-08 06:56:09
|
Hello <@!321486891079696385>
Could you teach me some jxl encoder settings for this use case(anime)? 🙂
I think i have no idea, how to adjust this use case...
|
|
|
|
fab
|
2021-05-08 06:57:46
|
To me is should be as Close as wp2
|
|
2021-05-08 06:58:11
|
Like i Said in this screenshot
|
|
2021-05-08 06:58:26
|
Not too focus ed on jon perception
|
|
|
|
diskorduser
|
2021-05-08 06:58:39
|
Could you send me anime images in dm? I like to check the artifacts
|
|
|
|
lithium
|
|
diskorduser
Could you send me anime images in dm? I like to check the artifacts
|
|
2021-05-08 06:59:33
|
https://gitlab.com/wg1/jpeg-xl/-/issues/147
|
|
|
|
diskorduser
|
2021-05-08 07:01:03
|
Oh that thing. I started using avif for anime :p
|
|
|
|
lithium
|
2021-05-08 07:05:03
|
Actually i tested avif two month ago,
I think maybe i just made a mistake.
|
|
|
|
fab
|
2021-05-08 07:07:14
|
Avif 1902 should be bad
|
|
2021-05-08 07:07:43
|
Before that date av1 Quality should be worse
|
|
2021-05-08 07:08:48
|
Only Now avif start to be fast on full hd resolution and good Quality at effort 4 and 23.6 kb images
|
|
2021-05-08 07:09:04
|
So double webp compression on all cases
|
|
|
|
Deleted User
|
2021-05-08 07:32:09
|
You can use non-reversible color transforms (like XYB) in Modular, but can you use RCTs in VarDCT?
|
|
|
|
_wb_
|
2021-05-08 07:35:11
|
No
|
|
2021-05-08 07:35:22
|
RCTs are modular transforms
|
|
2021-05-08 07:35:45
|
(well I suppose you could use them for the DC)
|
|
|
|
veluca
|
2021-05-08 07:35:46
|
wellllll...
|
|
2021-05-08 07:36:03
|
you could also use them via defining funny primaries, no?
|
|
2021-05-08 07:36:23
|
in principle, at least
|
|
|
|
_wb_
|
|
|
fab
|
2021-05-08 07:37:00
|
No tools for anime
|
|
|
|
_wb_
|
2021-05-08 07:37:02
|
Or an icc profile
|
|
|
|
fab
|
2021-05-08 07:37:13
|
We first need a better encoder
|
|
|
|
_wb_
|
2021-05-08 07:37:15
|
Or a funky custom xyb matrix
|
|
|
|
veluca
|
2021-05-08 07:38:20
|
a custom xyb matrix and funny primaries are almost the same thing 😛 and ICC is kinda the same too
|
|
|
|
Deleted User
|
|
diskorduser
Could you send me anime images in dm? I like to check the artifacts
|
|
2021-05-08 07:53:38
|
Then let's hope the artifacts are at the right places on Lees hentai pics. 😁 <:ugly:805106754668068868>
|
|
|
|
improver
|
2021-05-08 09:29:35
|
v important use case t b h
|
|
2021-05-08 09:53:01
|
what are "recommended" distance/quality levels one shouldn't expect too much ringing artifacts on anyway?
|
|
|
|
Crixis
|
|
improver
what are "recommended" distance/quality levels one shouldn't expect too much ringing artifacts on anyway?
|
|
2021-05-08 09:57:20
|
Standard d 1
|
|
2021-05-08 09:57:30
|
For no zoom
|
|
|
|
Scope
|
2021-05-08 09:58:51
|
For Art something like -d 0.7, -d 0.5 (because ringing artifacts are very noticeable on the clear lines), but if it is a complex image without solid color backgrounds etc., then -d 1 is also ok
|
|
|
|
Crixis
|
2021-05-08 10:00:30
|
For web d 2 is a good quality
|
|
|
|
Scope
|
|
|
fab
|
2021-05-09 05:40:03
|
Q 95.6128 x 74.81 p7 y 9.42 -gaborish 1 -epf 1
|
|
2021-05-09 05:40:13
|
With 04052021 jxl
|
|
2021-05-09 05:40:27
|
The one in squoosh But modular
|
|
2021-05-09 05:40:56
|
Then you do avif q18 speed 9 with a good 10052021 encoder
|
|
2021-05-09 05:41:24
|
You will have an image sharper than original
|
|
2021-05-09 05:42:50
|
Or use q 95.6528
|
|
2021-05-09 05:43:25
|
Dont know if gaborish 1 helps in that case
|
|
2021-05-09 05:43:42
|
I'll ask wb
|
|
2021-05-09 05:44:53
|
Anyway even with exhale encoder i can fix bad mastered opus
|
|
2021-05-09 05:45:06
|
And I know tricks to do sbr
|
|
2021-05-09 05:45:20
|
Opus to sbr is efficient
|
|
2021-05-09 05:45:32
|
But thats the wrong Way
|
|
|
|
lithium
|
2021-05-09 06:17:11
|
<@456226577798135808> <@456226577798135808>
About my anime image test, i want make sure my sample have diversity and general, so i collect different anime drawing style from different source.
In my test, i use different image quality assessment metrics to check compressed image, and some specific image i will check with my eyes.
Anyway, I plan stop this test, and close my gitlab issue.
|
|
|
|
raysar
|
2021-05-09 07:01:10
|
I have an example to justify an variable quality in one picture, photosphere
Example i take, you can see all around the picture is stitch and don't need same quality than the center.
The picture is made to be see in a photoshere software.
Is it hard to create this type of option in the encoder?
|
|
|
|
_wb_
|
2021-05-09 07:03:58
|
It is work, but the bitstream has everything needed to do it.
|
|
2021-05-09 07:04:53
|
In this particular case it would be best if the projection would somehow be taken into account in the perceptual optimization iterations.
|
|
|
|
veluca
|
2021-05-09 07:05:29
|
is it work? at least a first version could be rather easy, and just scale the quantization field by an user-given quality field...
|
|
|
|
Pieter
|
2021-05-09 07:06:28
|
In a photosphere you mostly want variable spacial accuracy than variable quantization.
|
|
2021-05-09 07:06:56
|
I feel like that's probably doable too, at least in squeeze mode (but that's for modular only?)
|
|
|
|
_wb_
|
2021-05-09 07:07:41
|
Oh, so just do everything as if it is min-dist, but then bump up the quantization according to the heatmap?
|
|
|
|
veluca
|
2021-05-09 07:08:56
|
yeah - after all, the quant field is always the same, just scaled to adapt to quality, from what I remember (this is of course probably wrong...)
|
|
2021-05-09 07:09:29
|
but even if that were not the case, it could still be done relatively easily
|
|
|
|
_wb_
|
2021-05-09 07:10:04
|
For 360 projections it would make sense to select vardct block sizes taking the projection into account (the projection distortion on the image will cause that naturally but it might be better to explicitly take it into account)
|
|
2021-05-09 07:11:32
|
Besides the quantfield there's also the block selection, where you may want to use bigger blocks in 'unimportant' regions
|
|
|
|
veluca
|
2021-05-09 07:12:46
|
yeah, but that's also taken into account somewhat already
|
|
|
|
_wb_
|
2021-05-09 07:13:08
|
But there too it should be easy to let the heuristics use say the average heat of the group as a target distance, instead of the global distance target
|
|
|
|
veluca
|
2021-05-09 07:13:09
|
the quantizer and amount of visual masking control what happens during dct blocks
|
|
2021-05-09 07:13:43
|
(the distance is only used to produce a very simple cost model for coefficients, it's likely not too important to get it right)
|
|
2021-05-09 07:14:31
|
well, also used to estimate a starting point for the heuristic
|
|
|
|
_wb_
|
2021-05-09 07:17:37
|
Our AI team is working on fast saliency models that produce heatmaps. Our current "saliency based compression" basically just slightly blurs the unimportant regions, which for JPEG/WebP is an easy way to let it compress better (at the cost of course of losing some detail in some regions)
|
|
2021-05-09 07:19:51
|
If we can instead of slightly blurring, adjust the jxl quality, I think it might give more compression gains for less loss of detail.
|
|
2021-05-09 07:22:22
|
(could also do something similar to the slight blurring by not or less strongly doing the encoder fwd gaborish sharpening in the unimportant regions, I suppose)
|
|
2021-05-09 07:22:59
|
(while still doing it in the decoder of course)
|
|
2021-05-09 07:25:57
|
They get quite good saliency maps at on-the-fly speeds btw. They used similar stuff as what they have for AI-based background removal, but it can be a lot faster since pixel precision is not at all required.
|
|
2021-05-09 07:27:23
|
The AI stuff is getting scarily good at some tasks.
|
|
2021-05-09 07:28:58
|
I sometimes feel like a dinosaur who still prefers the old school classical algorithms and heuristics, haha
|
|
|
|
raysar
|
2021-05-09 08:29:40
|
Maybe you can ask the question to google team of street view? 😄 i'm shure they have create someting to optimiser encoding photosphere pictures 😄
|
|
|
|
Deleted User
|
2021-05-09 08:30:47
|
I'm still waiting for Google Photos JPEG XL beta tests...
|
|
|
|
raysar
|
2021-05-09 08:33:10
|
I think we can also ask they what jpeg encoder they are using, it's very low bpp jpeg on google map but there is no horrible dct8x8 artifacts, it look like banding artifact it's strange 😼 (and i prefer that)
|
|
2021-05-09 08:36:09
|
I post a picture on "other-codecs" to speak about that if you can explain me their tricks 😄
|
|
|
|
Petr
|
2021-05-10 07:17:27
|
When talking about quantization / dithering, have you tried Spatial Color Quantization?
|
|
2021-05-10 07:17:37
|
I used scolorq (https://people.eecs.berkeley.edu/~dcoetzee/downloads/scolorq/) a while ago.
|
|
2021-05-10 07:17:48
|
And the results were impressive (physical example: https://translate.google.com/translate?sl=cs&tl=en&u=https://www.mozaikar.cz/pozoruhodna-mozaika-2/).
|
|
|
|
_wb_
|
2021-05-10 07:38:13
|
looks good but overkill for dithering to RGB888 and probably way too slow
|
|
|
|
Petr
|
2021-05-10 07:49:03
|
Yes, it's slow. I mentioned it just in case someone would find it interesting for jxl.
|
|
|
|
_wb_
|
2021-05-10 07:52:37
|
hm, `djpeg` from libjpeg-turbo has the following options:
```
-dither fs Use F-S dithering (default)
-dither none Don't use dithering in quantization
-dither ordered Use ordered dither (medium speed, quality)
```
|
|
2021-05-10 08:14:57
|
ah but that's not for RGB888 dithering
|
|
2021-05-10 08:15:02
|
```
-colors N Reduce image to no more than N colors
```
|
|
2021-05-10 08:15:45
|
libjpeg-turbo has built in color quantization / palette creation
|
|
2021-05-10 08:16:39
|
probably because this software dates back to the early nineties when "true color" displays were still rare, and many were still running in 256-color or 65536-color mode...
|
|
2021-05-10 08:17:24
|
(one more reason to eventually try to get rid of libjpeg-turbo for jpeg decoding: we don't need that kind of legacy functionality anymore)
|
|
|
|
Deleted User
|
|
Petr
I used scolorq (https://people.eecs.berkeley.edu/~dcoetzee/downloads/scolorq/) a while ago.
|
|
2021-05-10 12:54:21
|
Any comparison with pngquant? I'm really curious to compare them...
|
|
|
|
Petr
|
|
Any comparison with pngquant? I'm really curious to compare them...
|
|
2021-05-10 01:16:22
|
I haven't done any exhaustive comparison. I simply liked the idea and the output. It's interesting that it does different output for the same input on every run.
|
|
2021-05-10 01:16:32
|
Later the Windows binary of scolorq stopped producing reasonable output. I don't use it anymore. Maybe someone here will be able to revive it… 😉
|
|
|
|
Deleted User
|
|
Petr
And the results were impressive (physical example: https://translate.google.com/translate?sl=cs&tl=en&u=https://www.mozaikar.cz/pozoruhodna-mozaika-2/).
|
|
2021-05-10 01:22:03
|
And cool mosaic, by the way!
|
|
|
|
Troc
|
2021-05-10 03:59:00
|
Is MegaPixel QT a good or bad way to encode pictures into JPGXL?
|
|
|
|
BlueSwordM
|
2021-05-10 04:04:16
|
It's just fine.
|
|
|
|
Troc
|
2021-05-10 04:14:45
|
Hasn't been updated in a bit so I figured I'd ask.
|
|
|
|
raysar
|
2021-05-10 07:42:34
|
` -q N, --jpeg_quality=N
JPEG output quality. Setting an output quality implies --pixels_to_jpeg.`
djxl use libjpeg to re-encode in jpeg? (no mozjpeg?) and no jpeg option are possible?
|
|
|
|
_wb_
|
2021-05-10 08:26:57
|
It's just a convenience option, but I don't really see a reason to decode to jpeg if it's not a reconstructed jpeg
|
|
|
|
raysar
|
2021-05-10 09:00:44
|
For example my lossless file are jxl and i export it in lower quality for sharing for friends or for my phone. Without using imagemagick :p
|
|
|
|
_wb_
|
2021-05-10 09:11:42
|
I suppose if you install mozjpeg instead of libjpeg-turbo, and compile djxl to use libjpeg, you can get mozjpeg encodes with djxl...
|
|
|
|
raysar
|
|
_wb_
I suppose if you install mozjpeg instead of libjpeg-turbo, and compile djxl to use libjpeg, you can get mozjpeg encodes with djxl...
|
|
2021-05-10 09:28:44
|
Smart 🤓
|
|
|
|
fab
|
2021-05-11 06:57:23
|
do you have 9a8f5195 for sse4
|
|
2021-05-11 06:57:24
|
please
|
|
2021-05-11 06:57:28
|
04052021 build
|
|
2021-05-11 08:14:59
|
best parameters for jxl
|
|
2021-05-11 08:15:00
|
for %i in (C:\Users\User\Documents\pl\*.png) do cjxl -q 89.36 -s 7 --progressive --faster_decoding=1 --epf=2 %i %i.jxl
|
|
2021-05-11 08:15:14
|
414 kb mozjpeg
|
|
2021-05-11 08:15:18
|
537 jpeg xl squoosh
|
|
2021-05-11 08:15:25
|
382 with this
|
|
2021-05-11 08:16:57
|
|
|
2021-05-11 08:17:11
|
|
|
2021-05-11 08:19:50
|
this is like a benchmark
|
|
|
|
Deleted User
|
|
fab
best parameters for jxl
|
|
2021-05-11 08:24:44
|
#wrong-channel
|
|
|
|
fab
|
2021-05-12 06:43:12
|
for -q 89.36 it compress good
|
|
2021-05-12 06:43:39
|
in encode params i posted parameters specific for thumbnail artwork music
|
|
2021-05-12 06:43:59
|
the encoder is making better decisions
|
|
2021-05-12 07:14:29
|
is interesting that squoosh can compress (it can't)
|
|
2021-05-12 07:15:19
|
i did with scope build
|
|
|
|
_wb_
|
|
fab
for %i in (C:\Users\User\Documents\pl\*.png) do cjxl -q 89.36 -s 7 --progressive --faster_decoding=1 --epf=2 %i %i.jxl
|
|
2021-05-12 07:27:02
|
Please keep these for <#840831132009365514>
|
|
|
|
fab
|
|
|
raysar
|
2021-05-14 07:42:57
|
I don't see that question for dev:
Have you avoid any great or better algorithm because of a patent ? Or technical solution for jxl are the "best compromise" for an image codec ❓(about the lossy part)
|
|
|
|
Scientia
|
2021-05-14 07:45:31
|
I don't think there's a single great algorithm that was avoided
|
|
2021-05-14 07:45:37
|
probably a lot of little pieces
|
|
2021-05-14 07:45:43
|
that they couldn't use
|
|
|
|
raysar
|
2021-05-14 07:48:53
|
Yes i understand there are many type of optimisations to do a powerfull lossy image.
|
|
|
|
_wb_
|
2021-05-14 07:50:01
|
That's a good question. I don't think we actually were in a situation where we could have used something but didn't because of patents. Most of the things in jxl are either old (like the DCT), newish but not patented (like ANS), or invented by us, afaik.
|
|
|
|
Scientia
|
2021-05-14 07:50:37
|
that's interesting
|
|
|
|
_wb_
|
2021-05-14 07:58:19
|
The biggest patent minefields are in video codecs, afaiu. There is some spillover from that to image codecs, but largely the widely adopted image codecs have always been royalty-free (with the notable exceptions of GIF and HEIC).
|
|
|
|
raysar
|
2021-05-14 08:00:36
|
I need to learn how heic and avif codec works, it's a mysterious technology 🧐
|
|
|
|
Scientia
|
|
raysar
I need to learn how heic and avif codec works, it's a mysterious technology 🧐
|
|
2021-05-14 08:03:12
|
You can learn about how they work and more
|
|
2021-05-14 08:03:33
|
They're both just keyframes from hevc and av1 respectively
|
|
2021-05-14 08:03:52
|
If you learn about how those codecs work, specifically their keyframes
|
|
2021-05-14 08:04:06
|
Then you'll know how avif and heic work
|
|
|
|
raysar
|
|
Scientia
They're both just keyframes from hevc and av1 respectively
|
|
2021-05-14 08:06:48
|
Yes i see many conferences about codec video, i understand basic math about the p frame and many tricks for video. But about the i frame there not very details. They like patch, and removing noise, that's all i know 😆
|
|
|
|
veluca
|
|
_wb_
The biggest patent minefields are in video codecs, afaiu. There is some spillover from that to image codecs, but largely the widely adopted image codecs have always been royalty-free (with the notable exceptions of GIF and HEIC).
|
|
2021-05-14 08:43:39
|
What about AC JPEGs? :p
|
|
|
|
_wb_
|
2021-05-14 08:47:58
|
AC JPEG was never a widely adopted image codec 😛
|
|
|
|
veluca
|
2021-05-14 08:49:41
|
well, *because of* patents IIRC
|
|
|
|
_wb_
|
2021-05-14 08:51:16
|
Yes
|
|
2021-05-14 08:51:59
|
But we didn't avoid AC in jxl because of patents (they are expired), but because ANS was just better
|
|
2021-05-14 08:54:19
|
(we had the original flif MANIAC, which is an evolved kind of AC, in jxl originally, but we ended up with a more powerful single entropy coder that combines all the best things from all the entropy coders we used to have)
|
|
|
|
veluca
|
2021-05-14 08:55:55
|
yes, I didn't imply that 😛
|
|
|
|
Pieter
|
2021-05-14 08:57:13
|
well ANS has some disadvantages compared to AC no? like needing to buffer all symbols at encode time, because they're processed in reverse order?
|
|
|
|
veluca
|
|
|
Petr
|
2021-05-14 09:16:41
|
What's the meaning of "AC" in the recent messages? Is it as described here? https://stackoverflow.com/questions/18679987/what-is-the-meaning-of-dc-and-ac-in-jpeg-file#18684750
|
|
|
|
veluca
|
2021-05-14 09:18:49
|
no in this case I meant Arithmetic Coding
|
|
|
|
Petr
|
|
veluca
no in this case I meant Arithmetic Coding
|
|
2021-05-14 09:21:39
|
It makes sense now, thanks. I need to get used to these 2 meanings of 1 acronym. 🙂
|
|
|
|
_wb_
|
2021-05-14 09:22:43
|
Washington AC
|
|
|
|
improver
|
2021-05-14 09:31:01
|
iirc xface uses ac too
|
|
|
|
Petr
|
2021-05-14 09:45:24
|
I updated https://en.wikipedia.org/wiki/AC as an attempt to decrease confusion of other people. 🙂
|
|
2021-05-14 09:45:55
|
And also https://en.wikipedia.org/wiki/DC
|
|
|
Maiki3
|
2021-05-14 11:36:16
|
|
|
2021-05-14 11:36:57
|
congrats <@!794205442175402004> for getting JXL support added to chrome, msedge chromium, and firefox. I know I'm late and you are already well aware of this, but nevertheless, great job.
|
|
|
|
Crixis
|
|
Maiki3
|
|
2021-05-14 11:42:15
|
but this is edge
|
|
|
|
_wb_
|
|
Maiki3
congrats <@!794205442175402004> for getting JXL support added to chrome, msedge chromium, and firefox. I know I'm late and you are already well aware of this, but nevertheless, great job.
|
|
2021-05-14 11:48:04
|
Don't congratulate me, it's <@795684063032901642> and <@768090355546587137> and <@179701849576833024> doing the chromium integration and <@239702523559018497> doing the firefox one
|
|
2021-05-14 11:53:00
|
I mostly just stand on the sidelines and cheer, when it comes to browser integration 😂
|
|
|
Lastrosade
|
2021-05-14 08:00:27
|
hey hey ppl, I have an issue where cjxl won't read files that have filenames with japanese characters in them
|
|
|
|
veluca
|
2021-05-14 08:08:21
|
ugh
|
|
2021-05-14 08:08:24
|
on windows?
|
|
|
|
Lastrosade
|
2021-05-14 08:10:44
|
yes
|
|
2021-05-14 08:11:03
|
ffmpeg / imagemagick work fine
|
|
2021-05-14 08:11:15
|
cwebp and cjxl do not
|
|
|
|
Pieter
|
2021-05-14 08:12:09
|
unicode filename handling on windows is a pain
|
|
|
|
veluca
|
2021-05-14 08:17:35
|
probably a mixup of utf-8 and whatever non-utf8 thing that windows does
|
|
2021-05-14 08:17:41
|
maybe file an issue?
|
|
|
|
Lastrosade
|
2021-05-14 08:18:09
|
The files are fine
|
|
2021-05-14 08:18:13
|
ffmpeg works perfectly on them
|
|
2021-05-14 08:18:32
|
ahh I'm getting the same problem with ect now
|
|
|
|
veluca
|
2021-05-14 08:18:38
|
I mean a mixup in cjxl 😛
|
|
|
|
Pieter
|
2021-05-14 08:19:05
|
windows API has separate functions for iirc 8-bit filenames in the configured codepage, and functions that take 16-bit utf16
|
|
|
|
Lastrosade
|
2021-05-14 08:19:12
|
yeah windows likes to move things to and from utf8/utf16
|
|
2021-05-14 08:19:24
|
and there is this thing about the BOM
|
|
2021-05-14 08:22:38
|
yeah so the problem might not be with cjxl then
|
|
|
|
improver
|
2021-05-15 12:39:27
|
nah its probably w jxl but its because windows apis are pain
|
|
2021-05-15 12:39:47
|
filenames dont do BOMs iirc
|
|
|
|
Pieter
|
2021-05-15 01:00:49
|
No need for a BOM in UTF-16 IIRC?
|
|
2021-05-15 01:01:42
|
Oh, of course it still is, but I assume the byte order is implicit in the API.
|
|
|
|
improver
|
2021-05-15 10:52:35
|
BOMs are needed to aid detection of UTF-16 and its kind (LE/BE), but that shouldn't be needed on the file system level as they probably have single kind of filename encoding across the whole thing
|
|
|
VEG
|
|
Pieter
unicode filename handling on windows is a pain
|
|
2021-05-15 11:21:18
|
If UTF-16 versions of functions are used, it works fine. UTF-16 is native for Windows NT.
|
|
2021-05-15 11:25:10
|
All the other charsets (when ANSI versions of functions are used) are always converted to UTF-16 internally.
|
|
2021-05-15 11:27:09
|
It would be easier to code if UTF-8 were used as the native representation of strings, but Windows NT was designed before UTF-8 was created. At that time people thought that UTF-16 is the future, and ASCII-compatible charsets will eventually become obsolete.
|
|