JPEG XL

usually 0,6 0,3 mpx/s for encoding at s9 with normal heuristic

does C 5 is valid input

so is different shades of RCT

or same settings

so the value doesn't change changing the -C

<@!179701849576833024>

Probably because lossy modular doesn't actually do RCTs

I don't remember if it does

But I wouldn't be surprised if it didn't

It uses XYB so RCTs are not useful

Only when doing lossy in forced RGB will it use YCoCg, iirc

How is the QUALITY: based on butteraugli metric. Good at -d 1, use -d 2 for web distribution. d 1 is similar or the same as q 90 Vardct.

this is not official from the manpages

this is written by me

but probably i will unify this

when there is a new encoder

q90 = d1

so this is fixed

great

previously in guetzli we had d1.0 = quality 94 or so --- if today quality 90, we may have slipped a bit in quality

what constitutes great quality also relates to the size of the pixels and it is possible that pixels are getting smaller 😛

also can be that our mapping between quality values and butteraugli scores is less methodical or uses a different method in JPEG XL than it was in guetzli (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)

my viewpoint on quality is that people should use the -d way of defining quality, i.e., define it through the butteraugli rather than the traditional way

-d relates to butteraugli's understanding of human vision observing compression artefacts where as -q relates to old heuristics done in an early JPEG1 implementation

...

I'm meeting with Chrome's Blink API owners next week

I need to bring them data about: 1) content providers showing interest, 2) other browsers showing interest, and 3) other considerations about the unique value that JPEG XL is bringing

if anyone here has a specific on-going effort that could help with one of these three things, I'd like to learn about it so that I could bring it up in the meeting

this would simplify/speed up turning JPEG XL on by default in Chrome

https://discord.com/channels/794206087879852103/794206087879852106/832388137224634409 <@!801963509898149908>

Not to mention that libjpeg -quality and Photoshop 'quality' are very different (and ImageMagick and mozjpeg are somewhat different from default libjpeg too)

is it true that jxl is opened with libjxl

so even imagemagick

or qtjpegdll

or kdedll

they use libjxl

Yes

or they have different code

so you need libjxl installed

They can also link statically

I like this post -- it is written from a very practical viewpoint

thanks

i wrote newerimage instead on newer image

but those don't show in SEO

at all

but honestly i don't care i wrote for me

i edited the section of software in spanish

squoosh line is too long

maybe i need to edit

i don't know i can't format text

neither i can edit web pages

in italian they removed the software section due to a possible spam

Strange. At least something should be in that section.

By the way: there's a tiny problem with that section, but in English version. https://en.wikipedia.org/w/index.php?title=JPEG_XL&diff=next&oldid=1017219501

Someone removed my edit, but I think it should be there due to https://en.wikipedia.org/wiki/MOS:DATED...

right it was useless

what the person did is right

anyway to disable most thing in jpeg xl do

-s 6 -faster decoding=5 --epf=0 noise=o dots=o gaborish=0 --intensity_target=200 -q 78.5

for %i in (C:\Users\User\Documents\dd\*.png) do cjxl4 "%i" "%i.jxl" -s 6 --faster_decoding=5 --epf=0 --noise=0 --dots=0 --gaborish=0 --intensity_target=200 -q 78.5 --num_threads=2

maybe i like more the jpeg look it gives this setting

it's the smaller file

the bigger file is

for %i in (C:\Users\User\Documents\dd2\*.png) do cjxl4 "%i" "%i.jxl" -s 6 -d 2.035 --num_threads=2

Where potato user can take windows binaries for encode png's to jxl format? Mm?

<#822120855449894942>

can modular support intensity target?

It won't make any difference for compression, but it should make a difference for how it is signalled/displayed on hdr screens

yes but to me makes a difference

for %i in (C:\Users\User\Documents\jxl*.png) do cjxl4 "%i" "%i.jxl" -q 86.5 -s 6 -g 3 --intensity_target=1024 -P 6 -m --num_threads=2

makes better lossy screenshots

-s 4 -g 3 -intensity=180 -P 6 -C 3 -I 0.779 -m -q 93

maybe it can achieve an avif effect

but better avoid an avif effect and use like image editor default

but if the encoder crashes with multiplier of 0 how we can know if those settings are good

Not sure why it crashes

and much brighter, too

i don't know i don't have an android hdr phone

i have a phone from 2013

Hello, is there in jxl metadata all encode param? like video file with the full encoder option? xnviewmp see noting.

I don't think cjxl store encode parameters

Only what is needed to decode it

Nothing stops you though from adding a metadata box with the encode params you used

So imageviewer can't say me easyly if the picture is progressive,lossless jpeg,modular, original bit depth etc?

but it can ask to the decoder par of this information?

i think all of those except original bit depth should be ascertainable from the image without any metadata

What jxl_info can tell you are things that can be found out by parsing the codestream header

jpeg xl can look good even at q 58.91 -s 6

but i hope they do not make a neutral quality

-q 66.7 -s 8 to me is great quality

file: https://discord.com/channels/794206087879852103/806898911091753051/833006333192044544

for %i in (C:\Users\User\Documents\F*.jpg) do cjxl "%i" "%i.jxl" -j -P 5 --palette=0 -I 5 -s 3 -m --mquality=75 --num_threads=2

when i used simpler settings

use -m -q 75.58 -P 9 -s 9 on this image you have with 0.3.4

this a more recent one i used

