JPEG XL

Oh. probably I understood something wrong

With the current improvements, it's more like +5% on low quality photos and 20% quality on directional art <:kekw:808717074305122316>

degradation of quality in one type of image shouldnt be much of a problem as long as it isnt worse by a large margin

especially since there will most likely be more findings that can improve on the one that got worse without harming the other

also, at least to me, it is much easier to notice quality loss in art

I understand, Thank you for your work 🙂

gatekeeping encoding features because they apply for one kind of thing is silly imo. that kind of thing could be intelligently autodetected by encoder, and possibly applied to some areas and not others, even if right now it needs manual knob. also, even manual knobs can be handy for artist workflows

Just add line art [✔️] to gui when saving jxl.

yeh exactly

http://0x0.st/-yz9.jpg

https://en.m.wikipedia.org/wiki/Joint_Photographic_Experts_Group

these fonts look awful

wtf is with that rendering of p in some places

maybe is a bit oblique

but anyway is awful

not something i would read on a tablet

What's a Picture?

As in, what differentiates it from a photo?

i didn't encode anything new

I wonder if it would make sense to try to convert fonts to splines, so in authoring tools you could use such a font and it would get encoded with splines (or with patches that come from splines)

Wouldn't that be too expensive to decode?

For bold/large text, jxl splines are not that useful in my limited experience, because we don't have a stroke width, we have a blurry thing. But for thin/small fonts (where dct has the most trouble anyway), splines might be suitable

Expensive to decode: things can probably be sped up quite a bit, especially for the small sigmas that are useful for text (and you only need to render each letter/point size once, thanks to patches)

https://jxl-art.surma.technology/?zcode=C89MKclQMDYw4PJIzUzPKAEzubiCC3Iy81K5FIBA18hAgSI46EwxpNQQsCmmBgoWUPNMDBQMjSBsI2O4sJGBgYKRmQFMsZGpAZdrXgo0ZLl0FYJTS4BOMTAAAA

Why do I see a red outline here?

I would expect this image to be grayscale

(things are getting way out of the 0..1 comfort zone here of course)

<@!604964375924834314>

I don’t understand, when I save the source and run `jxl_from_tree` on it myself, the resulting JXL is also 70 bytes but does not display any spline

wait, I tried again and now it does

I have no idea what changed

but it also looks different

oh 73 bytes now?

ah, here is the blank one now

so `jxl_from_tree` is not deterministic on that file

that’s encouraging

yep, uninitialized read

experimenting with segmenting the image in photo and nonphoto parts, encoding photo with vardct and nonphoto with modular

example above is decoded with -s 8 so you see the vardct part blurry

here the resolution of the segmentation map is 1:64

my heuristics are not great but they kind of work (with some false positives and negatives)

the outlines you see around the photo part are not intended, I think it's because I just encode full images that get added, and the not-encoded-part is black (0,0,0)

you see that black around the edges, I dunno why, probably gaborish or something

it's a funky effect anyway 🙂

what do you replace the nonphoto parts with in VarDCT?

the black around the edges likely comes from DCT blocks going across the (black, I suppose) replacement border

I assume it disappears without `-s 8`

yes it disappears

