JPEG XL

in order to actually decide if alpha channel is not required it will be necessary to implement `j40_info_from_image`

https://tenor.com/view/sans-fight-gif-26158536

actually I wanted to enable ubsan, asan and msan altogether but it is impossible afaik

so, just one sans

san?

one of sans, or san

https://stackoverflow.com/questions/62109255/what-is-a-good-way-to-apply-multiple-sanitizers-in-cmake-with-gcc hmmm

I toyed with ninja as a replacement of make in Windows (I never had a good time with make in Windows), as ninja can be distributed as a single executable. unfortunately it requires a separate configure, and every attempt to make it self-configurable failed by now.

my idea was to have a bootstrapping `build.ninja` which will rewrite itself after configure. this seemed to work, but I realized that this will break after `ninja -t clean`

maybe the solution is to ditch make and force everyone to use a custom script (say, `./build` or `build.cmd`) that internally configures if needed and calls make or ninja

not really comfortable though

or using ninja *only* in Windows and make elsewhere might be a solution, but then I'd expect non-Windows people will try to run ninja anyway

Yea, and I like it a lot more than CMake.

one of my projects uses Meson (https://github.com/sboukortt/intersect-lv2/blob/master/meson.build) and tup (https://github.com/sboukortt/intersect-lv2/blob/master/Tupfile)

tup = https://gittup.org/tup/

cmake and meson are meta-build systems (i.e. doesn't do build themselves but generates a metadata for actual build systems) and I think it is too much for small projects like J40

tup has a great design that influenced ninja later

why is gnu make bad on windows

if you do it with mingw/msys2, it works fine in my experience

iirc gnu make on windows didn't work well with windows `$SHELL` (aka cmd.exe)

GNU make requires a `*nix` shell with all of the included utilities, the Windows command prompt does not provide that environment. MinGW/MSYS2 fixes that by bundling its own `*nix` shell environment and compiler toolchain (gcc, make, etc) that outputs native Windows programs.

WSL is an actual linux env it's like apples vs oranges

FYI: future J40 discussion will be placed in https://discord.com/channels/794206087879852103/1020056709831594005

configure higher inactivity timeout if u still haven't

oh thank you for the tip, is 1 week the maximum?

seems so...

I think that is just after inactivity though, so someone posting will reset it.

https://www.reddit.com/r/linux/comments/xfrf45/what_are_the_open_formats_i_can_use_to_support/

no jxl 😦

not sure if it was edited since then, but "JPEG-XL" is (now) listed

Yeah user blueswordm added it.

the paywalled spec?

yeah jpeg xl is standardized through ISO and they seem to have a paywall for anyone that wants to read a spec

What about Flif?

what about it?

the flif 'spec' is here: https://flif.info/spec.html

It's quite incomplete and not very rigorous, but then again FLIF was never really meant to be a 'serious' format in the sense of really getting adopted. To me it was more of a fun exercise and a research project than anything else — at least with hindsight; maybe at some point back in the time, I was taking it a bit more seriously than I should have.

Wait you're the author????

Anyways I was just saying I think flif isn't paywalled and has compression comparable to jpegxl

https://youtu.be/jnxqHcObNK4

Mad respect if you are the author, I just joined this discord cause i saw this youtube video on wavelets. and thought parts of JXL were related or inherited from flif and maybe could find more documentation

flif isn't paywalled since it's not officially standardized either 🙂

yes, I worked on both flif and jxl and part of jxl is based on ideas from flif

flif was made for lossless only though, most of lossy jxl is based on Pik

(though in jxl, lossy and lossless are not completely separate modes, e.g. all the lossy control fields and also the DC image are encoded with lossless jxl, aka modular mode — but the main lossy data (AC coefficients) is encoded in a different way)

really; was impressed with that artifactlesss demo though

keeping generation loss as low as possible is imo crucial for digital image preservation in the long term — otherwise we'll end up with photos that 'fade away' over time

the lossless transcoding of jpeg into jxl helps a lot in that respect

it's quite interesting that both the pik team and me had that same insight — we both submitted a proposal to the JPEG XL call for proposals that included a lossless jpeg transcoding option (brunsli in the case of the pik team, fuif having similar functionality in my case), even though that wasn't part of the original requirements of the JPEG XL project as it was originally envisioned by the JPEG committee.

now it almost feels strange to me that of all the "next generation" codecs that were supposed to replace jpeg — and there are quite a few of those — none of them had the idea to be 'backwards compatible' with jpeg in order to allow lossless jpeg transcoding, until jxl.

the original jpg is based on DCT right

yes

and what was flif based on again?

and all image and video codecs kind of still are based on DCT, except j2k which is based on DWT

flif doesn't do lossy transforms so it isn't really based on any transform

is it it's own algo or is it based on something?

it mostly does entropy coding in a much more complicated, image-specific, and better way than what was done before — e.g. PNG basically just uses general-purpose compression on image data, with only some basic filtering

it does have some transforms like a generalized palette (which is also in jxl) and YCoCg (which is also in jxl)

thank you so much <@794205442175402004>

the main difference between flif and fuif/jxl is that flif has this funky interlacing scheme where pixels are traversed in an Adam7-like pattern which is very bad for memory locality and thus decode speed, but it allows one very nice thing: you can do prediction from almost all directions! The final half of the data are basically pixels that can be predicted from NW, N, NE, W, SW, S, SE — so 7 of the 8 neighboring pixels. That means they can be predicted and context modeled very well.

Have you seen the nile language by bret victor and dan amelang?

http://www.vpri.org/pdf/tr2010003_PEG.pdf

I believe that is the backend for nile, I think I found a scheme r5rs or r7rs implemenation for the ometa backend but I lost the link

http://tinlizzie.org/dbjr/high_contrast.html

there it is compiled to javasecript but I believe how they compiled it wasn't very formalized

I believe bret victor did do a talk how they were making it very parallel but I lost that link as well

I don't see how that is related to image compression, are you talking about parallelization?

but the nile code looks beautiful, considering how much shorter they made the code 400 lines compared 400,000 of the cairo text rendering library chrome or webkit is using

well the nile code could be used to write a dct for compressing images. edit: *nile language

Rendering vector graphics is kind of something different, but I do hope that one day we can create a format that includes both vector and raster graphics (and text).

JXL splines are a start for that, but they're not expressive enough for all vector stuff

I don't know about format I think SVG and html have all those bases covered

I think you should have linked to https://raw.githubusercontent.com/wiki/damelang/nile/socal.pdf , I was a bit confused what it exactly was

oh sorry

I think jxl has the potential to bridge the gap between authoring formats and delivery formats, by supporting lossless and layers etc

It doesn't bridge the gap between raster and vector though

I wouldn't want to I think you can specify raster from svg

and have it embed the raster file in it.

Svg can do everything but it's very bloated

Pdf can too, but it's also very bloated

yeah I think there's some huge html compression that is bidirectional though so you can get back to the original svg without any errors

stream formalism is great, but technically speaking this can be actually done without a special language, isn't it? any language with inlined iterator seems enough to implement that formalism.

I mean bloated feature-wise

Implementing full svg requires implementing a browser, basically

Same with pdf

<@268284145820631040> I'm not sure I was just trying to get "nile"'s back end "ometa" working and failed

stream or pipeline formalism is kinda natural for PL and compiler researchers, pretty much everything is linear

(until it no longer is, especially with incremental compilation and IDE support)

so I guess it's natural that PL researchers may see everything else similarly

FLIF compression can be roughly experienced in JPEG XL as 'modular' -- with most things improved, but also some weakened

to put shortly, FLIF/FUIF is about 50 % more bytes than the VarDCT mode of JPEG XL, so it isn't exactly competitive for photographs

In JPEG XL we extended FLIF/FUIF with delta palettization (WebP lossless inspiration), static context trees instead of adaptive for faster decoding (for speed), with Alexander Ratushnyak's gradient predictor (gralic/qlic inspiration possibly), and with LZ77 with 2d short codes (WebP lossless inspiration)

I consider JPEG XL's modular fully supercedes FLIF, FUIF and WebP lossless and represents the best pixel-lossless practical format today

but VarDCT is still more powerful for lossy photographs

VarDCT's legacy is in the butteraugli/guetzli/brunsli/pik trajectory, possibly some ideas from webp lossless and brotli, too

and also the formats are 'happily married' as VarDCT uses modular for DC and control fields

webp lossless is a good format, too, and more mature

I believe it is possible to model webp lossless compression as a jpeg xl stream, too, so in the end there shouldn't be big wins ever for webp lossless

I tried to guide our side of lossless work to be more towards better compression of lossless photographs -- a domain where webp lossless is not so great

I don't know if I was successful in that in the end, I feel we ended up building a pretty generic solution

I think that the Ratushnyak's predictor should be quite strong for photographs

it is — modular e3 is using just that predictor with a simple fixed ctx model and it produces pretty dense results on photographic images

For compressing text, which is mostly repetitive patterns, jxl has two main methods: patches and lz77 with 2d distance codes. The limitation of lz77 is that groups are encoded independently, so you can't make references outside each (by default) 256x256 group. WebP has no groups; just like PNG it's row-based, not tiled, which is bad for parallel decode but good for horizontally repetitive patterns like text. Another thing is that we never really figured out how to effectively combine MA tree learning with lz77, so the current encoder basically does one or the other but not both — which is obviously suboptimal. You can try if `cjxl -m 1 -I 0 -P 0 -e 9 -g 3 --patches=0` produces a better result: that sets the group size to 1024x1024 (to allow more matching to happen), disables MA tree learning so the encoder will go all the way for lz77, and disables prediction and patches since those can do more harm than good when lz77 matching is the main tactic.

Patches don't have a group boundary limitation: they're encoded in a separate invisible frame and can then be referenced anywhere. The main problem there is that it's not easy to really detect all repeating patterns in an image in a way that is still reasonably fast. We currently have some heuristics that tend to detect quite a lot of text in screenshots, but the heuristics will certainly miss some opportunities. Better patch heuristics could lead to substantial improvements for images with lots of text — or other repetitive patterns like icons or avatars.

Thanks.

Lossy modular with no MA tree learning is a combination that isn't implemented. But we should do something else than just fail with a cryptic error. Could you open an issue?

TIL: I learned that qcms has been completely translated to Rust months ago https://github.com/FirefoxGraphics/qcms/

Interesting. Because some of the arguments against being colour-correct were about performance…

It's just a normal JPEG at the end

It does all the bracketing and tone mapping and writes out a SDR result

It's basically capturing HDR to produce a better SDR image

Though there also exists something like "HDR JPEG" which is based on JPEG XT. It's a tone mapped SDR jpeg that also contains extra info to reconstruct a HDR image.

to be fair, there's a benefit to mapping HDR to SDR, you theoretically get more details in both light and dark spots.

yes, though tone mapping is also an artistic choice, so if it's done by an algorithm and then set in stone, that's a bit of a pity compared to getting a real HDR image where you can still adjust those artistic choices

(not to mention that you may also want to display the image in actual HDR instead of tone-mapped SDR)

github.com/libjxl/libjxl is more up-to-date

SIGILL is how asserts fail in libjxl that said that's a *very* old version

Is there any way to simulate Wide Gamut or HDR on regular screen on Windows?.. Like, in this simulation SDR images would lack contrast, and normal gamut images would be looking gray-ish, while HDR and Wide-gamut would look normal. Perhaps a virtual monitor on virtual machine?

while it is (unfortunately) not possible to extend the gamut and dynamic range of the screen, one possibility is to take an existing image, make it even more narrow-gamut / low-dynamic-range, and then compare that with its normal version to illustrate the “direction” of the improvement

e.g. normal image:

artificially lower dynamic range:

flipping between the two gives an idea of the sort of improvement that HDR can bring

> narrow-gamut Yes, that's the idea > image I'm not talking about image file, but about debugging application.

ah, debugging is indeed another matter

I have a suspicion that finding a cheap HDR monitor might be quite an easier solution than managing the various hacks to simulate one

patches are very powerful... I tried compressing screenshots with lots of text using lossy modular and high butteraugli distance... and it's clear how stuff like text in titlebars and stuff become messy but like a wikipedia article stays quite good even at very high butteraugli distances

thanks to <@179701849576833024>'s clever patch detection heuristics — though of course there's always still room for improvement 🙂

when did these get implemented?

these heuristics

quite a while ago

they work reasonably well for text on a solid background

I wonder how well they work for synthetic images, like anime-screenshots

are they only used for lossless and/or modular, or are they also used for VarDCT?

Also for vardct

But the current heuristic requires at least two repetitions per patch, which happens for text but not for anime

Is there any benefit to near-repetitions? like say patch and then encode difference on another layer with blend add

In lossy mode it does that, but the threshold for being considered close enough is quite strict

The encoder uses kAdd blending for the patches and subtracts them, so no need for another layer, the residuals just remain on the main layer

The patch itself gets encoded in modular mode, the residuals with vardct if that's the main layer mode

So if the residuals are small, they might get quantized away, depending on the quality setting

Hello all, I'm learning about JPEG XL for participate on the next Inercia Demoparty ! Where can I learn more about the properties and predictors ?

Scroll up in <#824000991891554375> 🙂

Also the help screen of https://jxl-art.surma.technology/

oh thanks

many things in JPEG XL that is not part of the jxl-art tool, too

predictors here: https://github.com/libjxl/libjxl/blob/main/lib/jxl/modular/encoding/context_predict.h#L199

> I've said it before and I'll say it once more: JPEG-XL offers reversible recompression of JPEG, not lossless. If it were lossless, it would decode bit-identical to what the libjpeg decoder outputs, but this is not the case.

what

this person is confused about different jpeg decoders producing different results and somehow thinks libjpeg-turbo (with default options, I suppose) is the only correct way to decode a jpeg

i.e. this person is comparing original image -> jpeg -> rendered image vs. original image -> jpeg -> jxl -> rendered image

the only thing jxl guarantees is that original image -> jpeg -> jxl -> jpeg is identical

different jpeg implementations can result in different rendered image, even though the difference is imperceptible and probably +/- 1

Once the image is a JPEG, there's no exactly right way to decode it.

Another common case is PNG with alpha semi-transparency. Different programs may produce slightly different results because the alpha blending is not always done exactly in the same way.

One program may even render the same partially transparent image in two different formats (for example PNG versus lossless WebP) slightly differently.

Ugh, must be something wrong with it indeed

Looks like the bot was upgraded and somehow lost its reddit feeds, fixed it

That discussion was getting silly, I hope my clarification will help: https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1354717-google-chrome-is-already-preparing-to-deprecate-jpeg-xl?p=1354918#post1354918

google don't make you decidd

i was watching a song in vp9 4k on ytm 5,8 mbps connection

it interrupted the song at 2:10

with their ads

two ads non skippable

then they switched to 144p in the video i was watching

then immediately 4k

also google takeout include nothing of yours youtube music data neither your liked songs

> Is there a work-around via plugins? I wonder how fast a web assembly-written JPEG-XL decoder would be. Might be time to create a standard Media Codec API so formats can be added via browser extensions as they are getting increasingly stingy on adding new ones and political gatekeepers for the browsers that can add them. I would also suggest browsers add some type of database of formats so that when they encounter these unknown formats they can recommend the verified extension that supports it - similar to what they did with Flash years ago.

what's happening here. it does not encode.

Something wrong with cjxl from opensuse. it does not encode any files.

No. did not test nightly yet. going to download nightly.

Should I try asking jxl support in this app? They have avif already. https://github.com/SimpleMobileTools/Simple-Gallery/issues/1143

It's an android gallery application

Just installed that app. Avif doesn't work on Android 11 as expected. 😦

I'm going to learn android development and implement jxl 😭

jxl in a gallery would be amazing since i could convert all my old jpegs losslessly

but it would probably be worse if the rest of the system didn't support jxl

now, if the gallery could also transparently decode jxl to jpeg and share the jpeg version to other apps... 👀

wow jpeg XL now in firefox 108

nightly?

yes

that's great news -- ah, nightly, it has been there for a while

I noticed that the highest ever chrome blink bug has about 2900 stars

if we could get 3000 stars on the JPEG XL bug, it would be the most community interest ever on Chrome Blink subsystem

with the rate that it's growing I really don't see it hitting that number sadly

it would possibly reduce the impact of the '- There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL' argumentation in comment 84 here: https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c84

we would need to ask colleagues to ask colleagues to consider it

top 10 would be about 1000 stars

I think we got ~150 stars yesterday -- of course it was with quite a bit of media coverage

they list four reasons in comment 84

1. the flag is experimental (not really a reason for removal)

2. not enough interest (we can improve here with stars -- in practice bugs above 32 stars are statistically likely to make it, and usually 100+ stars show interest, but we can make this more clear)

3. JPEG XL is incremental -- I think they measure with PSNR and SSIM and similar, they don't have a process with evaluation by human viewing

4. Maintenance burden (((seems inflated, so far JPEG XL code has produced quite a bit of free work in Chrome when we have been solving systemic HDR and colorspace issues in Chrome for free, and we solved them for AVIF and others, too -- if we look at mature externally maintained codecs like JPEG, PNG and GIF, the maintenance work is not a substantial effort)))

if we can drop the 2nd concern in a way that it becomes somewhat ridiculous -- like having it the highest starred bug ever -- we can focus more on arguing on 3rd and 4th topic

yeah, it would be great if stars and comments come from the industry

of course it can be that there are not 3000 image compression experts in the world 🙂

it is still our moment to express support -- staying silent doesn't seem responsible either and starring is not a huge attack on their system 😛

Chrome people look at the stars and they have observed that bugs above 32 stars get fixed, their tools allow sorting by stars

so they will see it in prioritization and they will keep scratching their heads with a higher star count -- at least until it is closed

So when improvements in red artifacts retention

if they choose not to fix the highest (or say top 10 ever) starred bug, it will likely become a legend that they will talk about when talking about prioritization based on stars in general -- that can help in reviving it later

Does small improvements in ssimulacra2 can help It

For low fidelity jpg images?

chrome/aom does not use simulacra2, butteraugli or dssim. they use psnr, ssim, ms-ssim, and vmaf

Continue

they don't have plans or capacity to take in new metrics

What's next

I think three things:

For Stefania scordio image can it improve red artifacts

1. port enough stuff from JPEG XL to old school JPEG so that it becomes slightly better than AVIF -- to show how good the stuff is and to avoid the internet to be spoiled by oversmooth photography

Why some images get demoised in the reds by JPEG XL

I know every image is different

You can't do every image perfect

2. wasm implementations (both HDR canvas and service worker thread versions)

3. build more momentum: more awareness, build larger ecosystem, prepare for HW encoding, build a MJPEG XL possibly on libjxl-tiny, more visibility to the quality differences

reds and magentas are difficult

they can vary on different monitors

making it really complicated

matching the intensity of reds with the intensity of grays is important psychovisually, but poorly calibrated equipment make it challenging

try to view the image with different equipment and see if that is the issue here

compress with JPEG1 and AVIF to see if JPEG XL does better or worse at the same bit rate

if worse, file a bug on libjxl

AVif has old encoder

The libavif appveyor does not have 3.5.0-349

> 2. not enough interest I think 3000 stars is unrealistic, but there is very active discussion in the news, blogs and various platforms, and also interest from big players such as Facebook, Instagram, WhatsApp (and some other messengers), some CDNs, Shopify, Adobe, etc. and that is already a big internet traffic and huge number of users of these products > 3. JPEG XL is incremental -- I think they measure with PSNR and SSIM and similar or the comparison was done mostly for low bpp, since there is a prevailing opinion that the web only needs the lowest bpp at very high compression > 4. Maintenance burden however, it is a pity that there is no full time team just for Jpeg XL, then bugs and vulnerabilities would be found and fixed faster and there would be more quality improvements in the meantime and also the problem that could arise is that Google would ask the people who worked on Jpeg XL to drop work on it completely (although there is still free time, but maybe that wouldn't be welcome either)

we have a full time team just for JPEG XL

it is financed outside of Chrome org

we can make a commitment to Chrome on it

I started working on a wasm polyfill for browsers now, may also work on node but there are plenty of node tools already so it's not my priority. How much would you actually be able to add to JPEG? I would think they wouldn't want a lot of breaking changes at this point.

I'd recommend to start such a wasm polyfill together with Moritz, we have invested a bit into this and have quite clear ideas on how to proceed -- I'd love to maintain control over this since we were bitten by a volunteer effort in Brotli+nginx, where the volunteer became unresponsive for three years 😛

it could be a libjxl project from my point of view, then we would have enough control over it

I would feel a bit uncomfortable promoting a fully external solution for this as the only solution

we are able to improve high end (q95) JPEGs by 8 % and q90 by 7 % or so in decoding only

in a backward compatible way, and conforming to the JPEG1 spec

decoding improvements are 25 % or so in q85 and above, but sharply declining for lower quality

That's fine, didn't know if you wanted it to be under libjxl project anyway. <@795684063032901642> if you want to reach out, would love to go over that.

the main challenge in wasm is the HDR

there are two ways on how to get it done

HDR canvas

48-bit/64-bit PNG conversion

HDR canvas is just emerging, and it is now behind a flag in Chrome -- some people are thinking that the first version of the spec will be ready this winter

the canvas solution gives more opportunities for progressive rendering while the PNG solution requires less new features from the browser

it does require that 16-bit per channel PNGs can be HDR rendered

It looks like it's available in all but Firefox, or is this not what you are referring? https://caniuse.com/?search=canvas%20colorspace

also, is there any way to further improve butteraugli where this metric is behind ssimulacra2?

Overall the 7+25 % gives a 30 % improvement. This makes JPEG1 more powerful than AVIF in the q90+, possibly q85+ range

this is possible -- but we don't know for sure, we don't have experience on this -- but it seems to me that image quality is not the big issue right now

metrics and compression interact in weird ways, and butteraugli has some adjustments that make it less good for metrics and better for controlling image compression

That's awesome that you can get that much improvement out of the current format.

yes, it feels a bit bizarre that it is possible, but we have already published those tools in libjxl

we are refining and packaging them now and considering to wrap them in a libjpeg-turbo compatible API

if we could replace libjpeg/libjpeg-turbo then it would be faster to deploy

those APIs are relatively leaky and have loads of features, so it needs some work that Zoltan is doing now

if we can use ICCv4, we can even use the XYB colorspace there

but it makes JPEGs look rather funny when there is no ICCv4 support or the support is failing in some way

We use chroma subsampling only in B-channel, and have X and Y without subsampling -- that gives some more speed without the need to compromise quality

Like the image that turns green on Firefox 😆

It is bit of a coin toss, but I'd say we are three months away from it

ah, decode only three months away

we will very likely stage the launch so that decode is in the first phase and encode in the second

I don't understand this question

the newly encoded JPEGs are fully compatible -- we can do without ICC, with ICCv2, with ICCv4/XYB

XYB gives likely an additional 5-10 % or so, but the savings are in the 20+ % range without it, too

if we replicate the libjpeg API, then linux distribution maintainers can choose our libjpegli instead of another library, and all apps get it instantly

Oh, you mean is the API the same as libjpeg?

That was just answered 😆

Regardless, even if it wasn't it would likely be rather trivial to write a middle-man package to translate just like the pulse -> pipewire packages do.

we wouldn't be able to generate ICCv4 by default from the same API, I think, that would likely be observed as a violation of the API contract

so, some additional steps are necessary

getting all details right is going to be quite some effort

of course it would be much easier to just launch JPEG XL and have all the good stuff in a simpler package 🙂

but not all forces of the universe agree with that plan

JPEG1 has its strengths, too, particularly the speed and memory bandwidth use of decoding are nice

and the more we compress in encoding, the faster the decoding

True, but also 30 years old. Compression has evolved since then.

yes, like being able to recompress it 20-24 % is indicative that not all things went right 🙂

also what were they thinking not to add adaptive quantization -- it was a huge mistake -- even just one bit per MTU (with RLE or similar) to double every AC coefficient would make the format ~10 % better

I'm actually surprised there is not a polyfill yet. A few libraries get about 90% there but don't go the last step. I considered using vips, but that library supports a bunch of different formats and would just bloat the code. I think it's meant for for cli tools. You want a polyfill to be as small and specific as possible so it downloads and runs fast. Just having the polyfill will incur overhead so you want to minimize it as much as possible.

No add anymore

An interest in encoder such as cylbius new aom lavish commit

Isn't interesting enough to detract Google

Google is a big company

Google knows what's its doung

I've actually stopped receiving emails when somebody comments on the Chrome issue, not sure why

Stopped sending them after it hit 100 comments

Yeah, I got an email for comment 99, then 151 next, and no others

I'm still getting the emails.

There could be a limit on how many mails it sends per day or something

Yeah, I think it only sends one per day now.

We have a working wasm decoder from this summer, see https://github.com/eustas/jxl-demo for the code and https://eustas.github.io/jxl-demo/ to see it live. Steps that could be improved are - ease-of-use, perhaps using a service worker, - wasm binary size, currently 216k (brotli) compressed with some opportunity for improvements

FWIW, looking at the contents of `jxl_emcc.wasm`, I think Brotli was compiled for Wasm without `-DBROTLI_EXTERNAL_DICTIONARY_DATA` - see: https://github.com/emscripten-core/emscripten/issues/9960 That would probably save some kilobytes.

yes, about 75 or so, a good first step

but presumably the wasm decoder doesn't *actually* need a brotli decoder to just produce pixels

Yes, no brotli needed to get pixels, only to do jpeg bitstream reconstruction and compressed metadata boxes

Ah, interesting. If it's not done already (I could not find the build script), `-DJPEGXL_ENABLE_TRANSCODE_JPEG=0 -DJXL_DEBUG_ON_ABORT=0` could also help to reduce binary size.

If there is some way to break out various features that might not be needed with every image, that would make a smaller base file then could dynamically include the other libraries as necessary.

If you are using Firefox, service workers don't currently work in private tabs.

Just a cursory glance it looks like there are some placeholders which might not work and they don't appear to be using an actual service worker. That is what I will be looking into tomorrow. As far as Firefox's private tab service worker, I will probably just display an error message for now. Getting `img` and css `background-image` working without a service worker is a tricky proposition, will look into that later. Firefox has a bug out for it but no idea when it will be fixed.

Wasm ecosystem is a bit immature with support and particularly HDR support, but creating strong use cases like JPEG XL will also help to close those gaps faster

is that compared to mozjpeg? I would assume so but want to be sure.

Currently, browsers only support the p3 color space (https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement/getContext#colorspace) but there is a proposal to add rec (https://github.com/w3c/ColorWeb-CG/blob/master/hdr_html_canvas_element.md - no idea how long before they implement it). However, Firefox is behind and is still working on any HDR support. Only Safari supports it in CSS so far: https://caniuse.com/?search=display-p3

None of that has specifically to do with wasm though, but if the browsers don't support displaying a wider gamut, it won't matter much if wasm outputs in HDR.

Pretty disappointing but understandable.

Indeed, it's a bit disappointing. Note that libjxl itself is still fuzzed, see e.g.: <https://github.com/google/oss-fuzz/tree/master/projects/libjxl> (and I vaguely remembered that it is/was fuzzed internally by Google as well) So, most fuzzer bugs would probably have already been caught by `djxl_fuzzer` and others (libvips' fuzzer only tested JXL decode). Besides the support overhead, it also prevented new timeouts and OOMs from being found in other dependencies of libvips, since these type of fuzzer bugs are only reported once per fuzz target. <https://google.github.io/oss-fuzz/faq/#how-do-you-handle-timeouts-and-ooms> (I reported these in <#848189884614705192> and verified that it's also reproducible with `djxl_fuzzer`)

so this is the initial implementation of a Jpeg decoder with quality improvements? https://github.com/libjxl/libjxl/pull/1858

i think, what if also add Jpeg transcoding together with the new decoder? but the bad thing is that full Jpeg XL would lose one of useful features and also chances to fully support

yes

```I think JPEG XL's ability to be both non-Web editing format and Web format is actually working against it here, because the Web platform doesn't want non-Web features. Browsers haven't even implemented AVIF as specced, only a bare minimum subset. JPEG XL doesn't have a minimal subset``` https://news.ycombinator.com/item?id=33454038

Code complexity and vulnerabilities are a serious thing, but I wonder what jxl features are completely unneeded for the web?

High quality photo viewing, lossless, HDR, higher resolution (not even mentioning mostly web-specific features)?

There's a lot of use of highly compressed images on the web, but are all the other things really that useless?

I agree that supporting something bloated, with very different purposes like PDF or PSD is bad, but JXL doesn't have anything really useless for a web platform

Cmyk is useless for the web, but we don't allow that in Level 5 (which is what is intended for browsers)

Multispectral imagery (like satellite images with 12 channels and stuff like that) is useless for the web, but we also don't allow that in Level 5

Everything else I think could actually be useful for the web, e.g. layers can also be a good idea just for compression

Are the levels and their features listed somewhere, or is it in the spec?

It's in the spec, in 2nd edition

But even Cmyk is also present in Jpeg and this is rather a compatibility issue

speaking of which, is it possible to cite the 2nd edition draft posted in <#1021189485960114198> or is that the sort of thing that for legal reasons best be left until it's published

Best left until published, I think

I am not supposed to be sharing drafts, but I do it anyway because it is obviously the best way to improve them. But it would be wise not to draw ISO's attention to it.

Lossless is needed because PNG supports it.

Lossless for some images just compresses better than lossy

lossless is also necessary for the web for other purposes like small icons

remember you can losslessly recompress gif animations with jpegxl since it supports paletted color

I guess the difference there is that while they have PDF support in the browser, it isn't really part of the web platform.

2 and a half years have passed, the check problem, there are no more problems

even at low quality

q90 already, apparently, too much

it 2 times less than on tests 2 years ago, so the problem is definitely solved

the problems with the color's blocks are also completely solved

hmmmmm, why saving a white blank 800x600 list gives 457 bytes, at speeds 1-3, and at speeds 4-9 gives more than 520 bytes

I said that about varDCT. But there is also an anomaly on Modular size at a speed of 3

varDCT q0 e7 give 597 byte but q99 e2 give 492 byte

each effort level and modular vs. vardct will use different sets of heuristics (cause you can't evaluate all of them for speedy encoding) so that's not that strange

I said only about varDCT

I thought you were comparing modular efforts 1--3 vs. 4--9 and (separately) vardct q0 e7 vs. q99 e2?

both cases can be explained in the same way

stop talking about modular

I have even more questions when I saw that the size decreases with increasing quality

why and how it works

in modular mode, EVERYTHING is LOGICAL, the slow the speed, the more it compresses, except for parameter 3. But VarDCT has some kind of abnormal size i

not even a general-purpose compression algorithm is guaranteed to work in that way, contrary to what you want to believe

is that the answer? what,

I think you are holding an incorrect belief about compression levels

so if you are using that belief to judge cjxl or anything else, of course you will be disappointed

pyramid

in reality your "belief" is a (good) guideline about compression levels and algorithm authors will strive to maintain that, but it is not guaranteed, and I have seen plenty of cases where the "belief" doesn't hold

and that's especially visible when you are pushing those algorithms to edge cases

it's just that in this test it turns out that the best is not the best? for what reasons? why don't you think it's a bug? algorithms for that and algorithms that there is a clear and understandable explanation for their work

it can be argued that, for example, higher compression levels should also run lower compression levels and pick the best result, and sometimes it is naturally possible, but sometimes it isn't and it's a waste of time to run lower compression levels which will lose most of the time

<@268284145820631040> can you explain to me why VarDCT works longer and produces the worst file size

so as long as you don't frequently encounter that kind of cases, it's fine

I'm not a best person to answer that (I do have some understanding of modular encoding in libjxl, but not VarDCT), but my guess is that at each effort level libjxl will try a *limited* set of AC strategies and other parameters, and sometimes those sets don't overlap

so higher level may have missed a better set of parameters in this particular case

<@794205442175402004> I need you to tell me who is working on VarDCT

If this is the case, then why is there no Higher level that would compare all the best results? to use all functions from all compression levels

if the highest level wins about 99% of time there is not much incentive left to run lower levels, I agree it *can* be done in principle, but it doesn't have to be absolutely done

but, if you can demonstrate that, in most remaining cases lower levels can produce significantly better files than the highest level, then it might be worthwhile to run lower levels

I believe libjxl developers have already done that calculation though

to conclude my remark: compression, especially lossy one, is a balancing act between compression ratio, output quality and compression time

it is very easy to result in a seemingly suboptimal result, but it might not be worthwhile to fix that suboptimal result if that suboptimality is not significant enough

I can imagine that in the future there would be jxl recompressors like DEFLATE, and they will try a lot of different parameters including those not even covered by libjxl at any level, but libjxl doesn't have to do so, much like many other DEFLATE implementations don't

ah, and I forgot to mention that in VarDCT efforts are correlated with quality

I want to show that in this case e7 gives better quality than e9

maybe you are hitting the worse case scenario for Butteraugli then? (I haven't calculated the actual metric, but it might be a possible explanation)

?

so libjxl may have thought e9 is better than e7 in terms of Butteraugli, but it's not when you actually look at it

No I do not know what it is

(or you look at it *after zoom*)

can I have manY quality metrics when creating a file?

Butteraugli is an image distance metric used by libjxl, assuming that the image is seen from a certain viewing angle and distance from the screen and the screen has a specific intensity profile

so if your viewing condition doesn't match those assumptions, libjxl can give you a lower-quality image thinking it performs better in Butteraugli

okay, let's not discuss the problems of metrics yet, let's go back to my first question

that kind of things can easily complicate any lossy compression codecs

why does the white sheet in e9 is size 15% more than e1

keep in mind that e9 is still much smaller than the original uncompressed file 😉

and as far as I know Jpeg XL does not have a function that determines which algorithm is better to compress VarDCT or Modular

in this specific case the optimal encoder will have to determine how to efficiently encode a maximal-length RLE under the constraint of JPEG XL format, and that's not a typical case I think?

I want to say that PNG size 2 times less than EVEN modular e9

202 bytes

that's true, even when you specify a specific distance there is still a chance that modular is actually better than vardct at that distance

well I believe a hand-crafted JXL file will easily reach ~50 bytes

lossless webp also size less than jpeg XL

well how

actually, I've checked that, it is 21 bytes long

I've used jxl_from_tree https://jxl-art.surma.technology/ with the following spec: ``` Width 800 Height 600 - Set 255 ```

I note that webp in a white picture at any quality gives an identical size, but jpeg XL does not

so that's about the theoretical optimum if you have infinite time to optimize a particular JPEG XL file...

it's an entirely different story whether an encoder can produce that file in a reasonable amount of time or not

of course, someone made a function to automatically detect this? and creating such an image directly in Jpeg XL

https://jxl-art.surma.technology/?zcode=C89MKclQMDQwMuHySM1MzyiBsJ0yS1JSC0AyXLoKwalAUS4A < I got 20 bytes

well JPEG XL can be directly used to simulate cellular automata with a small MA tree, but the encoder will have no idea whether a particular image can be produced by CA or not

and some cellular automata can be used to simulate Turing machine (keyword: universality of CA), so you are essentially asking the shortest program to produce given output... and I think "extremely" is not even a good word to describe the computational complexity to do that

I'm not asking you to create a complex function for creating images, I'm only want "are all pixels of the same color in the picture?"

of course you can detect that case and produce a specific image for that

but there would be tons of those cases

what if, for example, the image is a horizontal linear gradient? that can be also detected and described with MA

that would be very revealing, we're talking about a hundred bytes, but the weight is 20 times less than a standard Jpeg XL

but by doing so you may also have to detect a vertical gradient because it'd be strange that only some directions work well

and things can escalate from there quickly, and the time to detect those special cases will soon dominate the total compression time

I'm also wondering if there are tools to look at the boundaries of the VarDCT blocks

maybe there might be a sweetspot for detecting those "simple" images, and you may propose one, but I would not hold my breath for that

`not create complex function`

complex function is impossible to detect, but even simple images will take time to detect

what is the maximum size of the VarDCT block at the moment?

256x256

J40 actually has an `if (false)` block for overlaying block boundaries, so it might be a use for you

Well, I tried a 768x512 image, ideally for 6 blocks, so that they with zeros and reduced to a few bytes. but the image still weighs 450 bytes, so NOTHING works

I'm not even sure if libjxl *does* produce an image with DCT256x256 blocks by itself though...

https://jxl-art.surma.technology/?zcode=C89MKclQMDQwMuHySM1MzyiBsJ0yS1JSC8AyXFyZaQoVCnYKhlwKCroK4QraEEZwaomCARcA Took me way too long to figure out how to do a simple gradient

in any case, I see it as a problem that no one noticed, it needs to be solved

and explanations

it will be very interesting to implement all possible linear gradients in this way, but I'm not very sure if it's actually possible (because of truncation errors)

this is of course interesting, but I'm only interested in the fact that an empty picture does not Size 20 bytes as it can, but size 597

I assume it's just a "simple" optimisation that's being missed, something to step in and override the normal encoding methods

"This entire frame is a single colour, use modular+palette instead of VarDCT mode" etc.

cjxl on opensuse does not create jxl files. I'm doing bug report. What severity should I choose?

Looks like it cannot encode only from png source. I'm choosing normal severity. probably built without png support or something.

<@263309374775230465>do you have linux?

my friend linux just had problems with png yesterday. when he compiled last build, and everything works for me on windows

and then he just took the finished build and everything was fine

missn build dep?

this works.

<@794205442175402004>

how do you mean, working on vardct?

vardct encoder improvements?

I think atm encoder improvements are not the first priority

in order not to read our hundreds of discussion posts, I just want to ask why the encoder cannot encode a 768x512 white sheet as 6 blocks of 256x256

I found out that at the input an image with one color, firstly, the size increases with increasing complexity, as well as that the quality factors somehow affect the size... do you have the tools to look the Boundaries of the VarDCT Blocks? <@794205442175402004>

iirc, current libjxl doesn't use blocks larger than 64x64

or at least not by default, maybe there's a way to make it use the huge blocks too

<@794205442175402004>do you have the tools to see the internal architecture and the location of the blocks, and what kind of blocks are they

https://github.com/libjxl/libjxl/blob/main/tools/demo_vardct_select.sh

in particular:

``` benchmark_xl --input=$tmp/orig --codec=jxl:d$i --save_decompressed --save_compressed \ --debug_image_dir=$tmp --output_dir=$tmp convert $tmp/orig \( $tmp/orig.jxl:d$i.dbg/ac_strategy.png \ -alpha set -channel A -evaluate set 66% \) \ -composite $tmp/blockselections.ppm ```

if you pass `--debug_image_dir` to benchmark_xl, it will produce this file `ac_strategy.png` that represents the block selection, which you can then overlay on top of the image with that second imagemagick command

why did you write so difficult

I am absolutely...

i copypasted from that script

no the input has to be a png or something

the visualization thing is done encode-side, I don't think we can do it decode-side

Error in jxl codec D:\a\libjxl\libjxl\tools\benchmark\benchmark_xl.cc:129: JXL_CHECK: speed_stats.GetSummary(&summary)

what about the paths?

oh you might need to compile a debug version, could be that the release version misses that visualization code

and you need to make sure that the debug image dir already exists

what this D:\a\libjxl\libjxl\tools\benchmark\

I run the program on the C drive and don't specify anything

and of course what are the convert commands if I'm on windows

I found out that the bug is found when calling the --debug_image_dir= command it just doesn't work

higher effort doesn't just produce *better* quality per bpp, it more accurately matches the target quality

effort=3 tends to undershoot the quality target

so while it produces smaller files, that's typically because the quality is lower than you requested it

so at, say, effort=7, you're going to get pretty close to the targeted butteraugli distance of 1

but at effort=3 you might ask for distance=1, but you end up getting a file lower quality than you asked

I need to find out how and why the reduced quality affects the weight of the picture, if it remains identical, I would not have a question if it were to weigh less, But WEIGHT is increasing, this is not normal, are you on linux? could you run up command?

because quality ultimately isn't something that the encoder gets to decide. the encoder gets to decide how much it *quantizes* the image

I have an urgent need to see the structure of these 3 files because I don't understand

i.e. it decides how much data it discards

discarding more data results in lower quality images, but with smaller file sizes

the decoder has to make an estimate of how much data to discard in order to achieve the desired quality

we are talking about this image

white 800x600

and I discovered that, with VarDCT, with increasing complexity, it becomes size up

that ultimately depends on the heuristics

And I want to know - why

libjxl's effort=3 always produces lower file sizes than effort=7 (at the same distance), regardless of the input if I had to guess, it's because effort=7 turns on some optional features that have some overhead to them

it should probably have a heuristic to determine if they are necessary but it doesn't

And There is a big waste of time on the arrangement of structural blocks, but this only makes it worse?

I'm not entirely familiar with libjxl's specific heuristics

<@853026420792360980>can you see what's here

oh god that shell script looks awful

I need to fix it

can you use it to show the structure of the blocks in the image?

no, the script doesn't work

benchmark_xl --input="white.png" --save_decompressed --save_compressed --debug_image_dir="/tmp" --output_dir="/tmp" --codec=jxl:d1

--debug_image_dir IS not work in Windows

the issue is `--save_decompressed`

well.

I assume it's a bug caused by the changes in the io codecs when cjxl/djxl were switched to use the api

How to make animated jxl from apng?

`❯ cjxl test.apng test.jxl -d 0 JPEG XL encoder v0.7.0 [AVX2,SSE4,SSSE3,Unknown] Read 426x240 image, 15349882 bytes, 0.7 MP/s Encoding [Modular, lossless, effort: 7], JxlEncoderAddImageFrame() failed.`

can you send that apng or a smaller example so someone with a debug build can see why it's failing?

I just created a APNG using ffmpeg. `ffmpeg -i 2022-11-07_20-03-33.mkv -vf scale=-2:240,fps=24 -ss 00:00 -to 00:10 test.apng`

That APNG is a valid one. it works fine in firefox. `❯ file test.apng test.apng: PNG image data, 426 x 240, 8-bit/color RGB, non-interlaced `

rare shot of Chrome deprecating JXL support

I wasn't able to make anything useful with them -- my thinking was to use optimization to find encodings, with layers having big transforms and selection masks

🤔

--save_decompressed bug

well, is there some way to look at the internal structure of VarDCT blocks visually?

benchmark_xl --input c.png --output_dir . --codec=jpeg:libjxl:d1.0 --save_compressed

$ ./ci.sh opt $ ./build/tools/benchmark_xl --input input.png --output_dir . --codec=jpeg:libjxl:d1.0 --save_compressed

but it doesn't work, show what you have at the output

<@416586441058025472>