<@416586441058025472> We don't understand what you say in this chan. Make good sentences with deepl.com if you need to translate. Are you testing random settings? That's very strange :D

I have no idea what <@!416586441058025472> is trying to say most of the time either here.

how to denoise image jxl. make look bad https://discord.com/channels/794206087879852103/794206170445119489/832329750998679552

You want to remove the noise in a jxl image? At encode time, or after? What are you trying to make look bad? Which image?

they were 7 test images

Most of all, what does this have to with JPEG-XL?

nothing they are only notes

I have no clue what you're trying to say.

the url is called how-is-the-codec-jxl/

sorry for being confusing but maybe i need better web skills

What are you trying to do?

see the various modular settings

I'm very sorry, but I think I'm missing the big picture. You post a bunch of commands, and then say things about denoising. I don't know how they're related, what you're trying to achieve, or what you hope to accomplish by mentioning it here.

it's a denoising look not true denoising it's bad

I don't know what you're trying to make me look at.

nothing random command like i did q 75 and -d 2.19 and imageglass jxl

What is your question?

i'm deleting some other messages, there is some spam up

like what you're talking talked (now i deleted) about what i deleted on my site that was confusing.

not related with jpeg xl sorry if it confused you

Ok, this is about your website?

yes confusing posts i made yesterday morning

somehow i put in the <#794206170445119489>

Honestly I'd just use `-s 9 -d x.xx` (where x.xx is either 0.00 or a nonzero number that is needed for a lossy image)

Or just default speed -d x.x

Does speed 9 really have that much of a penalty?

I personally can wait a little extra to encode as long as decode is pretty similar

Modular s9 is better, standard vardct s7 is more safe and tested then s9

Visually -s7 and -s9 in lossy dct have the same look. -s9 is very usefull for lossless.

size wise are s7 and s9 the same in dct?

or is s9 smaller?

S9 is particularly useful for photographic images.

The psycho-visual boost you get is quite nice with S9, and it is not easily noticed at 1st glance.

what about

--faster_decoding=2 --gaborish=1 --epf=2 --noise=1 -s 7 -q 89.26

we will see when new version will come out

it improve dssim dssim at s 9 q 99.2 with 50° commit is near perfect

I thought so, but on my comparison, it's really imperceptible even at 400% zoom, i'm working to create a custom webpage with different encoder params on different image type. Dev seem to say the same thing.

As it often goes, for lossy, slower speed setting is mostly guaranteed to be slower 😅

What you need is something with lots of random detail and lots of color and low-mid bpp.

That's where you'll see the biggest differences.

ok 🙂

i'm testing jxlinfo on different jxl. There is no line to say if it's a dct or modular file? I expect to have: dct, jpeg-lossless, modular, (maybe possible to detect: modular-lossy, and dct-lossless.) <:BlobYay:806132268186861619>

It seems he doesn't know either. 😜

Does chroma from luma prediction work in Modular? If yes, then in lossless, lossy or both?

Chroma from luma with signaled weights per 64x64 pixels is a VarDCT thing (the weights are multipliers for the Y DCT coeffs, which after multiplication get subtracted from/added to X and B DCT coeffs)

There is also the generic notion of channel decorrelation by means of color transforms, and for that there are RCTs (reversible color transforms) in Modular mode. An RCT can be applied image-wide but also per group, so you could see it as a form of low-res simple chroma from luma with signalled transform per 256x255 pixels (or 128x128 with -g 0)

So '-d' only works for VarDCT, for Modular should use '-q' or '-Q', right?

~~-d for modular, -Q for VarDCT, -q will map to either~~

When I try, -m ignores the -d value and works lossless.

oh, lossy modular maybe is different

wait, no, brainfart

obviously values other than 0 for distance are lossy

Yeah, looks like you're right.

Is this a bug or it should be that way?

It's intended, see this discussion. I was just confused, apologies. https://discord.com/channels/794206087879852103/803645746661425173/831228523871993875

Oh, ok, thanks 😄

I'm mainly interested in lossless and just use -d 0 all the time.

ok i updated the settings and deleted messages here

the benchmarks i did

also i wrote the bugs and the commands that crashes here

in BUGS section

Why don't you file bugs on gitlab issues?

because they aren't actual bugs but resolution that didn't work

with some specific command not supported by the encoder

or supported but not by the current

and also they were deleted

from <#803645746661425173> to avoid spam

I want to confirm something. When I transcode a JPG to JXL via `cjxl`: 1. The resulting .jxl file contains the DCT data of the original JPG file, but in a more efficient format. (a.k.a. filesize savings) 2. When I decode using `djxl` to a .jpg file, it should be exactly the same image as the original JPG. 3. When I decode using `djxl` to pixels (such as to .png), the resulting file is not the original JPG file, but rather, a JPG with **improved quality** i.e. a different image altogether. I'm putting special emphasis on the 3rd point, because I only remember that information being mentioned in passing in an article somewhere. I may have forgotten where :> Either way, I'm asking this because I got really confused as to why ImageMagick was saying that my losslessly transcoded JPG files were different from the original JPG file. I tried decoding with djxl to a .png file, and ImageMagick said the images were different. But then, when I tried decoding to a .jpg file, the images were now exactly the same. It took me a few minutes to recall that JPEG XL can "improve" the quality of transcoded JPGs.