replacing the nonphoto parts with some background color like in patches would make more sense I guess (but it's trickier to pick that color)

Pretty good detection on this image, what about efficiency on such mixed images and how would that work with reducing the quality?

Perhaps a lossy palette would also be useful here (because lossy modular creates noticeable pixelation after a certain quality), like AV1 does: <https://github.com/AOMediaCodec/SVT-AV1/blob/master/Docs/Appendix-Palette-Prediction.md>

why is it trickier?

you *are* using kReplace blending for the nonphoto parts, right? 😛

no

it's kAdd

probably a good idea to do so then

well both are just full frame sized

you can still do multiple kReplace patches 🙂

although it is a bit more painful

if it's in big chunks like 64x64, yes

I want to do it more fine grained if possible though

tbf you probably should detect big rectangles of photo/nonphoto (even if not 64-aligned)

also I'm doing the nonphoto in (quantized) XYB and adding it with a huge patch, not sure if that's the best approach

(could also do it in sRGB and use frame blending)

I think XYB is a better option but I dunno

I think so too but not sure about the quantization if the nonphoto stuff contains gradients

big rectangles of photo will usually work but not all photo parts are rectangular

well it will work in most cases - and when it doesn't, you can always use alpha-blend patches 😄

getting some improvements in compression/quality, though it's at a big cost in enc/dec speed (might be because huge patches are maybe not blended in the most efficient way?)

``` ClassD_APPLE_BasketBallScreen_2560x1440p_60_8b_sRGB_444_000.ppm.png Encoding kPixels Bytes BPP E MP/s D MP/s Max norm pnorm BPP*pnorm Bugs ----------------------------------------------------------------------------------------------------------------- jxl 3686 539560 1.1709201 1.798 24.019 1.86591029 0.59592572 0.697781424948 0 jxl:separate 3686 484890 1.0522786 0.721 3.958 2.19656682 0.65291474 0.687048240555 0 jxl:d2 3686 378848 0.8221528 1.833 22.743 3.60270667 0.93827879 0.771408511975 0 jxl:d2:separate 3686 356936 0.7746007 0.737 3.974 3.22002673 0.92808257 0.718893404432 0 jxl:d3 3686 304257 0.6602799 1.910 23.743 4.17911577 1.23043588 0.812432138116 0 jxl:d3:separate 3686 278003 0.6033051 0.705 4.447 3.96620774 1.17577899 0.709353486654 0 jxl:d4 3686 260803 0.5659787 1.786 14.222 5.61551571 1.53005294 0.865977425136 0 jxl:d4:separate 3686 236307 0.5128190 0.731 3.444 4.62687683 1.42663903 0.731607616013 0 jxl:d5 3686 230743 0.5007444 1.865 13.427 9.02261162 1.94301577 0.972954183865 0 jxl:d5:separate 3686 211319 0.4585916 0.794 4.231 5.60950613 1.65590114 0.759382321131 0 jxl:d8 3686 175870 0.3816623 1.888 13.239 11.13273525 2.79994567 1.068633777045 0 jxl:d8:separate 3686 161431 0.3503277 0.820 4.210 8.94032955 2.34201284 0.820471951791 0 ```

``` nonphoto_JonScreenshot_1200x1400_8bit_sRGB.ppm Encoding kPixels Bytes BPP E MP/s D MP/s Max norm pnorm BPP*pnorm Bugs ----------------------------------------------------------------------------------------------------------------- jxl 1680 126861 0.6041000 2.656 23.792 1.45755124 0.48071558 0.290400280210 0 jxl:separate 1680 102180 0.4865714 1.230 5.079 1.73315644 0.48175152 0.234406527574 0 jxl:d2 1680 100106 0.4766952 2.680 21.553 2.04487586 0.59050652 0.281491644342 0 jxl:d2:separate 1680 87044 0.4144952 1.241 5.020 2.14929438 0.69423165 0.287755711316 0 jxl:d3 1680 84446 0.4021238 2.791 21.775 3.11525416 0.82836638 0.333105843060 0 jxl:d3:separate 1680 72008 0.3428952 1.229 5.046 3.28416300 0.96416079 0.330606144826 0 jxl:d4 1680 75510 0.3595714 2.945 12.832 3.51071453 0.96273206 0.346170943750 0 jxl:d4:separate 1680 65121 0.3101000 1.185 4.372 4.04519129 1.14461236 0.354944293284 0 jxl:d5 1680 68877 0.3279857 2.633 12.460 4.62320328 1.21067688 0.397084722550 0 jxl:d5:separate 1680 58110 0.2767143 1.124 4.540 5.59611368 1.46440364 0.405221407205 0 jxl:d8 1680 54622 0.2601048 2.502 12.429 7.50739479 1.96001851 0.509810148368 0 jxl:d8:separate 1680 47183 0.2246810 1.216 5.138 6.74870634 1.90634576 0.428319581608 0 Aggregate: 1680 75597 0.3599858 1.802 9.023 3.36590130 0.95190569 0.342672572549 0 ```

👍🏻

So, it could be something like `--patches=2` and maybe enabled with `-s 9` by default, also interesting how this would work not only on UI/text images but also on art content 🤔

for dec speed I strongly suspect it's because modular is *a lot* slower - we probably need a "webp mode" for this to work well (and "stitching" together the nonphoto pieces in a smaller frame likely helps a lot too - also for i.e. memory...)

having said that, pretty cool results 😄

any chance there's a handy guide to the adaptive quant + use of side info in predictions?

nope! 😛

https://github.com/libjxl/libjxl/pull/466

<@!794205442175402004> Also, it would be nice to change the options for lossless mode segments, like maybe a lossy palette or faster for decoding `-i 0` could be useful

yes - one thing that's a bit annoying is that the modular mode stuff is still done in XYB, which likely is not the best idea (but it is easiest to implement)

doing the separation with multiple RegularFrames instead of with one big patch probably makes more sense - but then you need to detect good rectangles and stuff

<@!179701849576833024> patches need to be in the same color space as what you're adding them to, right? so XYB if you want to add them to an XYB frame. But with frames I could have a modular sRGB frame followed by vardct frames that use XYB and that should work with any blend mode, right? (kReplace if you could detect photo rectangles and do multiple vardct frames, kAdd if you want to do one big vardct frame) as long as the color profile is representable by an Enum...

yes, in theory - but I think XYB is OK anyway 😛

(you *can* choose scaling factors...)

I suppose a palette in RGB or in XYB doesn't make a difference, but for synthetic gradients that were computed in RGB, things might work better in RGB

<@!794205442175402004> What's a Flyby fix? Will it improve the patches logic? <https://github.com/libjxl/libjxl/pull/466>

it's a fix that happened because a bug was found in existing code so it's not the main purpose of the pull request but it does fix something as a side effect

and yes, it improves vardct mode patches

but not the detection 😛

nothing changes in the detection, but the way they are encoded is more sensible now (it used to be too high quality, leading to unnecessary bytes used to represent the patch more accurately than what was useful)

Also, sometimes the reduction of the palette is very strong in modular mode, perhaps on a low quality setting is worth using VarDCT for more blocks or do something like smoothing gradients

Source

`-d 8`

`-d 8 separate`

And the borders are still visible <:PepeHands:808829977608323112>

I think the approach needs to be changed, kAdding a whole frame is not a great method for various reasons

It might be better to do something like multiple kReplace Modular patches so the VarDCT part can avoid discontinuities (e.g. could apply strong blur to the holes or something like that)

Btw, the usual already existing patches are fully lossless when used in VarDCT mode?

No, they are done in quantized XYB (but otherwise lossless, yes)

Ah and lossy patch detection also allows different copies to be (very) slightly different

Below d3, the patches get subtracted from the vardct image, so if it's a perfect match and there is no quantization error, there will be no residuals in the vardct part, but if there's some error, vardct can still correct it

Because it is useful for high quality settings to use patches not only for better compression, but also for places where VarDCT can create noticeable artifacts and it is important that the modular mode is also guaranteed to be free of noticeable distortion

Yes, probably better things can be done than what we do now, which is the equivalent of something like `cjxl -m -R 0 -P 5 -Q 80`

It might be worthwhile to use (delta) palette instead, for example

(but the default delta palette is made for RGB, not XYB, and we don't have an encoder for that atm)

Is there any plan to add jxl support to stb_image.h? It'll gonna drive adoption rate 100x consider how popular the library is

https://github.com/nothings/stb

welp they didn't accept new formats, too bad > Will you add more image types to stb_image.h? > No. As stb_image use has grown, it has become more important for us to focus on security of the codebase. Adding new image formats increases the amount of code we need to secure, so it is no longer worth adding new formats.

I suppose in principle you could just concatenate all files in libjxl in the right order, remove the internal #includes, and call it stb_jxl.h, right?

(if you don't mind it being C++)

You can just as well just statically link with libjxl though

In my opinion the nice thing about software libraries is that you can do dynamic linking, which means not only do you avoid duplicating binary code, also you only need to update one place to update all dependencies.

People loves single header libraries I see lots of recent libs releasing these days offers this as a feature https://github.com/randy408/libspng

Is that because it is easier than to figure out how to statically link?

yeah

tbh i would use stb_image if i wanted something dead simple to integrate, not if i actually wanted performance or a variety of codecs. and i might switch from it to another library (depending on the image format) if my project grew, especially because i might end up with better build infrastructure that would make it easier to link against a more complicated library

in [1] are they saying that that's their criteria for "no known security bugs" and stb_image just isn't fuzz tested? or is there actually a known vulnerability in stb_image?

dunno, the definition is really vague about it

https://github.com/libjxl/libjxl/pull/473

> On a set of 9 screenshots, this gives a ~10% improvement in bpp*pnorm, more on higher distances than on lower distances (3.3% at d1, 8.1% at d3, 18.5% at d10)

that regression has been there for at least a year or so, so not sure if it should be called a regression or just an encoder bug that has basically always been there

for photographic images it doesn't make any significant difference, but for nonphoto / mixed photo+nonphoto, this makes quite a big difference

ah but stb_image implements all the formats it can decode... it's *never* going to add JXL or AVIF xD

writing a JXL decoder in a single header is not going to happen any time soon

The original ideas for splines are features like a single hair poking out from the head or a telephone line hanging on the sky -- today those are full DCT matrices when the line is oblique, DCT is terrible with them. I was thinking that eventually we may be able to detect using ML where to model these with splines and then use simple optimization for fitting.

Maybe classic vectorization algorithms might also work

for some artistic impressions possibly would be great -- I'm thinking we will have an intern project in two years to do hair splitting

Some heuristic to detect the "thin line on smooth background" case, then classic vectorization to find the line, then some optimization to find the best fitting spline params, or something like that

yeah!

Yes, top message in <#822120855449894942> should help

https://artifacts.lucaversari.it/ https://imageglass.org/moon https://mega.nz/file/fA8CnAIT#FZiMDYy1tEqDhDFy6ZL5hixvSug1lxpEEk229L2THu4

libjxl image quality is incredible feels like running webp2, nhw codec and the same codec jxl at the same time

some could argue the image has some blocking

but honestly great quality

people could dislike that artifacted look

me not

honestly i like luca versari work

the artifacts are very pleasing

there's some work indeed

https://storage.googleapis.com/downloads.webmproject.org/releases/webp/WebpCodecSetup.exe

https://en.wikipedia.org/w/index.php?title=WebP&diff=prev&oldid=1037977338

-q 77.837 -s 5 --use_new_heuristics --gaborish=1 -I 0.521

trying this probably -d can't get this accurate without compiling xiota fix

and probably even that don't fix it

https://artifacts.videolan.org/x264/release-win64/

x264-r3046-fa26446.exe 17M 10-Feb-2021 21:10

It has a pleasing effect like this encoder on slowest speed and CRF 15

don't know if still inflates instagram image sizes or is worth it

but is fantastic stuff

artifacts are definitely more noticeable

it deletes text in grey automatically

good rate control

not good for gay photos

because it doesn't preserve banding

if there is a photo like that gone through imagegonord it automatically tries to reduce the palette and not a more uniform banding

so jpeg xl is going to a different direction

the speed was fast 4,3 mpx on 1 core i3 330m

ram usage 780-1,1 gb with bigger photos

anyway good encoder

more than i expected on 4,3 mpx/s

Anyone going to submit something to the <#824000991891554375> compo?

No, we let you win. ;)

I don't think I will participate

Not fair if the contest organizer who makes the rules also participates

Honestly a

-q 84.498 -s 7 --epf=0 -I 0.93 --gaborish=0 --dots=0

that looks better

is better than

a -q 77.837 -s 5 --use_new_heuristics --gaborish=1 -I 0.521 that looks good

jxl is now only 10% better than webp

cavif rs is crap

but without the tools jxl looks worse

Also about vectorization https://youtu.be/EvGA5qCfy9I?t=294

May be it works better on anime episodes.

Many anime have quite complex backgrounds

Yeah

big improvement in this build

which commit dude

I am not very optimistic of vectorization -- or perhaps just my eyes are not compatible with it

it will of course work very well with vector content such as peppa pig

but commonly those cases are not where the bulk of bits are -- focusing on it is focusing on a niche

auto vectorisation is quite bad

manually vectorising is quite good but very time consuming

and ofc only really works if it's simple content

Is there anywhere a list of all the options in benchmark_xl or their equivalents from jxl, webp, etc.?

anything that can be done manually will find a neural solution at some stage

I think only in the code. It's a bit of a mess tbh, we should at some point refactor both cjxl and benchmark_xl to use the encode api and to use a unified mechanism to set options

we have technical debt in our codebase in relation to that

until we froze the format we were only using code as a vehicle to define the format

code quality was not a priority

that started to change in early 2020 -- we planned to freeze in August 2020 (and ended up freezing in December, mostly because we got more ambitious in reducing decoder size for android apps)

our early 2021 went into preparing for the practical world (with guidance from facebook), and to integrate the codec into Chrome

and lots of security issues

now we are at a stage where we can make further refinements in image quality and improve on production quality in the code base

as an example cjxl doesn't use the API that the library provides

when we fix these things, we will also improve on the related documentation

It's only natural that you have an encoder/decoder before you have a nice library api

i don't want warning message for d 0.3 d 8

Hello, I have some question about cjxl --separate feature(pr466), could you teach me some detail about this feature? > https://github.com/libjxl/libjxl/pull/466 1. non-photographic frame Modular patch will use which transform? 2. If I input a pixel art image(full non-photographic image) on separate mode, make a big Modular patch for full image will increase file size? 3. If don't mind decoding time, I guess --separate feature should be the best compress method for non-photographic image contents(drawing)?

it's still very experimental, I dunno what the best way to proceed with it is

two full frames is probably not the best approach, it's probably better to make smaller modular patches

I understand, thank you very much 🙂

how convert a png photo in 12 bit jxl

what is the command to specify 12 bit

please help

`--override_bitdepth 12` iirc

i did

for %i in (C:\Users\Utente\Documents\8\*.png) do cjxl -s 9 -d 0.787 -p --epf=2 --dots=0 -I 0.828 --faster_decoding=4 --photon_noise=ISO4780 --intensity_target=281 --override_bitdepth 12 %i %i.jxl

https://artifacts.lucaversari.it/libjxl/libjxl/2021-08-25T13%3A38%3A37Z_a6867904bbb5e44191d22a27f850d2e8d5cdb005/

for developing a raw file from a phone

but some images are dark so i should fix exposure

or use the jpg

how override_bitdepth works?

because to me without it creates same file from a png

anyway the result is good enough even without 12 bits

.....

-q 90.062 --gaborish=1 --epf=1 -I 0.94 --photon_noise=ISO424

this with latest build

i won't test generation loss because is pointless for me

also in the newest build is listed the current usage of PHOTO noise

What are you doing with raw then

I dont remember

It should be 19.00 25 August 2021 libjxl

Yes

There is less block boundary

Artifacts

Hope in 0.6 standard settings will work well

First learn to encode with default settings.

The 57 KB Is too high quality for current nightly encoder

Ah i dont post anything

Try for yourself if you want

Is a nightly version

downloading those you don't solve anything

you need a stable version and is far

https://ieeexplore.ieee.org/document/9505599

this was not merged

many things have to be merged from 24 days

quality at various qualities especially at lower than 83.428

various things have to be improved to make a final version

i guess final version is 1.0

3.14.15-9265 will be the final version

taking a leaf out of tex? 😛

for %i in (D:\DOCS\BACKUP\XIAOMI\1\Screenshots\*.jpg) do cjxl -j -s 7 -d 0.392 -I 0.283 --epf=2 --dots=1 --patches=1 --faster_decoding=3 %i %i.jxl

s 8 blurs everything in current encoder

Using jpg source with vardct -_-

Doing -d 0.392 on jpeg originals is silly, that is most likely higher quality than the original jpeg

Doing --epf 2 in combination with very high fidelity is also silly, those filters are made to make low fidelity look better, they likely do more harm than good at high fidelity

in fact the text is blurry

is almost a pain

Epf might blur some text, I dunno (it is supposed to preserve edges but I don't know how foolproof it is)

but the stars in the sky are good

not even artifacts

i don't think is quality

or decent enough

because they are not default settings

don't know

the compression isn't also extraordinary for some photos

is a nightly build

or d 0.478 s 6 faster decoding 1 could be enough

the current encoder uses good the ram

it uses more ram

i don't think is optimized for print or real usage for people that don't have the ram

but for my needs is enough

Not good enough

subpixel-LCD-rendered text was not a huge priority, and I decided against weighting it in the benchmarks leading to JPEG XL's design decisions

I consider that in the future the need for subpixel LCD text will be removed

also, subpixel LCD stuff is commonly not something that can be shared from a display to display -- the pixel order is different in different displays -- so it makes more sense as a graphics trick than a first class thing in an image format

my (perhaps false) expectations is that 4k and 8k monitors will make lcd subpixels much less interesting and it already is not used on (all?/most?) mobile phones

Subpixel rendering also doesn't work if you want to rotate your phone

I just think it is not the right thing to focus a lot on for an experience

butteraugli and other modeling we do considers that all pixels are in line

we could resample pixels for a display's subpixel style and orientation

but it is for not much benefit with the increasing pixel density

Next project of mine will be integrating jxl. I think it’s ready for prime time now.

integrating it in what?

Wow discordapp with jxl support

in discord? <:WhatThe:806133036059197491>

His name discordapp

My new website

When the part with jxl is deployed I’ll post the link to the part that uses it . But I do hear that discord is also looking at it from my sources, but not “really”

The digits so far are impressive, about 500kb to a megabyte for each archived photo converted from JPEG to jxl

Hey there! Happy to share some progress for the JXL bulk converter using WASM for clientside conversions. Release sometime this year on jpegxl.io. Parameters and UI is WIP. 🙂

Super excited to bring this to a live version

Wonderful

Hello <@!532010383041363969> sorry for ping, About avif DSSIM score better than jxl, this situation also happen on my drawing content, for some image case, high quality(jxl d1.0~0.5) and near file size, DSSIM say avif is better than jxl, but maxButteraugli say avif have big error, Butteraugli 3-norm or 9-norm say avif and jxl both have good quality(near 0.5). (and sometime maxButteraugli_jxl and maxButteraugli_old have different assessment) > https://encode.su/threads/3397-JPEG-XL-vs-AVIF?p=70690&viewfull=1#post70690 And about libjxl pr403, I don't understand why After 'opt2' version jxl:d0.8:epf0 get maxButteraugli 2.81184077, Theoretically high maxButteraugli score, it's meant compressed image have big error, but this pr removes annoying ringing artefacts, I understand target distance just a target, but get maxButteraugli 2.8 on d0.8, I thought this situation is too risky. (VMAF also have some special issue, if enable some psy parameter on aomenc, psy optimize can increase video quality, but reduce VMAF score) > https://github.com/libjxl/libjxl/pull/403

I remember back in the FLIF days, there was a flif.js that allowed you to render a FLIF image on a canvas

but since FLIF was very slow to decode (unlike JXL), there was very little incentive to use it

since the time you'd save from lower bandwidth consumption was usually eaten by the browser munching on JS

I'm wondering if there's a similar jpegxl.js you can use now, since jpegxl is actually very fast to decode

haven't seen anything easy to use yet, but there certainly are js/wasm builds, e.g. squoosh.app (which has both encoder and decoder)

By the way, if you do a lossless jpeg transcode, is there a way to revert losslessly?

some minimal wasm decoder would be nice to have - I don't think polyfilling is a very good solution in most production settings, but it could be good enough for some use cases, especially if users can just enable the flag to get native decoding

i.e. take a jxl that was originally from a JPEG and losslessly turn it *back* into a jpeg, assuming it doesn't use any new features like true lossless compression

yes, `cjxl in.jpg tmp.jxl; djxl tmp.jxl out.jpg` and in.jpg should be bit-identical to out.jpg

bit-identical in image data or bit identical in file data?

bit identical in file data

if you only care about image data, you can do `cjxl in.jpg tmp.jxl -strip` and save a few more bytes

So, if I have a webserver, I can store jxl internally, and scan the user-agent header. If the user-agent header is known to support jxl then I can just provide the jxl, but if the header is not on a whitelist, I can decode to jpg on the fly. Not sure how that works with accept-ranges though.

Although it might be more worth it in this case to just keep two copies. trade disk space for cpu cycles

yes, it all depends on storage vs cpu considerations

but this way the browser itself would have no polyfill JS code

on heavy traffic sites you'll certainly want to keep both and not convert on the fly all the time, but maybe only in a memdisk cache, for example

well in this case it would make sense to cache it

if you're gonna convert on the fly

no question

yes, mozjpeg + jxl could be a good transitional approach, save 20% in bandwidth for those who support it, save storage on the long tail of rarely requested images, no need to worry about consistency of quality or generation loss

You mean, source(png, whatever) -> cjpeg -> cjxl?

though of course jxl from pixels does give better compression than jxl limited to dct8x8

yes, or if you have jpegs already around

well if I already have jpegs, mozjpeg won't help, will it?

unless you mean jpegtran

yes, mozjpeg's jpegtran can still help a bit

or maybe you already used mozjpeg in the past 🙂

I use jpegtran a lot

though, I thought encoding to jpeg using mozjpeg rather than with libturbo-jpeg was basically a given

I actually swapped out my system libjpeg for mozjpeg even though they recommend against it since "your system libjpeg" is only for decoding, for my purposes and mozjpeg is just libjpeg-turbo on the decode side

yes, libjpeg-turbo is kind of silly to use as an encoder, its defaults are very fast but quite bad

in other news, has `libjxl` finally received a `make uninstall`

it bothers me when makefiles don't provide an `uninstall` with an `install` because it can cause issues if I decide to move the installation from `/usr/local` to a different prefix or if I just want to start tracking it with my system package manager

I have to go and manually clean up all the files installed

~~rm --no-preserve-root -rf /~~

maybe open an issue about it?

I don't actually know if it ever got one or not

if not I can file an issue

no mozjpeg no gimp plugin

i want just cjxl

``` Quality setting (is remapped to --distance). Range: -inf .. 100. ``` how is it remapped? is it a log scale? linear? etc.

`d = log2(101-Q)`? etc.

`d = 15 * (1 - 1/(101-Q))`?

from -500 to 0 to 7 modular

from 7 and up is vardct

d 15

that does not answer my question at all

from 0 to 7 q is modular

after is vardct

that does not answer my question at all

and repeating your answer will still not make it answer my question

ah the algebra it uses

i do not know

ask developers

dev of jxl

that's literally what I'm doing

by asking a question in <#794206170445119489>

If I specify `-Q` instead of `-d`, the docs say it converts the value of `Q` to a corresponding value of `d` but it doesn't say how exactly

as far as I'm aware, `-Q` is mostly there to be backwards compatible with people who know how jpeg quality settings work

i have simply blocked fab at this point lol

he appears to be one of those

unfortunately common in software spaces, the sort to just ramble about anything and everything regardless of what was actually asked

https://discord.com/channels/794206087879852103/803645746661425173/818396672081788958

Also `-q` and `-Q` ``` -q QUALITY, --quality=QUALITY Quality setting (is remapped to --distance). Range: -inf .. 100. 100 = mathematically lossless. Default for already-lossy input (JPEG/GIF). Positive quality values roughly match libjpeg quality. -Q luma_q[,chroma_q], --mquality=luma_q[,chroma_q] [modular encoding] lossy 'quality' (100=lossless, lower is more lossy)```

ah, it's almost piecewise linear

and yes I meant `q` not `Q`

> - cjxl -q 90 (-d 1): high fidelity, can be used on the web if fidelity matters more than usually, e.g. product images of a webshop selling clothes with subtle textile textures

normal cjpeg with quality 90, to me, is garbage

which means that if `-d 1` is "visually lossless" then it *has* to be better than cjpeg quality 90 which is very obviously not visually lossless

`q=90` jpegs will give you horribly obvious ringing

it is never claimed to be an exact match with cjpeg

it is just to give a similarity

yea, but I would never touch q=90 jpegs with a 10-foot pole unless they're photographs

cjpeg quality 90 in recent mozjpeg is at least 444

in libjpeg it always defaults to 420

I'm talking mozjpeg, yea

the problem here is that there's a lot of "visually lossless" png prefiltering going on that really is visually lossless, and I'm worried that someone will see "visually lossless" and won't realize that it simply does not work that way for synthetic images

photographs, sure

d1 is aiming to be visually lossless at a viewing distance of 1000 pixels

if you zoom in or get closer to the screen, everything that is not fully lossless at some point becomes visually lossy

for synthetic images it's probably safer to do fully lossless anyway to be sure, or something like d0.3 if you need to do lossy

results will also vary between encode speed settings, e.g. at speed 7 and up patches are used, which could help to avoid ringing at text, and at speeds 8-9 the encoder does butteraugli iterations to make sure the adaptive quantization is actually visually OK

with testing, I've found that `cjxl -d 1` is much better than `cjpeg -q 90` for synthetic imagery

which is the protest I'm making

`cjpeg -q 90` is not visually lossless by any means on any content

there are too many different definitions of visually lossless

that's the thing, but to me, an untrained eye looking at my monitor at at ordinary distance, `cjpeg q=90` is always very clearly different from the source

which is not the case for `cjxl -d 1`

maybe it's because it's more noticable to me? but I see this kind of crud and cringe

the fuzziness in the blue

I think we prefer to err on the side of looking better than expected rather than worse than expected

yea, that makes sense

this is from cjpeg q=90

I'm just pointing out that I think some other people might go "ew, `cjpeg q=90` sucks" and then think that it means `d=1` sucks as well, which is not the case

yeah colored details like that, even without 420, will get trouble in cjpeg because the luma and chroma quant tables don't match

comparing qualities between two formats is silly

they are different formats, they will work differently

I'm specifically discussing it since jon said "q=X roughly matches standard libjpeg"

that's the issue

many changes have been made

I mean it still says that in `--help`

the -q version of the encoder config was added because people expect that to be there

we are trying to popularize the -d way of thinking about it

so it's basically just for backwards compat and if you know that `-d 1` works then I should just use that and just simply not worry about it?

the thing is that jpeg will give you wildly different perceptual qualities at any q=X setting

while cjxl is more consistent

yea, I suppose. I already like the `-d` since it roughly corresponds to the same concept in video encoding

Moreover, `cjpeg -q` is not a quality indicator because none of the visual metrics for a particular image are used to determine quality, it is just a quantizer

for photos, cjpeg q90 can be just fine and correspond to d1

for nonphoto, cjpeg q90 can be pretty lossy and be more like d3

Yea, I prefer the `-d` anyway. For example, x264 provides `--crf` which is basically like the way we treat `-d` but on a different scale

`--crf 0` is mathematically lossless\* but `--crf X` for positive X is a quality setting, higher number is lower quality

the video codecs don't really have perceptual targets though, it's just the quantizer setting

https://github.com/libjxl/libjxl/pull/56 this might be interesting for you 😄 don't rely too much on it though! (I believe in my own website I ended up doing the simpler trick described in prepare_folder.sh)

They absolutely do, if written well

`--crf` is a perceptual quality setting in x264, which is based on the qcomp curve

well x264 does do perceptual optimization, but is there any guarantee that say --crf 20 will give a similar result on any content?

that's the design

--crf is content-aware

You can use CQP (constant quantization parameter) in x264, which fixes a particular quanitzer, but using CRF dynamically chooses the quantize parameter based on a psychovisual model (allowing it to things like quanitze darker areas less)

i don't know enough about x264 and how fancy its visual modeling is, maybe you're right

this is affected by the qcomp curve. `qcomp` is a setting (defaulting to 0.6) which affects how `crf` behaves

I know that in avif, the perceptual quality I get from a given q setting is pretty image dependent

Even `--crf` can be noticeably different in metrics or visually for different content, something similar for video is in the form of `--target-quality` in a third-party utility Av1an <https://github.com/master-of-zen/Av1an>

the issue I've found is that nothing has managed to replicate x264's model very well

x265 has not

crf only makes promises at the exact same settings though

different content encoded with identical settings should produce the same quality at the same crf

but even minor setting changes can alter it

`qcomp = 1.0` makes `crf` behave like `cqp` even if the bits are unnecessary in that sense, the way crf works, it starts at a baseline of constant qp and then increases qp if the extra bits are unnecessary, according to its model at `qcomp=1.0` it considers them to be always necessary and `qcomp=0.0` it considers them to be *never* necessary (essentially granting almost CBR)

Yep, x264 had good devs and was hand-tuned for years for this purpose, but still, it's not the same visual quality for all content

although that's mostly because you tend to use different settings

crf makes no promise to work across presets and settings

you can also tune it to psnr or ssim which optimizes against those metrics but you usually do not what to do that I don't think tune vmaf was ever added

in theory `-d` should do a good job at getting good, consistent quality - the corresponding `-q 90` parameter was chosen because usually on photographic content mozjpeg does a good enough job at doing the same with that quality (on average), but it was never intended to be a "in all cases you're getting a similar results"

ye, that's what it sounds like, but that's more a problem with mozjpeg -q 90 not being consistent

than cjxl not being consistent

basically any lossy image codec is not consistent

I don't know how much tuning for vmaf is a good idea, as a metric it has a few... issues... like being able to return >100, not returning the same thing for comparing two identical images, and increasing scores by just pre-sharpening the input file before compression...

something I am wondering is what the best default is for true lossless jxl

does it actually use a separate mode (like, say, webp) or is it just setting the Q to 0

separate mode

*very* separate mode

it's a separate mode (though that mode is also used in parts of lossy coding)

ah, so a lossy jxl could, say, take an allblack section and make it lossless on a block-by-block basis?

among other things, it's a fair bit slower, which is something we should work on

yea, that's the big thing I've noticed, is that cjxl -d 0 is very slow

no, that cannot (easily) be done - but you could put the quantization so low that it's basically equivalent

Are patches where it decides to use a different encoding setting/mode for a specific part of the image?

we can mix lossy and lossless using patches or multiple layers

not necessarily *just* that

but every frame is either modular mode or vardct mode

What is a frame in the context of JXL? Is that animation frames?

Yes, but I mean more about consistent quality indicators, such as metrics can provide this, like for example VMAF 95 is always constant good enough quality, no matter the content, settings and other things (although VMAF is also not perfect and it can be cheated, but it is still consistent than something more simple)

vardct still does adaptive quantization so you can effectively have different qualities in different regions

for archival is there anything to do other than `cjxl -d 0 -e 9 input.png output.jxl`

like beyond that would you recommend any settings beyond the default?

I know for ffv1 video archival you need to use `-c:v ffv1 -level:v 3 -g:v 1 -slicecrc:v 1 -coder:v range_tab` in the ffmpeg CLI cause the defaults are not good

for example it doesn't default to `-g 1`

if you really want best lossless and time is no concern, `-d 0 -e 9 -E 3 -I 1` and then choosing best of `-g {0,1,2,3}` and also try `-d 0 -e 9 -I 0 -P 0 -g 3 --patches 0` in case it's one of those where png is hard to beat

Also, what about the previously mentioned idea for that experiment to replace the background is not black, but something average, closer to the dominant or real background color, perhaps then these border artifacts will be unnoticeable?

if you're OK with "slightly lossy, but I challenge you to notice it", I suggest something like `cjxl -d 0.1` or `cjxl -d 0.1 --gaborish=0` (the first one will make smaller files, but has the disadvantage of approximating an inverse convolution, which is not done perfectly - so you'll occasionally be able to see one or two pixels that are different)

I tried something like that but it was bad for compression - I think it's probably better not to use two full frames but to just use more patches (also for non-repeated nonphoto parts)

Will the individual patches also compress noticeably worse than one large patch, or is the difference not as significant?

The patches are all thrown together in a big sprite sheet anyway

We should have a debug option to see the patch frame, it should be fun to see

(well except that we usually encode white as 0 there and black as something negative, so that doesn't quite work in png)

Also `--palette=0` / `--palette=10000` because for now, palette selection is not always accurate And as I mentioned before `-d 0 -e 9 -I 0 -P 0 -g 3 --patches 0` is rarely more effective than any other option without `-I 0`

`-E` and `-I` are not documented in `cjxl --help --verbose`

`--help -v -v`

oh, thanks

also what does `--gaborish` do?

``` --gaborish=0|1 force disable/enable gaborish ```

I don't know what that means

Some kind of Loop filters

btw, is the default single-thread encoding?

unless I tell it otherwise

or is the default cpucount

default count but at slower speed settings, it doesn’t give that much of a speedup

so I need to use `--num_threads=0` to disable threading?

yes

(I assume it'll produce an identical file)

also yes

Yes, unlike avifenc

In this case if I'm batch converting images I'd prefer to disable multithreading and just let each one run in a separate process

since I trust my operating system to handle that better than I trust cjxl

since lots and lots and lots of people care about optimizing the OS's ability to handle that

Sure, makes sense

It's not even just the operating system, not everything can be fully threaded when encoding a single image, so if there are a lot of images, it is usually always more efficient to encode one image per thread (except for memory consumption)

entropy encoding is a biggie

yup, especially in lossless mode

in lossy things scale well enough... lossless, nah

On Windows there are also problems with multithreading even for lossy, especially at slower speeds (although some older builds worked better)

how so?

I don't know, but on very old builds (maybe before FDIS) threads were fully loaded more often, then after some changes it became worse, at least on Windows on the same content and speeds (although I did not make special comparisons, but it was felt), also this applies to lossless for fast speeds, maybe there is some difference in Windows threading

I have a mini-display on my keyboard that monitors core loads, CPU and other things and it's usually always noticeable to me

mhhh... encoder or decoder?

for lossless multithreading we definitely changed a lot in the encoder and it is very likely slower

encoder