JPEG XL

Info

rules 57
github 35276
reddit 647

JPEG XL

tools 4225
website 1655
adoption 20712
nomacs 7
UI 11
chrome 34
image-compression-forum 0

General chat

welcome 3810
introduce-yourself 291
color 1414
photography 3435
other-codecs 23765
on-topic 24923
off-topic 22701

Voice Channels

General 2147

Archived

bot-spam 4380

jxl

Anything JPEG XL related

raysar
 spider-mario has it ever not been the case?
2021-05-20 12:46:14
Default d1 is around the same size than d0 on screenshot and art, i vote to have lossless by default with PNG 😝
2021-05-20 12:47:19
take a screenshot and test
fab
2021-05-20 12:47:30
usually is similar like a 210 kb 360 kb
2021-05-20 12:47:34
on galaxy s4 screenshots
spider-mario
2021-05-20 12:47:37
trying both and keeping the lossless output if it’s at most “not too much bigger” is something that we could consider at slower speeds
fab
2021-05-20 12:48:06
on youtube music screenshots it has more difference
2021-05-20 12:48:14
because there are big pictures
2021-05-20 12:48:38
430 mb lossless
2021-05-20 12:48:41
160 mb lossy
2021-05-20 12:48:46
like that a folder you will get
2021-05-20 12:48:55
the average
2021-05-20 12:49:01
with galaxy s4 screenshots
raysar
 fab 430 mb lossless
2021-05-20 12:49:15
FABIAN, USE THE SHIFT + ENTER to send multiple message ! and write real sentences ! i am not a robot.
_wb_
 spider-mario as far as I can tell, there is little point in encoding it lossily, it’s efficient enough to represent losslessly
2021-05-20 12:51:09
the philosophy is: if it's already lossy, don't introduce extra loss by default to avoid accumulating artifacts. So JPEG gets lossless recompression, GIF (which was likely color-reduced, which is a kind of lossy) gets lossless recompression. If the input is PNG, we assume it's not already lossy, so the default is to do visually-lossless (-d 1) lossy compression on it.
fab
2021-05-20 12:51:09
and original folder would weight 710 mb
2021-05-20 12:51:42
the one wb made is proper english
raysar
 _wb_ the philosophy is: if it's already lossy, don't introduce extra loss by default to avoid accumulating artifacts. So JPEG gets lossless recompression, GIF (which was likely color-reduced, which is a kind of lossy) gets lossless recompression. If the input is PNG, we assume it's not already lossy, so the default is to do visually-lossless (-d 1) lossy compression on it.
2021-05-20 12:58:19
Ok, i understand.
jjido
2021-05-20 01:05:53
So GIF converted in JPEG XL lossy is bad quality, while converted in JPEG XL lossless does not take more space?
veluca
2021-05-20 01:07:42
0xFF 0x0A : 0x0A is a newline and should cause stuff to break if you open the file in translate-newlines mode
2021-05-20 01:07:58
0xFF is just what JPEG typically uses for markers
2021-05-20 01:08:40
as for why not ASCII: it's harder to have non-jxl files be interpreted as JXL files like this
diskorduser
2021-05-20 01:31:46
I tried to encode a 1312x30297 PNG and Cjxl terminated. Is it a ram related problem?
2021-05-20 01:31:59
-s 7 -d 1
Scope
2021-05-20 01:32:44
Most likely RAM
diskorduser
2021-05-20 01:33:03
-s 6 works
2021-05-20 01:33:19
2.1 mb PNG
2021-05-20 01:34:28
Just 4gb
2021-05-20 01:36:59
I already have 2gb zram
2021-05-20 01:37:18
Probably it needs 8gb ram I think
_wb_
2021-05-20 01:38:42
Try -s 3
diskorduser
2021-05-20 01:39:06
-s 6 works.
_wb_
2021-05-20 01:39:27
Can also try -I 0.1
2021-05-20 01:42:14
It's a lot worse for lossless than for lossy
veluca
2021-05-20 02:04:29
I believe -s 4 to -s 6 will be more or less 24 bytes per pixel
2021-05-20 02:05:02
-s 7 will be more if there's anything resembling patches
2021-05-20 02:05:28
-s 3 should be about 12 or so
2021-05-20 02:05:39
and -s 8+, $a_lot
2021-05-20 02:05:41
(for lossy)
monad
2021-05-20 02:09:07
I'm hoping one day there's an encoder with reduced RAM requirements that allows me to encode all my images--but if it takes too long I may upgrade before that.
fab
2021-05-20 02:42:10
Can you write alb in Bot spam
2021-05-20 02:42:19
One of You
2021-05-20 02:44:19
Ok done
Troc
 monad I'm hoping one day there's an encoder with reduced RAM requirements that allows me to encode all my images--but if it takes too long I may upgrade before that.