If this is true, should we be saying that somewhere in the output of `djxl`? Because I assume that most people, when they hear that their JPG is being losslessly transcoded into a JXL file, they think that when they decode it back, the image will be exactly the same, no matter if it was decoded back into a JPG or PNG. At least, I expected that. As in, should we note that the decoded image when ***not*** reconstructing a `.jpg` file will be different than the original JPG file? And how exactly do we handle cases such as the image comparisons I mentioned above? When I compare a JPG file to a JXL file that's a transcoded JPG file, I expect the output to be the same, but they aren't.

I apologize if I couldn't explain my situation properly or briefly enough.

*Or we can maybe place that in the README somewhere? I don't really know. Sorry for sending so many messages. I tend to have a problem with saying too much.

The main thing to note is that the old JPEG format is somewhat underspecified, in the sense that there is some degree of freedom in how you decode it.

Two different jpeg decoders can produce different pixel values for the same input jpeg and still both be conforming decoders.

Probably the jxl decode pipeline is a bit more precise and smarter about dequantization than most jpeg decode pipelines.

Note that (vardct) jxl will also be somewhat underspecified (not as much as JPEG, but still a bit), and there will be slight pixel value differences e.g. between optimized and unoptimized decode paths, between ARM and x86, and even between different C compilers.

Does it mean I get different colors on phone and laptop on vardct jxls? 🤔

depends on what you call “different colors” but it should not happen to a notable extent

the colors are still defined in absolute terms

now, how different systems manage to display absolute colors the way they should be is a different matter but it’s outside of jxl’s control and not specific to it

no format is exempt from the latter problem

Thanks for clearing that up. On another note, though, this variability in decoding is really only okay because VarDCT is used for lossy, right? Ideally, I think, the same input should be standardized to have the same output, but for lossy I guess the tradeoff is fine?

Modular does everything in integer arithmetic and its decoded output is defined exactly (also in lossy modular)

Well except if you use XYB, then there might still be some rounding differences

VarDCT does the DCT and other things that are best implemented using floating or fixed point arithmetic, which leads to different rounding errors depending on how exactly you implement it (making trade-offs between precision and decode speed)

When you decode a losslessly-recompressed-jpeg-to-jxl to pixels you get an image whose pixels are identical to those of the jpeg you'd get when decoding to jpeg; no quality difference. It may be even lower quality if you decode to pixels to jpeg, because there is another lossy compression step.

Yes but there are different jpeg decoders and they don't all do exactly the same thing

Sure, I just wanted to comment on <@!557099078337560596> thinking that decoding to pixels would give you better quality. At best, it's the same quality.

It could be slightly better than what you get with default libjpeg-turbo though

How so? Decoding to pixels and reconverting to jpeg can only add additional noise. It can't add data that isn't there.

I think we do the dequant in a better way, and the DCT and color transforms more precisely

I mean comparing the result of `djxl recompressed-jpeg.jxl out1.png` with the result of `djxl recompressed-jpeg.jxl tmp.jpg; djpeg tmp.jpg > out2.ppm`

yes

there is signal and noise in the original jpeg

Of course then doing another lossy jpeg encode can only add loss, and probably will

that same signal and noise is in the recompressed one

decoding to jpeg will also have that exact same signal and noise

decoding to png can at best have the same (but due to quantization differences in the dct->png conversion have additional noise? unsure about this) - reconverting to jpeg can only add noise

Correct, best to always avoid recompression

Generation loss can be quite heavy if the quant tables of first and second jpeg don't match

https://cloudinary.com/blog/why_jpeg_is_like_a_photocopier

Does mozjpeg do any chroma subsampling?

<@!826537092669767691> how hard would be writing a program that guesses the original JPEG quantisation tables?

what do you mean original? getting qtable from pixels?

Let's say you've got a decoded PNG/PPM file and the only thing you know about it is that it was compressed once with JPEG. We have to guess the quantisation tables having only pixel values that resulted from it.

it's possible-ish

apply float DCT to the image

and then make a histogram for each coefficient, across the whole image

the histogram won't be very clear, because YUV/RGB and clipping makes a mess

but you should see higher peaks in the histogram that are close to the original quantized values

Would the list of most popular quantisation tables (this one was taken from Squoosh) make the task easier?

Yes, I made something like that for Cloudinary, it kind of works but it's not perfect. Good enough to see if it was a jpeg before or not, and to guess if it was a high quality one or a low quality one, but not good enough to get precise quant tables. Haven't really tried hard yet though, can probably do more if you first estimate chroma subsampling.

I think so. Once you get the histogram, you can brute force through all quant tables at all qualities, and see which fits the histogram best.

this could crash

-s 4 -g 3 -intensity=180 -P 6 -C 2 -I 0.779 -m -q 93

is too complicated

also is not called intensity

interesting article

Hi everyone, is someone here monitoring the libVips JPEG XL integration effort?

i guess? stuff was written about it in <#804324493420920833> a bit

I'm just asking if I should file issues over at GitLab if I find problems that are (almost) certainly coming from libjxl or if this would be confusing since some team member is already watching...

filling issues on gitlab would probably be better, since it's easier to track them there

sometimes stuff gets told in chat and forgotten...

Ok, thanks

i mean for usage questions chat is probably preferred because of possibly lower latency, but once it's clear that there's an issue in the library, gitlab issue should be opened for that

but that's just my opinion, i'm not core dev

Ok, I'll try here first:

Are there known issues in limited memory environments (Docker)?

something like https://gitlab.com/wg1/jpeg-xl/-/issues/99 ?

``` bash-5.1# free -m total used free shared buff/cache available Mem: 3936 166 3342 107 428 3460 Swap: 1023 513 510 ``` ``` bash-5.1# cjxl front.png front-s8.jxl -s 8 J P E G \/ | /\ |_ e n c o d e r [v0.3.7 | SIMD supported: AVX2,SSE4,Scalar] Read 4946x6933 image, 16.4 MP/s Encoding [VarDCT, d1.000, kitten], 1 threads. Killed ```

Well, or like https://gitlab.com/wg1/jpeg-xl/-/issues/192

The first problem seem to be that it isn't handled gracefully...

An error message when failing to allocate memory would be nice, yes

Good people. Couple of challenging questions for you perhaps! Does the jxl format have any multi component support like jpeg2000, and how to beat fake it! And is there any document that describes encoding speed for more complex architectures? I just want to make an argument for jxl in space

It supports up to 4099 channels/components (3 for visual/RGB, 4096 "extra channels")

What do you mean with "more complex architectures"?

Poor posed question, but how many MP/s can be achieved with something like jetson tx2. Or is this still far off the goal of jpeg xl in terms of target hardware?

jetson tx2 is dual-core NVIDIA Denver2 + quad-core ARM Cortex-A57. any guess of what kind of encode speeds we get there, <@!179701849576833024> ?

I have absolutely no idea what a denver2 is like 😄 if it's reasonably close to a A72, I think you should be able to get ~2 mp/s on it

So you are saying to us than social media and other BIG website have technical solution to estimate original jpeg and NOT re encode some jpeg because they see if it's a high jpeg compression and it's USELESS to re-encode it?

what encode speed setting are you talking about? s3 fd4 will be faster than s9 fd0 🙂

s3 fd0 IIRC

give me a couple of minutes and I'll give some up-to-date numbers on my Samsung A51

If it's a JPEG, you can just see what the quantization table is and avoid re-encoding because, you know, it's a JPEG already. If it's not a JPEG, then you cannot avoid re-encoding because you don't have the JPEG 🙂

How do you estimate that? My phone has A76

I just run it 😛

you can just compile cjxl/djxl in Termux and run it

Cross compiled using Android ndk?

no need to cross compile, just Termux and compile natively

Oh easy.

although cross compiling can be quite a bit faster

(depends on your mobile cpu and x86 cpu 😛 my personal phone compiles faster than my work laptop, say...)

single core s6 fd0 1.8 MP/s, s6 fd4 2.5 MP/s, all cores 5.43 and 6.61 resp

nice

s6 fd0 is pretty close to default encoding, which is good

I just want Google camera jxl encoding asap 🤓

Also Google photos jxl support

About 1,8-2x faster on A76 vs A73.

not surprising...

Is the speed enough for shooting 16mp photos?

64mp jpeg mode takes at least one or two second to save on my phone .

depends on too many factors

but it *should* be able to replace jpeg

Has anyone attempted (or even hinted at) a non-reference jxl encoder/library? I know it's early but I'm a bit curious...

Is this possible. Take jxl photo from native camera app at fast speeds and then compress them later (with slower speeds) on desktop or laptop without affecting the image quality?

not as far as I know - any specific reason why you would want it?

in theory yes, but I don't know if it's a good idea

Just to compare, really. The reference libraries aren't always known for their speed or compression efficiency.

I'd be surprised if a significantly faster/more efficient implementation is (easily) possible - we put quite a lot of work in that 🙂

Well, that's refreshing to hear <:BlobYay:806132268186861619>

-s 8 -q 87.76 -P 4 -X 39 -Y 30 -m -q 69.6 --intensity_target=310 --dots=0 --epf=1

what is bad about it?

should i always use the default

use `-d` not `-q`

even if the compression don't satisfy me

With some phones coming with over 108mp, Idk whether these speeds are enough to save them without taking too much time.

you *can* do quite faster encoding 🙂

Odds are a device made for taking pictures will have some form of HW encoder.

Hw encoder for images? I don't think so

Sure, digital cameras have them.

whether or not they'll support JPEG XL depends a lot on adoption

It would be nice to have jxl hw encoder with s7 speeds on phones and cameras.

With 16bit support 😝

(we actually use floats typically :P)

I do wonder what an FPGA-based encoder could do, sometimes

cost per unit, performance, density, and energy efficiency are better with asics than fpga

I've got one, but the tooling is hell

sure but FPGAs are much more flexible, and update-able with software

In particular, I can make a FPGA encoder (in theory), but not an ASIC encoder 😛

FPGAs allow shipping early because the system doesn't need to be as bug free

we can make ASICs if we need

I believe our TPUs are -- for example -- ASICs

the transistors are getting so cheap that people are really creative on what can be put into hardware -- and even compression algorithms are becoming a topic

for example Microsoft's Zipline is an exploration step in this direction

sure, but it's a lot easier to make an algorithm for FPGA to try it out 😛

random settings part 2

-S 6 -I 0.427 -g 2 -Y 70.72 -X 41.25 -q 81.1 -s 8

ok i will stop

for %i in (C:\Users\User\Documents\orb\*.png) do cjxl4 "%i" "%i.jxl" -s 6 -q 87.76 -I 0.427 -g 2 -Y 70.72 -X 41.25 -m --num_threads=2 for %i in (C:\Users\User\Documents\orb2\*.png) do cjxl4 "%i" "%i.jxl" -q 81.1 -s 8 --num_threads=2