2021-05-20 05:16:52
How many pictures do you have and which resolution?
monad
2021-05-20 05:24:11
The smallest image I have that I can't encode is 10240x15360 pixels and I have several larger. Not too many, but it would be nice to save the probable ~35% on a 400 MB image.
2021-05-20 05:26:25
That smaller one actually fits within WebP's limitations though. The larger ones are PNGs.
2021-05-20 06:26:46
I haven't actually started converting my collection yet, just done tests. My use case is overwhelmingly lossless archival, so I've been patient between waiting for the format to freeze, metadata support to improve, and any bugs to be resolved. Broader software support is desirable as well. Plus, I anticipate some efficiency improvements in modular and with over 100,000 images I only want to encode everything once.
veluca
2021-05-20 06:29:58
the format *is* frozen 🙂 but you're right on the improvements for modulars...
monad
2021-05-20 06:30:51
Well, it wasn't always.
_wb_
2021-05-20 06:42:46
it's frozen for half a year now
2021-05-20 06:43:00
(the codestream at least)
2021-05-20 06:43:25
(the container is frozen for a month or so now, but you usually don't need that)
monad
2021-05-20 06:59:33
Not being an expert, I was waiting for the container freeze as well to ensure I had forward-compatible files. As I understand it, jpeg recompression uses the container and it seemed like metadata handling might've been in flux.
2021-05-20 07:01:11
If my other reasons for waiting are invalid and I can assume I have lossless encoding for arbitrary image files with the latest cjxl, that would be great to hear.
veluca
2021-05-20 07:01:32
I believe in practice we didn't change anything in a non-bw-compatible way even in the container for a few months 🙂
2021-05-20 07:02:37
if you're willing to wait, and to spend more computational time that you otherwise would, I have plans for a few improvements to lossless compression heuristics that I might be able to implement in the next month or two
monad
2021-05-20 07:04:06
Definitely willing to wait, since I'm mostly doing long-term storage.
2021-05-20 07:04:52
But I'm also naturally antsy. ;-)
KAGAMI
2021-05-20 07:26:08
Hey people, I just found that IANA have a page for AVIF but not for JXL. https://www.iana.org/assignments/media-types/image/avif why is that, do they want to wait for final specification for JXL?
2021-05-20 07:27:38
(I found that from mime-db https://github.com/jshttp/mime-db/blame/d80f8970aebc5b0c901b519570e93948aa9162fa/src/iana-types.json#L8608)
_wb_
 KAGAMI Hey people, I just found that IANA have a page for AVIF but not for JXL. https://www.iana.org/assignments/media-types/image/avif why is that, do they want to wait for final specification for JXL?
2021-05-20 07:35:13
We're here: https://www.iana.org/assignments/provisional-standard-media-types/provisional-standard-media-types.xhtml
2021-05-20 07:35:30
I assume they wait for publication of the ISO standard, I dunno
2021-05-20 07:35:48
The media type is not going to change though
2021-05-20 07:36:12
So best to update all mime dbs out there
2021-05-20 07:37:20
Especially since some people want to get rid of client-side magic sniffing and make things only work if the server does the magic sniffing and gives a correct `Content-encoding`
KAGAMI
2021-05-20 08:12:00
Right, better to prepare as early as possible
2021-05-20 08:17:28
Seems both Apache and Nginx have no AVIF and JXL https://github.com/jshttp/mime-db#data-structure
veluca
2021-05-20 08:21:09
how many of those databases exist? really!
2021-05-20 08:21:23
I already sent CLs to like 4
2021-05-20 08:21:30
or someone else did
2021-05-20 08:22:01
anyway, at least on arch linux nginx *has* jxl as a mime type for *some* reason
2021-05-20 08:23:09
ah, because it's taken from mailcap, one of those that I did patch
_wb_
2021-05-20 08:23:38
I would expect IANA to have a masterlist where all the others get their truth, what's the point of having a central registration authority otherwise?
veluca
2021-05-20 08:25:24
spoiler: not true
2021-05-20 08:28:26
application/wasm was added ~12 days ago to nginx, perhaps the file in nginx doesn't really get used
_wb_
2021-05-20 08:29:06
Are those dbs based just on extensions, or on magic?
veluca
2021-05-20 08:29:26
there's all kinds 🙂
_wb_
2021-05-21 07:00:31
http://www.digipres.org/formats/mime-types/
2021-05-21 07:02:22
that one is interesting because it is a "meta" mime-type-db based on 6 sources, going to try to open issues to add image/jxl on all 6 of them
2021-05-21 07:09:07
https://issues.apache.org/jira/browse/TIKA-3411
2021-05-21 07:16:40
it is amazing how hard it is to get a new media type added to all the places — why can't they all just do a daily sync with IANA instead of waiting for manual input?
2021-05-21 07:35:39
http://fileformats.archiveteam.org/index.php?title=JPEG_XL&diff=39858&oldid=38290
2021-05-21 07:36:14
maybe, but I somehow doubt it
2021-05-21 07:40:13
2021-05-21 07:46:03
sent an email to the Library of Congress format descriptions maintainers (https://www.loc.gov/preservation/digital/formats/index.html)
2021-05-21 02:20:40
https://issues.apache.org/jira/browse/TIKA-3411 they want to add the long header but not the short one, ugh I hope I can change their opinion
2021-05-21 02:26:26
https://github.com/mime-types/mime-types-data/pull/43
2021-05-21 02:27:36
how many of these mime-type lists are there?
veluca
2021-05-21 02:36:38
I lost count
improver
2021-05-21 02:36:39
many many
2021-05-21 02:37:05
https://github.com/gabriel-vasile/mimetype/blob/master/tree.go one more. i think this one is used by ipfs
2021-05-21 02:50:05
https://www.garykessler.net/library/file_sigs.html
_wb_
2021-05-21 02:57:43
https://github.com/gabriel-vasile/mimetype/issues/154
2021-05-21 03:00:53
mailed Gary Kessler
2021-05-21 03:07:08
hm, how to get in here by default? https://github.com/file/file
2021-05-21 03:07:41
`Match of <= 16 bits are not accepted`
2021-05-21 03:07:43
hm
2021-05-21 03:12:20
oh nevermind
2021-05-21 03:12:21
https://github.com/file/file/blob/master/magic/Magdir/jpeg#L135
2021-05-21 03:12:24
we're already there
veluca
2021-05-21 03:53:04
"# JPEG XL (transcoded JPEG file)" mhhh
_wb_
2021-05-21 04:02:06
The comment is wrong but the actual string is ok, meh
Scope
2021-05-21 06:42:39
> Update JPEG-XL with latest changes. Are there any changes in lossless?
veluca
2021-05-21 06:45:35
nope
BlueSwordM
2021-05-21 06:49:10
What are the main changes?
Scope
2021-05-21 06:50:15
`--effort` <:JXL:805850130203934781>
BlueSwordM
2021-05-21 06:51:31
Niice.
2021-05-21 06:51:37
Going to upgrade right away then.
2021-05-21 06:56:43
Oh no.
2021-05-21 06:56:53
That change is going to break some of my scripts 😆
veluca
2021-05-21 06:57:17
-s still works 😛
lithium
2021-05-21 07:14:28
grayscale_patches_on_splines.png, what is this? ```https://gitlab.com/wg1/jpeg-xl/-/blob/44778c6902084bd239c5fb8eaa53bfd90dd9face/third_party/testdata/jxl/blending/grayscale_patches_on_splines.png```
veluca
2021-05-21 07:15:38
random chunk of a screenshot to test stuff 😛
lithium
2021-05-21 07:16:23
oh, I understand 🙂
spider-mario
2021-05-21 07:17:20
we wanted a test for blending, we needed test data for that, we had previous test data for patches and for splines
2021-05-21 07:17:27
“let’s test the blending of one onto the other”
2021-05-21 07:17:29
and that’s it
Troc
2021-05-21 09:12:41
Fabian said that there's a new new JpegXL.
2021-05-21 09:12:47
What's going on?
_wb_
2021-05-21 09:18:19
?
2021-05-21 09:18:37
there's bugfixes and stuff every week or so
2021-05-21 09:18:54
other than that I don't know what could be this new new jxl
diskorduser
2021-05-21 11:38:08
New new jxl coming from undercover developer fabian
2021-05-21 11:41:16
It's called fxl. Fabian XL image format
veluca
2021-05-21 11:55:18
parameters with less than 5 significant digits are ignored 😛
jjido
2021-05-22 12:07:24
if you pass unknown parameter, the encoder makes on-the-spot a new use for it
fab
2021-05-22 02:54:24
another question do you use jxl arts in png or jpegs from internet or from a conformance testing
2021-05-22 02:54:30
when encoding to a dev libjxl
2021-05-22 02:55:14
or you use only the image ISO gave to you?
2021-05-22 02:55:37
how this work is done by image researchers?
2021-05-22 02:55:51
what is the right way?
_wb_
2021-05-22 03:06:25
For conformance testing we only need to test all technical components of a decoder
fab
2021-05-22 03:06:44
no when you tweak heuristic
_wb_
2021-05-22 03:07:55
I don't know what others do, but you typically use some small test corpus while making tweaks
2021-05-22 03:13:27
For quality tuning, it's best to use a representative corpus, to the extent that that can be done
2021-05-22 03:14:13
And also to use lossless sources, we're not trying to be an artifact remover for existing codecs
lithium
2021-05-23 09:16:51
Butteraugli_guetzli, Butteraugli_github, Butteraugli_PIK target distance compare Butteraugli_jxl target distance Is there have a big difference? like on Butteraugli_guetzli target distance, you can't lower q84(jxl -d 1.45|-q 85).
_wb_
2021-05-23 09:22:31
I think those Butteraugli variants do have some differences, no idea if the difference is big or small. The jxl one should be the most recent one so I assume it's the 'best' one.
2021-05-23 09:24:38
Target distances are only a target, where the goal is to end up close to the target but this rarely happens exactly, especially in the faster settings where you cannot afford to do iterations of encode / metric compute / encode again / ...
lithium
2021-05-23 09:27:45
I collect some Butteraugli distance data from old version Butteraugli, but this guidelines can't match Butteraugli_jxl.
fab
2021-05-23 02:19:08
can you send 100e3c7e jpeg xl for windows?
2021-05-23 02:19:09
thanks
2021-05-23 02:19:13
but i want it now
2021-05-23 02:23:58
cjxl only i need
lithium
2021-05-23 02:27:05
I remove 100e3c7e, I will upload cjxl 44778c69 on <#803663417881395200>
fab
2021-05-23 02:28:12
no i need that exact commit
2021-05-23 02:28:16
please if you have
2021-05-23 02:28:22
i need to encode only one photo
2021-05-23 02:28:31
i will download also that
diskorduser
2021-05-23 07:34:04
Use b612
2021-05-23 07:34:53
Or facetune or something
2021-05-23 07:36:19
Why Fabian, why did you delete 😣
fab
2021-05-23 07:36:49
i'm confused if jpeg xl meet my needs or not
diskorduser
2021-05-23 07:39:11
Well. jpegxl isn't a image editor!
fab
2021-05-23 07:42:48
--dots=0 --epf=3 -q 77.6213 -faster_decoding=3 --noise=1
2021-05-23 07:44:23
and that was an high quality images
2021-05-23 07:44:36
shot in hdr with 3 flash exposition
2021-05-23 07:44:38
in good light
2021-05-23 07:44:41
very good light
2021-05-23 07:45:22
weights 3,89 mb 16 mpx image
2021-05-23 07:45:39
4:3
2021-05-23 07:45:59
sony wx60
2021-05-23 07:46:07
the camera is from 2013
2021-05-23 07:46:16
so the dynamic range may be poor
diskorduser
2021-05-23 07:46:17
You could also try -q 77.3141592653589793238462643383279 for better results
fab
2021-05-23 07:46:56
stop defending jpeg xl
2021-05-23 07:47:04
and its auto algorithm
2021-05-23 07:47:21
jpeg xl is patented we all know
Pieter
2021-05-23 07:47:50
?
fab
2021-05-23 07:48:35
i want the images i post in instagram to be one quality
diskorduser
 fab i want the images i post in instagram to be one quality
2021-05-23 07:49:03
I can help you with that. Continue in offtopic channel
fab
2021-05-23 07:49:20
i finished
diskorduser
2021-05-23 07:50:13
Instagram always reduces quality. You just have to resize your photos to 1080x1350 and export them to 100 quality jpeg before uploading them
2021-05-23 07:51:13
Also you need to use a slight unsharp mask filter after resizing to get better looking photos on Instagram
fab
2021-05-23 07:51:33
just reshade isn't enough
2021-05-23 07:51:35
?
2021-05-23 07:51:46
or bicubic lanczos
2021-05-23 07:51:58
or paint
diskorduser
2021-05-23 07:52:09
Use robidouxsharp in imagemagick
2021-05-23 07:54:55
Or use automatic algorithm in Adobe Photoshop.
fab
2021-05-23 07:56:31
from which version automatic algorithm is integrated?
diskorduser
2021-05-23 08:02:09
Or Use Adobe lightroom mobile and in export settings turn on output sharpening - screen - amount low or standard.
2021-05-23 08:06:50
You could also find these settings on lightroom cc desktop.
veluca
2021-05-23 08:22:41
sneak preview of how I've been spending my weekend: ``` luca@desktop ~/jxl-rs master $ cargo run /data/jpeg_xl_data/bb_epf0.jxl Compiling jxl v0.1.0 (/home/luca/jxl-rs) Finished dev [unoptimized + debuginfo] target(s) in 0.30s Running `target/debug/jxl /data/jpeg_xl_data/bb_epf0.jxl` Image size: 7216 x 5412 ```
Ringo
2021-05-24 01:12:57
> `cargo`
2021-05-24 01:13:11
nice
Nova Aurora
 veluca sneak preview of how I've been spending my weekend: ``` luca@desktop ~/jxl-rs master $ cargo run /data/jpeg_xl_data/bb_epf0.jxl Compiling jxl v0.1.0 (/home/luca/jxl-rs) Finished dev [unoptimized + debuginfo] target(s) in 0.30s Running `target/debug/jxl /data/jpeg_xl_data/bb_epf0.jxl` Image size: 7216 x 5412 ```
2021-05-24 01:14:45
Is this the rust bindings for libjxl or a new rust encoder <:megapog:816773962884972565>
veluca
2021-05-24 01:15:46
it's a new rust *decoder*... well, for now it only reads image size xD
Nova Aurora
2021-05-24 01:17:27
Not really, they've already spent a lot of time on C, It would probably be easier to write a brand new coder
veluca
2021-05-24 01:46:02
the idea is more to learn rust than to write a production-ready decoder though xD
190n
2021-05-24 07:17:13
talk to mozilla they'll ship it in firefox
raysar
2021-05-24 11:35:40
I use cjxl 30ea86ab The animate encoding is strange in size look at the size @ d 10 and i don't find any encoding option working on canary enven with matches=0 :/ The original png: http://dl.free.fr/meRq2iIJc
2021-05-24 11:37:36
Same size problem @d5
2021-05-24 11:43:45
`Failed to read image .\manga.apng` it's an magick apng from gif
veluca
2021-05-24 11:56:41
try `--patches=0 --dots=0`
2021-05-24 11:57:05
patches and dots are utterly broken in the current publicly available versions
2021-05-24 11:57:32
the encoder will in particular happily encode a number of dots that is quadratic in the # of frames
raysar
 veluca try `--patches=0 --dots=0`
2021-05-24 01:54:43
Great, it works 🙂 I see file size increase when i go up to "-d 4.4" so d 4.4 is is smallest animate jxl that i can make 😄 d 4.5 break file size XD
veluca
2021-05-24 01:56:15
IIRC that's where we enable dots I think
2021-05-24 01:57:08
ah no
2021-05-24 01:57:16
4.5 is where we enable progressive DC
2021-05-24 01:57:28
... try `--progressive_dc=0` and it should work even above 4.5
2021-05-24 01:57:44
(progressive DC is another one of those things we encode a quadratic number of times :P)
raysar
 veluca ... try `--progressive_dc=0` and it should work even above 4.5
2021-05-24 01:57:45
Ok thank you
2021-05-24 01:58:23
dots=1 did not change file size
2021-05-24 02:00:07
I big apng if you want to test big animate jxl :p (180frames) http://dl.free.fr/kyHwaySdG
2021-05-24 02:02:34
It's very slow to have a smooth play on chrome canary, but it works. `cjxl.exe .\got.apng .\got.jxl -d 6 --patches=0 --dots=0 --progressive_dc=0`
veluca
2021-05-24 02:04:06
do you mean that it takes a while before it starts looking smooth?
raysar
 veluca do you mean that it takes a while before it starts looking smooth?
2021-05-24 02:04:16
yes, maybe 15 seconds ^^
veluca
2021-05-24 02:05:14
ouch
raysar
2021-05-24 02:08:32
webp is never fluid on canary 😄
2021-05-24 02:09:13
I need to create good animate file to test smoothness, to 5-10-20-30fps 😄
2021-05-24 02:13:40
webp: http://dl.free.fr/i3shLzxCo
lithium
2021-05-24 03:30:10
Theoretically on jxl d 1.0(q 90), jpeg xl compressed image quality will better than libjpeg q90 444? (like jxl d 1.0 ≒ libjpeg q 91 ~ q94 444) I guess vardct adaptive quantization can more reasonable spend resourse on important area and reduce error, file size also smaller than libjpeg?
_wb_
2021-05-24 03:44:00
Yes, adaptive quantization should help to spend bits where they are needed most
lithium
2021-05-24 03:53:10
So that's why Butteraugli_jxl d 1.0 define on q90? jpeg xl d 1.0|q90 can reach higher libjpeg quality. (like Butteraugli guetzli and pik d 1.0 define on q94~95.)
Maximilian
2021-05-24 03:54:05
I hope this is the right place to ask: Would this format be suitable for storage and delivery of 16bit sint heightmap data?
diskorduser
2021-05-24 03:55:51
16bit - Yes. IDK about sint
lithium
2021-05-24 03:56:40
you mean 16 bit depth?
Maximilian
2021-05-24 03:56:46
basically yes.
2021-05-24 03:57:14
both lossy and lossless.
lithium
2021-05-24 03:57:49
https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_image_codecs
diskorduser
2021-05-24 03:57:52
What's a sint heightmap data?
lithium
2021-05-24 03:58:04
JPEGXL 24-bit (integer) or 32-bit (float), up to 4,100 channels
Maximilian
2021-05-24 03:58:22
signed-integer
2021-05-24 03:58:32
heightmap is basically depth
veluca
2021-05-24 03:58:39
format wise, you can do it
Maximilian
 Maximilian heightmap is basically depth
2021-05-24 03:59:11
probably whatever encoding aspects would apply to both
veluca
2021-05-24 03:59:12
not sure our codebase deals with it without using floats as an input/output format, and perhaps some nontrivial flags
Maximilian
2021-05-24 03:59:57
I would be using it as a library anyway.
_wb_
2021-05-24 04:00:43
Modular happily encodes negative values, current api only has methods to get float or uint values though
2021-05-24 04:01:03
So you'd have to use the float api or else negative values get clamped to 0
2021-05-24 04:02:11
You can of course also do the offset or two's complement thing and encode int16 as uint16
2021-05-24 04:04:35
For lossy: the current VarDCT encoder really wants to know what it is encoding, and it is made for perceptual data, not arbitrary data. So probably not a good idea to use it for lossy heightmaps.
2021-05-24 04:04:59
You can use lossy modular though
Maximilian
2021-05-24 04:06:09
Isn't there support for depth-maps though?
2021-05-24 04:07:50
4.2.8 of 'JPEG XL Use Cases and Requirements'
2021-05-24 04:08:11
or does that not include the actual encoding, just header stuff?
_wb_
2021-05-24 04:08:16
Oh, yes, there's an extrachannel type for it
2021-05-24 04:08:32
But I don't think we defined how to interpret it
veluca
2021-05-24 04:09:09
and the API doesn't quite support it either
_wb_
2021-05-24 04:09:18
You can add a depth channel to an image and it will get modular-encoded
2021-05-24 04:09:40
Does the api only do RGBA atm?
veluca
2021-05-24 04:10:01
atm yes
_wb_
2021-05-24 04:10:33
Shouldn't be too hard to add something to iterate over the non-alpha extrachannels though, just need to think about what the best way is to do that, api wise
veluca
2021-05-24 04:10:59
yup
Maximilian
2021-05-24 04:11:07
is Modular completely lossless?
2021-05-24 04:11:28
oh, there's lossless mode of that too
_wb_
2021-05-24 04:11:29
Could add specific functions for depth, temperature, etc, or a generic one and define an Enum or whatever of the types
2021-05-24 04:11:44
Modular is mostly useful for lossless
Maximilian
2021-05-24 04:12:18
and lossless is completely lossless? On wikipedia it says 'near-lossless'.
veluca
2021-05-24 04:12:36
well, for color channels - for "just data" it probably works well on 😛
_wb_
2021-05-24 04:12:39
It does? That's misleading
veluca
2021-05-24 04:12:44
then wikipedia needs correction
_wb_
2021-05-24 04:12:53
It does mathematically lossless
Maximilian
2021-05-24 04:13:06
yeah, i thought that was wrong.
2021-05-24 04:13:20
`"lossless/near-lossless/responsive mode called Modular"`
_wb_
2021-05-24 04:13:52
Any lossless codec can also be used in a near-lossless or fully lossy way, if you do encoder preprocessing to make the pixels compress better
2021-05-24 04:14:21
And modular has some specific features that make that more effective than in, say, PNG or lossless WebP
Maximilian
2021-05-24 04:14:37
Yea, that was my hope.
Pieter
2021-05-24 04:14:38
Maybe it's less confusing to call it "mode optimized for lossless" and "mode optimized for lossy" ?
_wb_
2021-05-24 04:14:44
(in particular the Squeeze transform and the Delta Palette one)
2021-05-24 04:15:08
Well VarDCT is always lossy
Maximilian
2021-05-24 04:15:19
how's decoding speed compared to png for lossless?
_wb_
2021-05-24 04:15:24
Unless the input is a jpeg, lol
2021-05-24 04:16:43
Decode speed of modular depends a bit on the transforms and predictors you use and mostly on the depth of the MA tree
2021-05-24 04:17:17
You can do PNG-style "basically just gunzip" with it
2021-05-24 04:18:04
But if you want better compression, it will be slower to decode than that, not much can be done about that I think
Maximilian
2021-05-24 04:18:25
yea.
2021-05-24 04:19:02
i suppose the best would be for me to just test each different algorithm.
veluca
2021-05-24 04:19:17
I think on a single thread it can be anywhere between 20x and 2x slower than PNG (at least with the current code)
_wb_
2021-05-24 04:20:14
For 16-bit it should be about the same speed as 8-bit though, unlike png
veluca
2021-05-24 04:20:20
it is theoretically possible to make it about 2-3x faster than it is now, but it's... complicated
Maximilian
2021-05-24 04:21:27
if its compression ratio is much better than png, it's worth it.
lithium
2021-05-24 04:33:34
https://discord.com/channels/794206087879852103/794206170445119489/846415541018820629 Follow this discuss, I understand why my butteraugli distance data can't work on butteraugli_jxl, butteraugli d 1.0 defind on q94~q95, butteraugli_jxl d 1.0 defind on q90, So I think butteraugli_jxl d 1.0 is more like butteraugli(pik, guetzli) d 1.3 ~ 1.45.
2021-05-24 05:07:35
https://discord.com/channels/794206087879852103/794206170445119489/832525604548902932 ```(where we likely calibrated the quality through butteraugli max score -- it is possible that a lower norm is better for this purpose and that a lower norm leads to slightly lower quality values mapping to d1.0)``` About this comment, vardct adaptive quantization use lower p-norm on photographic image is fine, but maybe use lower p-norm on non-photographic image is too risk?
_wb_
2021-05-24 05:19:52
That makes sense
2021-05-24 05:20:30
If you run benchmark_xl you get to see both the maxnorm and pnorm by default
lithium
2021-05-24 05:24:45
I using butteraugli_main and my parallel script
2021-05-24 05:30:11
I think my issue case is edge case, non-photographic image, red and blue color smooth plane have gradient...
Maximilian
 _wb_ Modular happily encodes negative values, current api only has methods to get float or uint values though
2021-05-24 06:16:28
sint will be added to the api in the future, right?
veluca
2021-05-24 06:19:37
at some point yes... for now you can use floats 🙂
Maximilian
2021-05-24 06:21:42
i suppose i could use modular directly
_wb_
2021-05-24 06:32:34
I'm a bit curious: how do you get negative values in a depth channel?
Maximilian
2021-05-24 06:33:03
its a heightmap, not depth
2021-05-24 06:33:08
relative to WGS84
2021-05-24 06:33:20
so below sealevel is negative
_wb_
2021-05-24 06:33:21
So below sealevel or something is negative?
2021-05-24 06:33:24
Ah ok
2021-05-24 06:34:41
So when encoding a map of The Netherlands, it would have quite a lot of negative values
Maximilian
2021-05-24 06:35:24
yeah, probably :p
2021-05-24 06:35:41
but WGS84 doesn't always conform to real sealevel
Pieter
2021-05-24 06:38:11
How is sea level defined?
Maximilian
2021-05-24 06:40:07
It's based on earth's gravitational field
Pieter
2021-05-24 06:40:40
Right, that's well-defined of course.
Maximilian
2021-05-24 06:40:46
this is getting offtopic though.
GilDev
2021-05-25 03:37:00
Hi, I’m helping Graphic Converter’s developer to test the JPEG XL implementation which is quite glitchy right now. I can’t find the djxl option to get a more verbose output with more decoding details, could you please tell me what it is? Looked on the `-h` page but didn’t find it, although I’m pretty sure I used it in the past
veluca
2021-05-25 03:38:47
I guess `-v` exists but I don't know if it does anything useful...
GilDev
 veluca I guess `-v` exists but I don't know if it does anything useful...
2021-05-25 03:42:15
Get an unknown argument error
veluca
2021-05-25 03:42:44
then it doesn't do anything useful xD
GilDev
2021-05-25 03:43:48
And to give some info, I open a JPG or PNG file with Graphic Converter, I save it to JXL through the software using 90 % quality, both with or without metadatas and container format, it saves the JXL file that is 4 times as big as the original, and this one opens back in Graphic Converter but gives this when trying to decode with djxl: ``` djxl 2.jxl 2.png Read 830262 compressed bytes [v0.3.7 | SIMD supported: AVX2,SSE4] WARNING: failed to pin thread 1. WARNING: failed to pin thread 0. WARNING: failed to pin thread 2. WARNING: failed to pin thread 3. Failed to decompress to pixels. ``` So nothing much
zebefree
2021-05-25 03:46:16
Try jxlinfo
GilDev
2021-05-25 03:52:36
I haven’t compiled JPEG XL so don’t have jxlinfo, it failed at the time when I tried, I’m using the Homebrew release
veluca
2021-05-25 03:53:46
can you dump the first few bytes here? `hexdump -C file | head -n 5` or so
GilDev
 veluca can you dump the first few bytes here? `hexdump -C file | head -n 5` or so
2021-05-25 04:14:58
The 1.jxl is with metadata and JXL container enabled (export settings from the software) and 2.jxl is without ``` $ hexdump -C 1.jxl | head -n 5 00000000 00 00 00 0c 4a 58 4c 20 0d 0a 87 0a 00 00 00 14 |....JXL ........| 00000010 66 74 79 70 6a 78 6c 20 00 00 00 00 6a 78 6c 20 |ftypjxl ....jxl | 00000020 00 00 00 00 6a 78 6c 63 ff 0a 3a 1f 04 3b 01 00 |....jxlc..:..;..| 00000030 48 80 28 00 a1 cd ee 1f 00 dd 10 24 41 12 24 d1 |H.(........$A.$.| 00000040 99 04 31 fc d0 21 94 64 d8 22 d6 d2 dd 4b c5 0f |..1..!.d."...K..| $ hexdump -C 2.jxl | head -n 5 00000000 ff 0a 3a 1f 04 3b 01 00 48 80 28 00 a1 cd ee 1f |..:..;..H.(.....| 00000010 00 dd 10 24 41 12 24 d1 99 04 31 fc d0 21 94 64 |...$A.$...1..!.d| 00000020 d8 22 d6 d2 dd 4b c5 0f 59 96 a6 0c 00 71 fb 81 |."...K..Y....q..| 00000030 bf 62 32 00 2d 48 f5 49 01 a3 41 58 71 4e 81 bd |.b2.-H.I..AXqN..| 00000040 95 2b 55 0f 00 40 34 14 2a a3 8c 73 56 4e b7 5e |.+U..@4.*..sVN.^| ```
veluca
2021-05-25 04:16:54
that doesn't seem obviously wrong, at least...
2021-05-25 04:17:19
one thing you can do, if you can recompile JXL, is compile in `opt` instead of `release`, it will tell you where it fails
GilDev
2021-05-25 04:22:41
I can’t right now but will eventually try. I guess the official developers will also test it further in the near future
veluca
2021-05-25 04:30:16
if you figure out it's a libjxl problem, file an issue: https://github.com/libjxl/libjxl/issues
GilDev
 veluca if you figure out it's a libjxl problem, file an issue: https://github.com/libjxl/libjxl/issues
2021-05-25 04:30:42
Sure thing!
Scope
2021-05-25 05:20:04
<https://github.com/libjxl/libjxl/commit/bdde644b94c125a15e532b2572b96306371a7d4e> After this global commit will it be possible to make individual commits?
veluca
2021-05-25 05:23:27
yeah
2021-05-25 05:23:35
that's what we'll do 🙂
2021-05-25 05:23:41
that one is *the last* global commit
Eugene Vert
2021-05-25 05:23:52
libjxl/doc/guidelines.md still states the Apache 2 license
veluca
2021-05-25 05:25:04
ah, we had to have missed something
KAGAMI
2021-05-25 05:26:11
Has there been active work for Content-Encoding: jxl ? https://github.com/w3ctag/design-reviews/issues/541 Is brunsli still a thing?
_wb_
2021-05-25 05:28:44
jxl can be a brunsli, not sure if it's useful to have content-encoding jxl in browsers that just support jxl directly though
veluca
2021-05-25 05:35:21
yeah, I was thinking of writing a plugin for nginx that would basically do the equivalent thing but send an `image/jxl` without `Content-Encoding`
2021-05-25 05:35:30
should be faster from an user experience point of view
zebefree
2021-05-25 05:39:11
The advantage of the Content-Encoding is that users can still save the image and get a regular JPEG like they expect.
_wb_
2021-05-25 05:41:26
Yes. I suppose that could theoretically also be done, or done as an option, when a `jbrd` jxl is shown as just an image.
veluca
2021-05-25 05:41:28
yeah but that might also be implemented on the browser side, without any need for standardizing it
Scope
2021-05-25 06:23:02
Also, it might be better to make a github bot
veluca
2021-05-25 06:24:29
github bot? for what?
Scope
2021-05-25 06:26:02
Instead of <#805062027433345044>
veluca
2021-05-25 06:28:24
ahhhh
2021-05-25 06:28:26
right
2021-05-25 06:28:32
although it should be mirrored, so...
Scope
2021-05-25 06:41:38
<https://github.com/libjxl/libjxl/commit/cb3f1bda7fee11328b7ddd0bd560db4b2e0f3c2c> Ah, that's another branch, that's why the bot didn't work
veluca
2021-05-25 06:43:12
yeah, it's just a few cherry picks
_wb_
2021-05-25 06:47:19
The branch for chrome needs to be cherry picked fixes only, to avoid introducing new bugs?
veluca
2021-05-25 06:48:27
yup
_wb_
2021-05-25 06:50:16
So 0.4.0 will be what ships in Chrome 93, and current main will become 0.5.0?
veluca
2021-05-25 07:08:50
something like that, yes
Scientia
2021-05-25 09:33:35
Will jxl be enabled by default or just a flag?
veluca
 _wb_ So 0.4.0 will be what ships in Chrome 93, and current main will become 0.5.0?
2021-05-25 09:37:29
actually that's 92 not 93
Scientia Will jxl be enabled by default or just a flag?
2021-05-25 09:37:38
in 93 hopefully by default... we'll see
Scientia
2021-05-25 09:41:46
In 92 it will be a flag?
veluca
2021-05-25 09:42:36
yeah for sure
Deleted User
2021-05-25 09:48:47
What's the consideration behind flag or no flag?
2021-05-25 09:49:03
Won't 92 be feature-complete?
improver
2021-05-25 09:50:17
testing of stuff. also progressive loading i think
Deleted User
2021-05-25 09:52:51
Well, but it's not that people instantly use JXL and even if they do, they probably wouldn't miss progressive loading too much.
improver
2021-05-25 09:53:35
naive
veluca
2021-05-25 09:54:27
(a) progressive (b) good RAM usage (c) security etc (d) politics 😛 (enough support from decision makers)
_wb_
2021-05-25 09:54:53
Adding support for a new codec is basically a nearly irreversible decision. I think it's very reasonable to put it behind a flag for one version cycle.
2021-05-25 09:55:35
Plus being sure there are no bugs etc.
veluca (a) progressive (b) good RAM usage (c) security etc (d) politics 😛 (enough support from decision makers)
2021-05-25 09:56:21
And these things too.
Deleted User
 _wb_ Plus being sure there are no bugs etc.
2021-05-25 09:56:37
Well, but those can emerge after every commit. ^^
improver
2021-05-25 10:00:11
> Adding support for a new codec is basically a nearly irreversible decision is it really, though?
2021-05-25 10:01:34
I'd imagine quite a bit of stuff what adopts AVIF would use <picture> and accept hints
2021-05-25 10:01:48
and not browser version tests
_wb_
2021-05-25 10:16:18
Yes, Accept headers can change
2021-05-25 10:17:16
But JPEG XR is the only example I can come up with of a browser dropping support for an image codec
veluca
2021-05-25 10:20:06
and even then IIRC it was because they dropped the *browser* xD
zebefree
2021-05-25 10:20:24
Browsers supported TIFF a long time ago
2021-05-25 10:21:37
Also XBM was supported and dropped
_wb_
2021-05-26 05:03:17
Ok but those are uncompressed. I cannot imagine that was used very often even when it worked.
2021-05-26 05:04:00
I can see BMP getting dropped too
Jim
2021-05-26 11:01:28
I doubt BMP will get dropped. I see some libraries using it, especially with canvas, to pass lossless image data without the overhead of re-compressing it.
Scope
2021-05-26 11:06:14
BMP was partly used for favicon.ico, before switching to PNG
_wb_
2021-05-26 11:06:27
that's ICO, not quite the same as BMP
fab
2021-05-26 12:01:26
is way to download build or dll
2021-05-26 12:01:30
compiled by others
2021-05-26 12:01:46
or jpeg xl still isn't meant to be integrated by converters
2021-05-26 12:04:46
i want to file an issue about the quality not uniform
2021-05-26 12:05:19
but first i need to try if that is resolved
2021-05-26 12:05:45
or if there are not significant regressiosn
2021-05-26 12:06:36
those people are running a version higher than me
2021-05-26 12:06:54
so maybe they don't have same issue
2021-05-26 12:07:29
and they get higher perceived quality on s 9 q 66 in comparison to s 9 q 65 or the old settings i used
Petr
2021-05-26 12:07:44
IIRC XnView has a DLL for jxl (if this is what you're asking for).
fab
2021-05-26 12:07:59
when scope will make next build
2021-05-26 12:08:08
without mingw
2021-05-26 12:08:17
is that difficult to make a non mingw build?
2021-05-26 12:08:34
has any sense for a dev to make a non mingw build?
2021-05-26 12:08:53
at least i need to understand the basics
2021-05-26 12:10:44
github this has totally changed
_wb_
2021-05-26 12:30:18
maybe we can get some autobuilding stuff now we're in GitHub, so we can have releases with binaries
fab
2021-05-26 12:38:09
how to add images
2021-05-26 12:38:10
on github
2021-05-26 12:38:17
do i need to use slowpics
2021-05-26 12:38:25
or mega
2021-05-26 12:38:32
better mega
Petr
 _wb_ maybe we can get some autobuilding stuff now we're in GitHub, so we can have releases with binaries
2021-05-26 12:50:10
Ideally with version etc. in metadata of the binaries. And including the GIMP plugin. 😇 👍
fab
2021-05-26 12:51:12
i opened a issue
2021-05-26 12:51:23
maybe it will be closed or deleted
2021-05-26 12:51:33
but i did so more people see
2021-05-26 12:51:43
not sure if is a great comparison
2021-05-26 12:51:56
but there is blurring and loss of precision
2021-05-26 12:52:02
at medium bitrates
2021-05-26 12:52:24
like it skips some qualities
2021-05-26 12:52:38
it is right?
2021-05-26 12:54:52
facebook is a copyrighted name i should not write it
_wb_
2021-05-26 12:55:46
I don't know if subtle encoder behavior when using weird non-default options and weird atypical images is that relevant
fab
2021-05-26 12:55:54
i tried also normal settings such as s 9 q 65
2021-05-26 12:56:04
it looks blurrier
2021-05-26 12:56:50
so there aren't issues
2021-05-26 12:57:05
is the encoder that is smart that skips some qualities
2021-05-26 12:57:12
is it a feature?
2021-05-26 12:57:23
to waste less bits?
2021-05-26 12:57:32
gaborish does this
2021-05-26 12:59:11
yes but i had to crank up the bitrate too much to get better quality
2021-05-26 12:59:17
is something that can happen
2021-05-26 12:59:23
or the encoder needs to improve
2021-05-26 12:59:38
its precision
2021-05-26 01:00:00
from 70 kb the image become 100 kb
2021-05-26 01:00:08
not too much
2021-05-26 01:00:19
but the number q is increased +15
2021-05-26 01:00:46
do not know because i do not develop the encoder
2021-05-26 01:04:31
like wp2 is simpler to operate with because default settings give appropriate amount of blurring. JPEG XL is strange to me.
2021-05-26 01:05:18
2021-05-26 01:05:23
it added the link good
2021-05-26 01:06:10
obviously that for jon jpeg xl is simpler because he understands the qualities
2021-05-26 01:06:44
he knows how to get a not too strong blurring
2021-05-26 01:06:55
and so
2021-05-26 01:08:27
maybe it needs floating partitioning to improve
2021-05-26 01:37:56
the build ewout published is highly experimental don't use it
2021-05-26 01:38:11
it looks too blurred
2021-05-26 01:38:21
even at
2021-05-26 01:38:35
for %i in (C:\Users\User\Documents\ss\*.png) do cjxl -d 2.71816 -s 9 --gaborish=1 --epf=0 %i %i.jxl
2021-05-26 01:39:21
don't waste time with appveyor
2021-05-26 01:41:30
they probably want to look fine at higher bitrates like
2021-05-26 01:41:40
for %i in (C:\Users\User\Documents\ss\*.png) do cjxl -q 82.972 -s 9 --gaborish=0 --epf=2 %i %i.jxl
2021-05-26 01:42:10
but i don't advice to encode anything with it
2021-05-26 01:49:20
To me the encoder is good enough
2021-05-26 01:49:41
But I dont know if use d2 or d3
2021-05-26 01:58:34
-q 88.2818 -s 9 --use_new_heuristics
2021-05-26 01:58:44
i want to see how ram will use
2021-05-26 02:01:04
i think less because is one core
2021-05-26 02:03:35
for %i in (C:\Users\User\Documents\ss\*.png) do cjxl -q 85.73 --faster_decoding=6 -s 7 %i %i.jxl
2021-05-26 02:03:42
the image now looks great
2021-05-26 02:04:13
https://ci.appveyor.com/project/EwoutH/libjxl/builds/39328673/job/0perh7t4aiii724h/artifacts
_wb_
2021-05-26 02:04:16
maybe move to <#840831132009365514>
veluca
 veluca sneak preview of how I've been spending my weekend: ``` luca@desktop ~/jxl-rs master $ cargo run /data/jpeg_xl_data/bb_epf0.jxl Compiling jxl v0.1.0 (/home/luca/jxl-rs) Finished dev [unoptimized + debuginfo] target(s) in 0.30s Running `target/debug/jxl /data/jpeg_xl_data/bb_epf0.jxl` Image size: 7216 x 5412 ```
2021-05-26 06:59:58
aaaannd code is live - don't expect too much though! https://github.com/libjxl/jxl-rs
2021-05-26 07:00:22
(especially from my rusty rust skills...)
_wb_
2021-05-26 07:08:44
Maybe djxl-rs would be a better name, or do you think an encoder could also be in scope?
veluca
2021-05-26 07:09:05
perhaps, perhaps
_wb_
2021-05-26 07:09:15
Ok leave it 😁
veluca
2021-05-26 07:09:35
likely depends on how I feel when I wake up every weekend 😛
_wb_
2021-05-26 07:10:04
`jxl-weekend`
2021-05-26 07:12:04
Might be worthwhile to get someone unfamiliar with the codec to also work on this, based just on the spec, not the libjxl code
fab
2021-05-26 07:52:07
https://github.com/GoogleChromeLabs/squoosh/pull/1030
Jim
2021-05-26 08:21:34
`weekend-at-jxls`
il1kesonic
2021-05-26 11:57:52
hello guys i just downloaded discord so many subscribers of mine kept recommending it to me! So i decided to just join random servers. Anyways, how are you all?
BlueSwordM
 hello guys i just downloaded discord so many subscribers of mine kept recommending it to me! So i decided to just join random servers. Anyways, how are you all?
2021-05-27 12:02:41
Hello. We are here in this Discord server to discuss about JPEG-XL and lots of things related to math, technology and general science.
2021-05-27 12:02:44
We also like cats.
2021-05-27 12:02:48
I'm doing fine on my part.
2021-05-27 12:02:51
How about you?
190n
2021-05-27 12:04:15
this is not a new user to the server btw
il1kesonic
2021-05-27 12:04:51
I'm fine ❤️ and how are you <@!164917458182864897> ?
190n
2021-05-27 12:05:28
doing pretty well just got out of class
GilDev
 zebefree Try jxlinfo
2021-05-27 12:19:32
<@!179701849576833024> Got jxlinfo from the developer, here’s what I get
veluca
2021-05-27 12:21:11
well, that seems reasonable...
Deleted User
 _wb_ Guess the same thing could be done as what imagemagick does in jpeg: just attach some metadata blob with the encode settings.
2021-05-27 05:55:21
`opusenc` from Opus Codec embeds both encoder info and encoding settings in Vorbis tags, like this: ```ENCODER=opusenc from opus-tools 0.2-3-gf5f571b ENCODER_OPTIONS=--bitrate 64```
_wb_ Nope
2021-05-27 05:57:43
So truncated JXL will behave like APNG (showing just the first few frames at full quality)?
_wb_
2021-05-27 05:59:45
Yes
diskorduser
 hello guys i just downloaded discord so many subscribers of mine kept recommending it to me! So i decided to just join random servers. Anyways, how are you all?
2021-05-27 06:01:20
You have a 788 day old account, but you just download discord now? Suspicious.
improver
2021-05-27 06:01:55
tbh i love sophia's shitposting it's so quality
fab
2021-05-27 06:15:55
why we don't have new jpeg xl builds?
2021-05-27 06:16:03
other than the squoosh one
Jim
 fab why we don't have new jpeg xl builds?
2021-05-27 06:20:13
I believe they are focusing on getting integration into the browsers right now. Patience, a new build will arrive soon enough. As far as Squoosh, I believe they sometimes set their builds to use newer builds than the latest stable so they can test and add new features in or fix certain bugs.
fab
2021-05-27 06:20:40
now jpeg xl works at different qualities
2021-05-27 06:21:01
still medium hasn't the best accuracy
diskorduser
2021-05-27 06:21:11
Compile git builds then.
Jim
2021-05-27 06:21:56
<:This:805404376658739230> Always an option to just use the newest code
fab
2021-05-27 06:21:58
medium to me is q 65.1, q 82
2021-05-27 06:22:27
not bpp
2021-05-27 06:23:23
like i filed an issue with a low quality image and almost high quality one
2021-05-27 06:23:25
for %i in (C:\Users\User\Documents\bn2*.jpg) do cjxl -j -s 6 -q 63.52 --epf=2 -p --gaborish=1 --patches=0 --dots=1 --use_new_heuristics %i %i.jxl for %i in (C:\Users\User\Documents\dos2*.png) do cjxl -q 82.33 -s 8 --epf=2 --gaborish=1 %i %i.jxl
2021-05-27 06:23:31
12052021 build
2021-05-27 06:24:04
and first thing i notice is that even using q 65.1 or q 75
2021-05-27 06:24:13
it looks ok
2021-05-27 06:24:26
with the new ones
2021-05-27 06:24:34
but using same build as
2021-05-27 06:24:41
12052021
2021-05-27 06:24:48
it looks blurred
2021-05-27 06:24:51
....
2021-05-27 06:24:55
I always use speed 9
2021-05-27 06:25:16
so the precision could be improved
2021-05-27 06:25:51
i think there isn't aim for max precision or accuracy, they want only to improve encoder at the moment
2021-05-27 06:26:07
to have more users
diskorduser
2021-05-27 06:26:52
I remember jxl developers said not to use experimental and non standard flags to test images. Still you do it and continue ~~ranting~~
fab
2021-05-27 06:26:53
like they want users to get less generation loss
2021-05-27 06:27:51
jpg as jaffathecake said
2021-05-27 06:27:56
its a format for the web
2021-05-27 06:28:05
meant for different scope case
2021-05-27 06:29:13
anyway they will close the issue in a time
2021-05-27 06:35:54
jpeg xl they use terms especiall jon as better in medium quality in subjective tests or in psnr, automatic encoding quantization
2021-05-27 06:36:12
something like that
Jim I believe they are focusing on getting integration into the browsers right now. Patience, a new build will arrive soon enough. As far as Squoosh, I believe they sometimes set their builds to use newer builds than the latest stable so they can test and add new features in or fix certain bugs.
2021-05-27 06:36:46
this right answer
Deleted User
 improver tbh i love sophia's shitposting it's so quality
2021-05-27 10:13:34
Nothing beats Fabian.
improver
2021-05-27 10:14:56
fabian is quantity sophia is quality
Petr
2021-05-28 05:42:16
Hmm, this is interesting: https://commons.wikimedia.org/wiki/File:JPEG_XL_logo.svg
2021-05-28 05:42:53
Although I like to see the logo on Wikimedia Commons, I'm afraid it's a copyright violation…
2021-05-28 05:46:50
Yeah, but see this: https://jpeg.org/contact.html → Branding → license_agreement.pdf
_wb_
2021-05-28 05:52:44
I can ask, not sure if they're going to want to do that
190n
2021-05-28 05:53:12
can't tell what font that is but it may not be free
Pieter
2021-05-28 05:54:12
well a codec as a process isn't copyrightable, but various things around it certainly are (the specification, reference code, ...)
2021-05-28 05:54:48
and even if licensed liberally, it's still subject to copyright