the command works in 0.3.7

alternatively you could use only -q 87.76 modular

and s 6

or s7

it encodes but decoder don't read it

How about writing every random settings on a Excel sheet? And posting it's link here

but the -I with three 0.xxx don't work

intensity target with modular i think not

the thing that makes me nervous when i create a file and the decoder don't open

but i shouldn't be agitated

this is expected

but we don't know if is encoder fault that creates -i 0.xxx files that are unreadable

or is djxl

Just out of curiosity, does JPEG XL make a good replacement format for screenshots? Sure, transcoding a PNG screenshot to JXL is fine, but does screenshoting *to* JXL sound okay?

why not?

Understand that adoption in future devices and OS's as well as online services and websites needs to come to fruition once JXL's ISO standards are finalized

Sure, but I see no reason not to offer JXL as an option when screenshotting.

JXL lossless should be a drop-in replacement as afar as I'm concerned

Who wins? JXL lossless or PNG?

JXL lossless.

by a significant margin right?

I haven't compared directly

but something like 30% right?

For non photographic images, that is a good estimate.

For photographic types of images, 50% is not too uncommon.

have you compared a zopflinated png?

i can usually get 20-30% losslessly with zopfli out of png

the only issue is it's zopfli so it takes about 30 minutes for a 4k image <:YEP:808828808127971399>

Yes, I've compared with ECT.

JXL vs PNG isn't really much of a contest. JXL vs WebP is much more interesting.

<https://docs.google.com/spreadsheets/d/1ju4q1WkaXT7WoxZINmQpf4ElgMD2VMlqeDN2DuZ6yJ8/>

And this is a comparison with very optimized PNGs

So red is larger than jxl right?

Yep Below there are tabs with file sizes and also a comparison of the best PNG optimizers (there the colors are reversed, red is the smaller size for visual convenience)

I think this is the first time I see EMMA doing anything good

Wait that has to be a bug

EMMA is doing pretty bad on every tests

What is EMMA? I can't find anything about that codec on the web?

What are the comparisons and which EMMA (there are several versions with the same compressor name)?

Like on pretty much any tab you'll find BMF and EMMA on the far right

unless I can't read a table

No, it's only reverse colors, green is more effective

which is possible

uhhh

EMMA everywhere, red = bad ?

EMMA on the details page, green = good ?

https://encode.su/threads/2459-EMMA-Context-Mixing-Compressor

Ohh

I assume with context mixing this is veeerrry slow?

In the general table, I changed the colors since it was already created by Jon Sneyers and clearer as a comparison of all formats (but in separate tabs I compared with Jpeg XL all other encoders and red is a negative efficiency) Btw this is a different EMMA (but the basis is the same, I used GDC EMMA version from <https://globalcompetition.compression.ru/#leaderboards>)

while interesting on pure compression ratio it says nothing of speed <:SadOrange:806131742636507177>

Wait what's pglz and what dark magic is it doing?

Oh

It's for SQL apparently

it's probably very slow and ill suited to other content types

Nah I'm talking about it being very fast

The compression ratio seems somewhat ok

oh, I see, the scatter plot above

Because it is difficult to compare it as well as lossy compression, also because I was comparing very new and experimental formats, each new version can differ significantly in speed (for example very old versions of Jpeg XL were much faster and used all CPU threads, then it became very slow, and newer versions are faster, more efficient, but slower than the oldest)

And lossless WebP2 is crazy slow (because it hasn't been optimized at all yet)

honestly I wouldn't even test webp v2 yet

Google has their hand in every basket huh?

Avif, webp2,jxl

half of the compressors on compression.ru I've never even heard of <:Thonk:805904896879493180>

Most of them are closed source and designed to win benchmarks <:kekw:808717074305122316>

yeah, if it's not OSS I'm not interested

Though cmix is good

It's open source

Actually definitively the best compressor

Too bad it needs 32GB+ of ram and it's speed is measured in minutes per megabyte <:ReeCat:806087208678588437>

Hell maybe even hours per megabyte

that alone makes it not the best

Best as in compression wise

yeah, but I tend to prefer practical things to impractical ones

If we're talking best for daily use lzma2 and zip's deflate are the best

Repeatedly shown their worth

lrz is my fav, but never got the adoption zstd got

Also on some images with the same resolution Jpeg XL is much slower than others (so it is possible to create a very wrong test with a small number of images) For the experimental compressors I chose only the strongest ones for compressing images (to compare the maximum possible compressibility)

JXL seems very good, especially with how asymmetric it is

Still a 95 sec decode time seems very long

But I guess it's a half gig image

And such a thing is to be expected

In the GDC test it is a set of about 1 gigabyte of images

they used `--num_threads=1` <:WhatThe:806133036059197491>

I assume to make it equal

Since the more advanced ones probably aren't multi threaded

that's one way of defining 'equal'

I guess

Not my methodology 🤷‍♂️

This is more of a technical than a pragmatic graph

yeah

mine benchmarks are more pragmatic, but also out of date

Yep `--num_threads=0` was more correct for 1 thread (but Jpeg XL was only as a lower bar option from open formats)

oh actually they're more up to date than that page, which used 0.1.0

Yes, this is already an outdated version anyway, after which there have been significant changes Multi-threaded comparison would also be interesting (but in practice, especially when used on servers where many images are encoded simultaneously, it is rarely used)

fair, but lots of images are compressed by users before they're ever uploaded to a server

Yes, although users can also have a lot of images, and I don't think GDC was user-oriented (but it's also an interesting comparison for me, where I can find some new experimental encoders) And closer to practical use than, for example, the Hutter Prize comparison (which prioritizes the highest possible compression and also the old, not changing test set)

if you want to deal with proprietary formats, sure

Yes, but for experimental formats it is not so important, because even for open formats there is very little chance of their adoption as a standard (it should be created for this purpose from the beginning, it may be useful the methods they use, but even closed formats with GDC usually share what they used)

heys kittens

owo

Though the conversations can get a bit offtopic (no thanks to me lol) this isn't a general chat

You're probably looking for <#806898911091753051>

Looks like for icons especially jxl often loses

WebP lossless is quite good (most of the people who made it are here, btw, as they also made jxl)

Some things are just a matter of encoder optimization

We have mostly been focusing on larger images, not paying that much attention to tiny images

So the encoder is probably still doing some silly things

It makes sense since that's the application, photos and other user created imagery

Well we do want to be universally applicable

doesn't PNG do reasonably well for icons since they're relatively small regardless?

ideally in the far future you could use jxl lossless for that

Well it's easy to have large variations in size when the size is in the 50-500 byte range

With manual selection of options, JXL can usually beat lossless WebP on most images where it was previously worse (mainly because the current encoder is not always optimal)

True, but averaged over many images of different types, JXL seems to always hold the advantage

yeah, we've found a few and the devs are aware of most if not all of them

That's why I did my comparisons on different types of images with the size of each image for each format And yes, on certain single images almost any modern format can be better than another, even lossless AVIF, but the overall result is more important

For example here <https://docs.google.com/spreadsheets/d/1ju4q1WkaXT7WoxZINmQpf4ElgMD2VMlqeDN2DuZ6yJ8/>

The spreadsheet has Tabs for different types of images and the size and compression efficiency of each image for each format

Yes, especially for faster encoding speeds

And emoji/icons (but this is also because FLIF/WebP/WebP2 removes the invisible alpha)

Yes, it discards unnecessary alpha (without visual changes)

To be precise: WebP makes invisible pixels black, jxl currently keeps their RGB intact, and AVIF and WebP2 use premultiplied alpha which makes invisible pixels black but also reduces precision of semi-transparant pixels.

Yes, but this usually does not affect the image visually, it remains without visual losses (but might be important elsewhere, for example in games as some technical information) And it would be useful to have such an option in JXL as well (it's possible but not yet implemented in encoder options for lossless)

In WebP/AVIF encoders this can be enabled/disabled ```-exact ................. preserve RGB values in transparent area, default=off``` ```-p,--premultiply: Premultiply color by the alpha channel and signal this in the AVIF```

Also WebP (89 262)

JXL (67 071)

For now it's just a bruteforce, but in the future I hope the encoder itself will be more optimal in choosing About MA tree I think it is better to explain someone from the devs

as you can see in <#824000991891554375> , MA trees are a very expressive/powerful context modeling technique

the search space is enormous though

the current encoder, even at -s 9, is very far from exhaustive when it is trying to determine a good MA tree for the image

exhaustive search would be computationally infeasible, likely it would take longer than the age of the universe to really find the absolute best MA tree for a medium-sized image

so it boils down to making good heuristic decisions in the encoder, and different algorithms and settings are possible for that

use more of the source pixel to try

I 1 use all pixels

E make channels see each others (E 3 all colors channel see each other) seam one of the flags that always make smaller file but is slow

work only on s 9

g is how big are the separate squares for encoding, big square -> more probability to find an order. g 0-3, default is 2

Default is 1

Group size is 128 << that number

So 128 for 0, 256 for 1, 512 for 2 and 1024 for 3

For jxl art we use -g 3

(usually)

Bigger groups means less parallel decode (so slower on multicore)

It can mean better compression (because less boundaries that are poorly predicted) or worse compression (because less opportunity to do localized RCTs and palettes)

is the image quality at q 60.4 improving?

like is any better than doing

for %i in (C:\Users\User\Documents\jpg*.png) do cjxl "%i" "%i.jxl" -I 3.9 -X 8 -P 8 -Q 86.6 -m -s 8 --num_threads=2 for %i in (C:\Users\User\Documents\jxl1*.png) do cjxl "%i" "%i.jxl" -q 60.4 -s 4 --faster_decoding=3 --num_threads=2

with 0.3.5 or so

i think yes because you have 1 less generation loss

Thumbnails have stopped working. What do I do?

If you are on kde, check your `/usr/share/kservices5/imagethumbnail.desktop` MimeType section. There must be image/jxl;

Windows 10.

big step for JPEG XL: https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c16

Erik Andre from Facebook expresses support for JPEG XL image coding

"""Just wanted to chime in and mention that us at Facebook are eagerly awaiting full JPEG XL support in Chrome. We've very exited about the potential of JPEG XL and once decoding support is available (without the need to use a flag to enable the feature on browser start) we're planning to start experiments serving JPEG XL images to users on desktop web. The benefit of smaller file size and/or higher quality can be a great benefit to our users. On our end this is part of a larger initiative to trial JPEG XL on mobile (in our native iOS and Android apps as well as desktop)."""

maybe this will get mozilla off their ass

I consider this is one of the three biggest achievement for us -- right along with the chrome integration and standardization

Mozilla is very responsive and kind as usual -- I don't see big worries there

Just we have been too busy to take them into account appropriately

Hope the JPEG meeting goes well!

it's a plenary meeting, they tend not to be the most interesting activity of the day...

unless they go on for 24 hours, of course?

please don't even suggest that...

there have been 4+ hours plenaries

I've tried to compile jpeg-xl via `./ci.sh opt` on Ubuntu 20.04 through WSL, and I'm getting this error. I've installed all the libraries they've told me to, so I'm not really sure what's going on. It compiles fine on Debian 10 Buster (WSL).

``` [46/464] Linking CXX static library third_party/highway/libhwy.a Compiled HWY_TARGETS: AVX3 AVX2 SSE4 Scalar HWY_BASELINE_TARGETS: Scalar [293/464] Linking CXX executable lib/jxl_gbench FAILED: lib/jxl_gbench : && /usr/bin/clang++ -DJXL_DEBUG_WARNING -DJXL_DEBUG_ON_ERROR -funwind-tables -Xclang -mrelax-all -Xclang -mconstructor-aliases -fno-omit-frame-pointer -O2 -g -DNDEBUG -fPIE -pie lib/CMakeFiles/jxl_gbench.dir/extras/tone_mapping_gbench.cc.o lib/CMakeFiles/jxl_gbench.dir/jxl/dec_external_image_gbench.cc.o lib/CMakeFiles/jxl_gbench.dir/jxl/enc_external_image_gbench.cc.o lib/CMakeFiles/jxl_gbench.dir/jxl/splines_gbench.cc.o lib/CMakeFiles/jxl_gbench.dir/jxl/tf_gbench.cc.o -o lib/jxl_gbench lib/libjxl_extras-static.a lib/libjxl.a /usr/lib/x86_64-linux-gnu/libbenchmark_main.a third_party/brotli/libbrotlienc-static.a third_party/brotli/libbrotlidec-static.a third_party/brotli/libbrotlicommon-static.a -lm third_party/highway/libhwy.a -ldl third_party/libskcms.a /usr/lib/x86_64-linux-gnu/libtcmalloc_minimal.so third_party/liblodepng.a /usr/lib/x86_64-linux-gnu/libgif.so /usr/lib/x86_64-linux-gnu/libjpeg.so /usr/lib/x86_64-linux-gnu/libpng.so /usr/lib/x86_64-linux-gnu/libz.so third_party/sjpeg/libsjpeg.a /usr/lib/x86_64-linux-gnu/libIlmImf.so /usr/lib/x86_64-linux-gnu/libImath.so /usr/lib/x86_64-linux-gnu/libHalf.so /usr/lib/x86_64-linux-gnu/libIex.so /usr/lib/x86_64-linux-gnu/libIexMath.so /usr/lib/x86_64-linux-gnu/libIlmThread.so /usr/lib/x86_64-linux-gnu/libpthread.so /usr/lib/x86_64-linux-gnu/libbenchmark.so.1.5.0 -pthread /usr/lib/x86_64-linux-gnu/librt.so && : /usr/bin/ld: /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/Scrt1.o: in function `_start': (.text+0x24): undefined reference to `main' clang: error: linker command failed with exit code 1 (use -v to see invocation) [302/464] Building CXX object lib/CMakeFiles/encode_test.dir/jxl/encode_test.cc.o ninja: build stopped: subcommand failed. + retcode=1 ```

I'm not yet well-versed in C/C++, nor compiling code, so any help is appreciated. Thank you!

Well, I guess it'll be another invisible win for users. Most people probably won't even realize they're being served JPEG XL files until they suddenly can't share them with other people :> Ah, the joys of adopting new formats.

not sure what is wrong there... can you try `./ci.sh opt -DENABLE_TESTING=Off`?

Hm. Alright then, I'll try that.

``` [295/464] Linking CXX executable lib/jxl_gbench FAILED: lib/jxl_gbench : && /usr/bin/clang++ -DJXL_DEBUG_WARNING -DJXL_DEBUG_ON_ERROR -funwind-tables -Xclang -mrelax-all -Xclang -mconstructor-aliases -fno-omit-frame-pointer -O2 -g -DNDEBUG -fPIE -pie lib/CMakeFiles/jxl_gbench.dir/extras/tone_mapping_gbench.cc.o lib/CMakeFiles/jxl_gbench.dir/jxl/dec_external_image_gbench.cc.o lib/CMakeFiles/jxl_gbench.dir/jxl/enc_external_image_gbench.cc.o lib/CMakeFiles/jxl_gbench.dir/jxl/splines_gbench.cc.o lib/CMakeFiles/jxl_gbench.dir/jxl/tf_gbench.cc.o -o lib/jxl_gbench lib/libjxl_extras-static.a lib/libjxl.a /usr/lib/x86_64-linux-gnu/libbenchmark_main.a third_party/brotli/libbrotlienc-static.a third_party/brotli/libbrotlidec-static.a third_party/brotli/libbrotlicommon-static.a -lm third_party/highway/libhwy.a -ldl third_party/libskcms.a /usr/lib/x86_64-linux-gnu/libtcmalloc_minimal.so third_party/liblodepng.a /usr/lib/x86_64-linux-gnu/libgif.so /usr/lib/x86_64-linux-gnu/libjpeg.so /usr/lib/x86_64-linux-gnu/libpng.so /usr/lib/x86_64-linux-gnu/libz.so third_party/sjpeg/libsjpeg.a /usr/lib/x86_64-linux-gnu/libIlmImf.so /usr/lib/x86_64-linux-gnu/libImath.so /usr/lib/x86_64-linux-gnu/libHalf.so /usr/lib/x86_64-linux-gnu/libIex.so /usr/lib/x86_64-linux-gnu/libIexMath.so /usr/lib/x86_64-linux-gnu/libIlmThread.so /usr/lib/x86_64-linux-gnu/libpthread.so /usr/lib/x86_64-linux-gnu/libbenchmark.so.1.5.0 -pthread /usr/lib/x86_64-linux-gnu/librt.so && : /usr/bin/ld: /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/Scrt1.o: in function `_start': (.text+0x24): undefined reference to `main' clang: error: linker command failed with exit code 1 (use -v to see invocation) [304/464] Building CXX object lib/CMakeFiles/encode_test.dir/jxl/encode_test.cc.o ninja: build stopped: subcommand failed. + retcode=1 ``` I seem to be getting the same error. Huh.

ok, let's see if my sleep-deprived brain can figure this out

` ./ci.sh opt -DENABLE_TESTING=OFF` seems to skip a lot of the tests, yes, but gives the same error ``` [9/193] Linking CXX executable lib/jxl_gbench FAILED: lib/jxl_gbench : && /usr/bin/clang++ -DJXL_DEBUG_WARNING -DJXL_DEBUG_ON_ERROR -funwind-tables -Xclang -mrelax-all -Xclang -mconstructor-aliases -fno-omit-frame-pointer -O2 -g -DNDEBUG -fPIE -pie lib/CMakeFiles/jxl_gbench.dir/extras/tone_mapping_gbench.cc.o lib/CMakeFiles/jxl_gbench.dir/jxl/dec_external_image_gbench.cc.o lib/CMakeFiles/jxl_gbench.dir/jxl/enc_external_image_gbench.cc.o lib/CMakeFiles/jxl_gbench.dir/jxl/splines_gbench.cc.o lib/CMakeFiles/jxl_gbench.dir/jxl/tf_gbench.cc.o -o lib/jxl_gbench lib/libjxl_extras-static.a lib/libjxl.a /usr/lib/x86_64-linux-gnu/libbenchmark_main.a third_party/brotli/libbrotlienc-static.a third_party/brotli/libbrotlidec-static.a third_party/brotli/libbrotlicommon-static.a -lm third_party/highway/libhwy.a -ldl third_party/libskcms.a /usr/lib/x86_64-linux-gnu/libtcmalloc_minimal.so third_party/liblodepng.a /usr/lib/x86_64-linux-gnu/libgif.so /usr/lib/x86_64-linux-gnu/libjpeg.so /usr/lib/x86_64-linux-gnu/libpng.so /usr/lib/x86_64-linux-gnu/libz.so third_party/sjpeg/libsjpeg.a /usr/lib/x86_64-linux-gnu/libIlmImf.so /usr/lib/x86_64-linux-gnu/libImath.so /usr/lib/x86_64-linux-gnu/libHalf.so /usr/lib/x86_64-linux-gnu/libIex.so /usr/lib/x86_64-linux-gnu/libIexMath.so /usr/lib/x86_64-linux-gnu/libIlmThread.so /usr/lib/x86_64-linux-gnu/libpthread.so /usr/lib/x86_64-linux-gnu/libbenchmark.so.1.5.0 -pthread /usr/lib/x86_64-linux-gnu/librt.so && : /usr/bin/ld: /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/Scrt1.o: in function `_start': (.text+0x24): undefined reference to `main' clang: error: linker command failed with exit code 1 (use -v to see invocation) [18/193] Building CXX object third_party/highway/CMakeFiles/logical_test.dir/hwy/tests/logical_test.cc.o ninja: build stopped: subcommand failed. + retcode=1 ```

You don't *need* to help, by the way, if it's too much trouble for you. I really appreciate it though!

try uninstalling `libbenchmark-dev`

(and then clearing the build directory and rerunning `./ci.sh opt`)

from what I understand, the command line there should *not* give that error, because `main` should be defined in `/usr/lib/x86_64-linux-gnu/libbenchmark_main.a`... this might be a broken package on your system, but if you uninstall `libbenchmark-dev` then we shouldn't even try to compile that file

okay, okay, i'll do that

<@!179701849576833024> Looks like it worked! I wonder why the package was broken in the first place, but no matter, thank you so much for the help!

you're welcome! I have no idea what was broken but happy to help

I don't know if the facebook app has a 'save image' and if it does, they can convert at that time. In Chrome I believe they can reload the image as image/jpeg (or they could also convert locally) if someone wants to save it.

yes it has even on mobile

facebook

you can save with the left button other poeple foto and it will appears download

in that case they need to convert it at that time I suspect

maybe is called save photo and not download

they can also re-download

It would be more cool if they just saved the JXL and forced everyone else to implement it.

Wouldn't redownloading somewhat defeat the purpose?

technocrats have a responsibility to accommodate a good life for the technically handicapped

ideally users would not have to think about this at all

if they need to think -- we very quickly start eating the savings a new format can create

humans are 1000x expensive than the computers, cables, and energy used to transmit data 😄

Yeah, yeah, I tried to make that a cool(TM), but Discord wouldn't allow the trademark character.

In terms of money? Or natural resources? 🙂