JPEG XL

but it seems I have made a mistake that makes (at least in some cases, if not most) the better approach to behave worse

I don't want to guess what it is, I don't know enought and I want to keep the most open and humble mind for debugging

Oh, so it's mostly an issue related to post filters, not actual image coding. Is there a bistream analyzer that can analyze a JPEG-XL image? I'd love to work more on JXL ever since I've picked up more skills in video codec development.

but it is 100 % clear that it is on my plate

JPEG XL Rust decoder would likely need more hands

or if you like, I could debug this together with you -- I could show how I'd approach it and what I would try in fixing it

I'll try to avoid rollbacking it because it is just far better approach as is

the heuristic is L2 related if I remember, and does the matching based on L2 (or perhaps L4, not sure, need to dive into the code again)

If you want to write Rust you're very welcome!

Hello Luca, it's been a while 😄

I still need to find enough time in a row to put together the main skeleton of the modular decoder, there's already a good amount of stuff to do but that would unblock even more 🙂

The JPEG XL Rust community is lively, intelligent and things are happening with speed -- and it is less mysterious than encoder quality topics 😄

is it common knowledge here that Microsoft seemed to have published a JPEG XL plugin https://apps.microsoft.com/detail/9mzprth5c0tb?hl=en-US&gl=CH

hi bluesword!!

Hi couleur.

The image coding did definitely change though, it seems like 0.8 uses smaller block sizes compared to newer versions. Left 0.8 right 0.11, same bpp.

This might be relevant, although I'm not sure if it's the cause of the regression

What tool are you using?

the java decoder, jxlatte

Most internal libjxl debug views are currently broken due to changes over the years, however jxl-oxide allows viewing hidden frames, metadata and chunk offsets using `jxl-oxide -I --all-frames --with-offset input.jxl` jxlatte allows debug views of VarDCT block selection with `jxlatte.jar --draw-varblocks input.jxl VarDCT.png`

Looking at that, it seems like large blocks were outright disabled in 0.8, so there should be room for both quality and density improvements between them

Ah yes, I forgot about that

What I want to see specifically is how the large blocks are quantized. Larger blocks don't necessarily have lower fidelity.

Don't forget that large blocks get some of their AC coeffs encoded as part of the LF image already. E.g. a 32x32 block has 4x4 LF coeffs, so not just the DC but also 15 low freq AC coeffs. The quantization of all LF is the same. Adaptive quantization only applies to the rest of the coeffs, only the HF.

No such tool exists yet

Libjxl can visualize the adaptive quantmap

benchmark_xl has some option to get debug images

Assuming they still work... I can't get any output from benchmark_xl anymore, even just output images

Yeah you might need to edit some code to make it work again.

I don't think these two issues are directly related to each other. In AV1 specifically, 64pt transforms only retain the first 32 coefficients (as a hardware saving measure), so for e.g. a 64x64 TX, the encoder only considers 1/4 of the coeffs (upper left quadrant), truncating the rest. Therefore these larger transforms are a bit "blurry" by design. AFAIK, JPEG XL considers all coefficients during quant/dequant no matter the transform size. Please let me know if I'm wrong.

back to jpeg? from jpeg xl? no

uhhh, it should be

```cjxl derpy.jpg derpy.jxl JPEG XL encoder v0.11.0 0185fcd [AVX2,SSE2] Note: Implicit-default for JPEG is lossless-transcoding. To silence this message, set --lossless_jpeg=(1|0). Encoding [JPEG, lossless transcode, effort: 7] Compressed to 21296 bytes including container djxl derpy.jxl reconstructed.jpg JPEG XL decoder v0.12.0 3d7cec2 [AVX2,SSE2] Reconstructed to JPEG. 910 x 461, 6.315 MP/s [6.31, 6.31], 0.415 MB/s [0.42, 0.42], 1 reps, 16 threads. 27,593 derpy.jpg 21,296 derpy.jxl 27,593 reconstructed.jpg```

Yes

no way <:monkaMega:809252622900789269>

its a unique capability no other media format has. normally youre supposed to either end up with a much larger lossless output, OR or a degraded quality output thats not even guaranteed to have a smaller filesize AND still takes long to encode (you can lower the target quality until it becomes smaller, but it worsens generational loss further)

I would rather have a grainy-looking type of blur that preserves texture and grit and high-frequency spectrum energy... than just play-doh smooth or blocky/smearing blur that is so typical and jarring in current libjxl and most other notoriously poor codecs

Like in really bad hardware AV1 coders or early versions of libaom

grain and high-frequency energy does a good job of masking blur and other artifacts.

do the checksums match?

Yes, if no error occured

Unfortunately, getting that kind of blur is very hard.

`--photon_noise_iso 250000`

it was posted here recently, so a fair number of active users would be aware of it https://discord.com/channels/794206087879852103/803574970180829194/1345719825552511046

jxlatte has `--draw-varblocks`

still gotta fix a few known bugs though

Not really, dct was basically designed to make it easy to preserve spectral energy while lowering the precision at the same time

Instead of totally wiping away high frequency information with blurring and smearing, it can be preserved with lower precision dct residuals

That's why dct is good at preserving grit and texture. When done right. There's no excuse for ugly smearing.

dct's typical weakness is ugly block artifacts. Not blurring/smearring

DCT is a very good tool for preserving sharpness and grit and texture especially at typical viewing distances where the blocks are harder to notice

It all depends on how steep your quant matrices are, you can make them steeper and be more blurry but less blocky/bandy, or you can make them flatter and get blocky before you get blurry

(where with steep I mean the higher frequencies get much coarser quantization than the lower freqs)

The default quant tables of jxl are quite ok

Someone had to intentionally design the encoder to blur and discard high frequency information instead of attempting to preserve it at low precision. Like you said, steep quant matrices where the high freq coeffs are 0

One of the weaknesses of avif/av1 is that you cannot really do custom quant tables, you can only pick from 15 presets or so iirc

Block boundary artifacts can be harder to notice through a lot of high frequency noise

Especially if it's spread around

Call it "blue noise blurring" if you wanna sound cool and fancy 😎

The problem is that retaining the same general **form** of grain is hard.

Macroblocking artifacts can potentially be psychovisually "masked" with noise

Macroblocking is a combination of low frequency and high frequency distortion

Since its at regular intervals centered on the edge of blocks

out of curiosity, was the idea of customizable predictors ever explored? as in, you could signal one of the predefined predictors in an MA tree leaf, *or* you could define your own as a simple arithmetic equation using these available pixel positions. like for example if the encoder wanted to make it `(NW + NE) / 2`, it could

I guess this would make the search space too large for the encoder to actually make use of it, and be very slow during decode

<@794205442175402004> just saw your bluesky post about an upcoming paper on JXL. Definitely interested, have any links to it?

this one? https://discord.com/channels/794206087879852103/822105409312653333/1346162085289267292

maybe... am unsure. Didn't have any specifics... but thought whatever it was would be worth reading. 🙂 I'll check out the one you mentioned. Thanks!

that's the one yeah :)

Yep that's the one

I've done some recent work on understanding AV1 QMs, and it turns out they're surprisingly challenging to improve on

despite those having unusual properties that you don't see in other QMs, removing those properties tends to harm subjective and/or objective quality

so in practice, the preset QMs tend to be good enough -- you just need to pick the right level

I suspect the original author (from Thor) authored those QMs by factoring in modern video codec prediction modes to fit like a glove

At first I thought you had re-invented JXL art, but I don't *think* that was. The existing predictors can already cover most cases that mixing them would be useful

yeah that's fair. i guess with it usually only using two predictors in most cases anyway, using more than the dozen or so that are available wouldn't really be worthwhile probably

As a refresher ```if [property] > [value:int] (THEN BRANCH) (ELSE BRANCH) Both the THEN branch and the ELSE branch can either be another decision node or a leaf node. The following properties can be used in a decision node: c: the channel number, where 0=R, 1=G, 2=B, 3=A (if Alpha was enabled in the header) g: the group number (useful in case the image is larger than one group). Modular group numbers usually start with 21. x, y: coordinates N: value of pixel above (north) W: value of pixel to the left (west) |N|: absolute value of pixel above (north) |W|: absolute value of pixel to the left (west) W-WW-NW+NWW: basically the error of the gradient predictor for the pixel on the left W+N-NW: value of gradient predictor (before clamping) W-NW: left minus topleft, i.e. error of the N predictor for the pixel on the left NW-N: topleft minus top, i.e. error of W predictor for the pixel above N-NE: top minus topright, i.e. error of W predictor for pixel on top right N-NN: top minus toptop, i.e. error of N predictor for pixel above W-WW: left minus leftleft, i.e. error of W predictor for the pixel on the left WGH: signed max-absval-error of the weighted predictor Prev: the pixel value in this position in the previous channel PPrev: the pixel value in this position in the channel before the previous channel PrevErr: the difference between pixel value and the Gradient-predicted value in this position in the previous channel PPrevErr: like PrevErr, but for the channel before that PrevAbs, PPrevAbs, PrevAbsErr, PPrevAbsErr: same as the above, but the absolute value (not the signed value)```

```Leaf nodes are of the following form: - [predictor] +-[offset:int] The following predictors are supported in leaf nodes: Set: always predicts zero, so effectively sets the pixel value to [offset] W: value of pixel on the left N: value of pixel above NW: value of topleft pixel NE: value of topright pixel WW: value of pixel to the left of the pixel on the left Select: predictor from lossless WebP Gradient: W+N-NW, clamped to min(W,N)..max(W,N) Weighted: weighted sum of 4 self-correcting subpredictors based on their past performance (warning: not clamped so can get out of range) AvgW+N,AvgW+NW,AvgN+NW,AvgN+NE: average of two pixel values AvgAll: weighted sum of various pixels: (6 * top - 2 * toptop + 7 * left + 1 * leftleft + 1 * toprightright + 3 * topright + 8) / 16 Edge cases: If x=y=0, W is set to 0. Otherwise, if x=0, W is set to N. If y=0, N is set to W. If x=0 or y=0, NW is set to W. Similarly, NE and NN fall back to N and WW falls back to W.```

Hi, I see that Microsoft has made its JPEG XL extension public. Is this finally a way to get thumbnails on Windows, or were there other solutions before?

https://github.com/saschanaz/jxl-winthumb

now we just need discord to support JPEG XL!

since it's based on electron, which is based on chromium....

hm.

Discord recently added "support" for AVIF via converting them to WebP for display

I guess the same could be done for JXL 🤷

Discord only added support for uploading and displaying webp images a couple of years ago even though it's been in chromium for over a decade 😆

Thanks! I guess it's better than the official solution?

Hmm, that doesn't seem to work for me.

Microsoft store one or GitHub one?

Github one

did it say something like this at any point?

Yep

hmm maybe restart Windows? oh also the DLL needs to stay in the same place/location that you ran the commend on it. If none of that works then I'm not sure what the problem is however if you are on Win11 then the Microsoft store one should work fine enough

It's been 42 days since I last restarted it, so it shouldn't hurt. Otherwise, yeah, I'm on W11, but an older version that's not compatible with Microsoft's plugin.

there might be a vencord plugin for that

eh, unless vanilla supports it im not able to upload jxl

Discord requires webp to work

Almost every bitmap is in webp format

If you disable webp, discord breaks, even if you remove it from http accept headers

No one should ever actually consider installing the official discord election app... but if they wanted to support jxl they could use the existing js polyfill, that's probably the simplest way for them to do it until Chrome bends the knee... https://github.com/niutech/jxl.js

Or, alternatively, they could just add support only to their thumbnail/preview generator lilliput.

That is required for previews to work like with other image formats

if you use chrome with better discord you can install a teivally modified embed more formats extension. but I just use dissent which supports jxl

there is a webapp called fshcord which also embeds jxl

Fishcord?

https://github.com/fsh-org/Fshcord

fsh

got screenshots?

not off hand

Out in New Brunswick now, stuck on road at 5 am, anybody who says that JXL is useless, is quite frankly an idiot. JXL is coming in clutch with out 400kbps internet

Wouldn’t AVIF be better for that kind of ultra low bandwidth at least right now with current encoders?

I want it to still look good tho

prog decoding king

progressive decoding still matters in 2025

it always has. people who say it doesn't probably have fiber, live next to data centers, only go to centralized websites, and never go on the internet outside a city or something

I used to be in sticks but not like this, thankfully tommorow I will have starlink, but for now, low speed unlimited data for now with 1 bar lol

🇨🇦: "We hate everything from the 🇺🇸 and won't buy it!" meanwhile, someone in 🇨🇦: "Yes I'll take Starlink please."

even then, its nice to have the image load partially so you can actually look at it quicker, so prog decoding would benefit everyone who looks at stuff

hey, I don't care what whoever does, if I get faster then 512kbps I'm happy

I have dealt with dialup internet as late as 2014, it is pain

In upgrading a commercial software that used jpg internally for data storage to use jxl instead for higher quality / smaller size, we noticed an issue that I don't know if it's expected or not. It seems that recompressing the same image multiple times the same jxl with the same settings, progressively introduces more and more artifacts into the image. This wasn't the case with jpg. Now this can be categorized as a bug in our software, but in any case bugs happen and once the images are destroyed, they are destroyed. I wonder if this is something that it's expected of the JXL format or not, and it's expected to behave (much) worse than JPG in this regard

No, since it needs to download the entire image first before you can even begin decoding, then you have to wait for the decoder to finish completely before an image can be displayed.

With JXL you can start decoding while it's still downloading and get a good preview with less than 1/10th of the image downloaded.

There's no comparison with AVIF at all

For limited bandwidth connections

ahh i forgot about progressive decoding

Older versions of the libjxl encoder were designed to be more resistant to generation loss. There are still some encoder settings you can adjust to reduce generation loss, ask one of the other encoder experts here. I don't remember all the flags or effort-levels off the top of my head, but the important ones are disabling gaborish and epf

Some JPEG1 encoders are extremely resilient to generation loss too. That's why you're noticing less generation loss there.

I think jpegli (included with libjxl) might also be very resilient to generation loss

Hope this helps explain what you're seeing :)

yes, thanks even just the "generation loss" term helps 🙂

i'll wait if someone can suggest encoder settings, we might have to patch something in untill we devise a proper solution

Yes, also it's usually very discouraged to subject images to multiple rounds of "lossy" transformations where small errors can accumulate. a lossless encoder is recommended as the best tool for images that will be subjected to transformation and compression multiple times.

what encode settings are being used currently? additionally what version of libjxl and also what was being used for JPEG encoding (library/encoder and encode settings)?

for the most part only the first question of mine matters

For lossy JXL you should disable EPF and gabor filters, or try a lower effort setting (default effort level is 7)

in cjxl, if you set distance = zero, you have lossless mode

just a small sample of the artifacts

this is originally a cad generated image so it's vector graphics so to speak

are all images that go through this software from cad or just this sample?

`--epf 0 --gaborish 0` for lossy mode will help, if you are using cjxl.

no not all of them

it's one specific use case though

others are pictures taken with cameras

we know which is which btw so we could use different encoder settings of course

i'm tring to see what we use now exactly

If you are using lossless mode, and you find lossless compression is too slow, lower the effort value to 2 for example.

we are using a slightly lossy mode

Gaborish is the primary source of generation loss, EPF is fine as far as I know

`--distance 0 --effort 2` is extremely fast and good.

quality 95 i think

we use libjxl directly (not spawning cjxl)

Try quality 95.6 (mapped to a distance of =>0.5). It disables Gaborish by default and should reduce generation loss

epf is a pre/post filter in the same category as gaborish. I doubt it has no effect on generation loss.

For high quality CAD and other synthetic images, lossless is quite often (i would probably say almost akways) a better pick over lossy.

*in newer versions of libjxl (I forget the date exactly)

no problem, the api provides nearly identical options and knobs as cjxl.

It's mostly Gaborish, not epf https://github.com/libjxl/libjxl/issues/3458

cjxl is basically just a wrapper for libjxl

i think we're using JxlEncoderDistanceFromQuality() and then JxlEncoderSetFrameDistance

i'm still looking to confirm if we provide 95 to JxlEncoderDistanceFromQuality but I think so

wow. Are you sure epf is enabled in that video?

If so I'm very impressed

It's best to explicitly disable gaborish if you are worried about generation loss, but even better to use lossless mode.

Or hear me out, lossy modular <:Stonks:806137886726553651>

unfortunately we need the additional size gain; we shouldn't recompress images in principle but it turns out we need to fix a few bugs

ok so i'll try the 95.6 trick and/or explicitly disabling gaborish

in the future when the libjxl encoder is tweaked/improved more then lossy modular might be a really good option for the CAD style images

https://libjxl.readthedocs.io/en/latest/api_encoder.html#_CPPv424JxlEncoderFrameSettingId

For example: ```c if (JxlEncoderFrameSettingsSetOption(*frame_settings, JXL_ENC_FRAME_SETTING_GABORISH, 0) == JXL_ENC_SUCCESS) ```

Same thing with `if (JXL_ENC_SUCCESS == JxlEncoderSetFrameLossless(*frame_settings, JXL_TRUE))` If lossless is too slow try setting `JXL_ENC_FRAME_SETTING_EFFORT` to `2`

At a distance less than or equal to 0.5, Gabor filter is automatically disabled, according to `lib/jxl/enc_frame.cc`

No need to use `JxlEncoderDistanceFromQuality()`

Just use `0.5` directly as the distance value

Or, you can use any distance you want, and just disable gabor manually.

with `JxlEncoderFrameSettingsSetOption()`

Then you can continue using the same distance/quality settings but still have better resilience to generation loss

:)

But still, if you can afford it, might as well use lossless. Lossless mode can be extremely, ridiculously, insanely fast if you use effort 1 or 2

also you're likely going to want low distance anyway if you're trying to be resilient against generation loss

or lossless in general

best to explicitly disable gaborish instead of relying on encoder quirks which could change between versions

Ya know... I *think* Foxless wants people to use effort 2 lossless :P https://discord.com/channels/794206087879852103/794206170445119489/1347148914104598569 https://discord.com/channels/794206087879852103/794206170445119489/1347149958326784101 https://discord.com/channels/794206087879852103/794206170445119489/1347150029579616327 https://discord.com/channels/794206087879852103/794206170445119489/1347151510253080626 https://discord.com/channels/794206087879852103/794206170445119489/1347160716980912140 https://discord.com/channels/794206087879852103/794206170445119489/1347165072975462431 Hard to know though

Also, I wonder if 0.8's higher quality means less generation loss with gaborish disabled

https://www.iso.org/standard/85066.html

why is this so expensive

are there other jpeg xl papers out there

ISO standards are always crazy expensive.

Because ISO is a scam

Sorry lol <:kekw:808717074305122316>

But it's true lol

there's community draft in <#1021189485960114198>

https://discord.com/channels/794206087879852103/1021189485960114198/1256224842894540831

this is the direct link

apparently the reference implementation is more of a standard than the standard itself though

It's a multinational bureaucracy of trade cartels. You can't expect any better...

libjxl is part of the spec (18181-4)

the difference is that there's no paywall

Uh, no... the reference implementation is pretty hard to read. jxl-oxide is actually much cleaner and legible

(I never thought jxl-oxide is legible enough)

the reference, libjxl, is... well, it hasn't aged well.

I mean granted they did fix some important issues like making it return errors instead of merely calling abort()

Not to say that it hasn't improved in a lot of ways. But as far as readability goes, nooooo.

I never said it was easy to read, just that it's more authoritative than the spec itself

Oh, so that's what you mean

Not necessarily. It depends on if it's less risky to change libjxl or to change the spec

It might be too risky to change libjxl if there is a bug that would make existing files corrupted in a way that was impossible to reliably detect

That's the only case where the spec would be changed to match incorrect libjxl behavior

mainly this one https://github.com/libjxl/libjxl/issues/3356

this is an unfortunate one, it's obviously libjxl bug but fixing libjxl introduces bitstream incompatibility

so spec is modified to match libjxl

yeah but changing the spec had other advantages

making people buy the second edition?

I said *advantages*

that is an advantage (to the ISO)

well I don't think anyone here is affiliated with ISO <:kkomrade:896822813414011002>

No one here likes the ISO, it was only done to be 'official', hence the free draft copy here

I wonder how much money ISO makes by selling specs...

Although, with that bug, maybe there would in fact be an unintuitive way to reliably detect the problem in existing files. I have a proposal.

like surely all 3 people that bought it aren't enough to justify paywalling it

I don't know how it works inside ISO, but does JXL being ISO standard gives it any leverage in applying its support into PDF (which is also ISO standard) over AVIF (which isn't ISO standard)?

does PDF support either?

at the moment none, but they are in the process of choosing format for HDR images

JXL makes more sense

I feel even without that, JPEG XL would be the obvious choice, as it supports good lossless, JPEG transcoding, HDR, and a bunch of other features

I once tried to find a way to detect such image and implement that in jxl-oxide, but failed https://github.com/libjxl/libjxl/issues/3356#issuecomment-1984036235

AVIF's features are just: HDR (which jxl also has), efficient at very low bitrates (not as helpful for a pdf), (terrible) lossless support

yeah, JXL is really the only sensible choice

In the case of this bug, it's a bug with lz77 encoding, so existing files can be fixed and corrected after detection. As far as detection goes... all you have to affirm is that it was encoded with a version of libjxl released before a certain date or commit that fixes the behavior.

yep, but browsers support is may also be a consideration - eg. currently browsers include Javascript JPEG2000 decoder, since JPEG2000 can be embedded in PDFs and browsers don't support it natively

solution: also support jxl in the browser!

just one more reason browsers need to add support for JXL then

If you know the quirks of the libjxl encoder, you can detect if the image was encoded by a version of libjxl before a certain commit, if the commit that fixes the old behavior also changes an unrelated quirk.

It's an unintuitive solution but I think that is the way to detect how old the libjxl version is.

libjxl has a lot of identifiable quirks that form a fingerprint when encoding a file

this might break when other encoder than libjxl would emerge

True, but, depending on the quirks you choose to look for, you can make it highly unlikely to match a different encoder, like a fingerprint.

it's already changed, too late to try to revert it now I would say

Not necessarily. The situation is basically the same, the only difference is that everyone became aware of the problem and decided maybe it would be easier to change the spec.

It's just a decision, I'm just pointing out what the possibilities are.

My about me page says "anything is possible" :)

https://discord.com/channels/794206087879852103/803574970180829194/1340711274824204350

And since PDF/R is a subset of full-PDF, then they need to add it to main spec first, right?

Since it's a lz77 related problem existing files can potentially be repaired, losslessly

<https://github.com/libjxl/libjxl/issues/3356#issuecomment-1984036235> > if a group has only one LZ77 repeat symbol at the end of the stream, both spec and libjxl method will end up in identical final bitstream and entropy-coded stream state, but they will have completely different image.

can someone download the pdf and send it here? I can't access it due to vpn blocking

Scroll down a little and check the survey. They ask if it should be a PDF/R exclusive

what do yall think? should it be PDF/R only or main spec?

Regardless, if it's added to pdf/r at all, the chances of it getting added to pdf next are much better

I originally wanted the spec way for the better compression, but apparently it was a few bytes at most if anything. So, why go the spec way?

Stubbornness or the joy of solving impossible problems.

:)

I said both, since I'm not in a commercial environment so only interact with regular PDF

No other real form of justification

so the main spec inclusion would still remain uncertain, although it wouldn't have much sense to have AVIF in main spec, and additionaly JXL in PDF/R

do you know if PDF/R is widely used?

Regardless of the outcome it would be good for <:JXL:805850130203934781>

what even is the difference between main PDF and PDF/R

"PDF/R, short for "PDF for Raster Images," is a specialized subset of the Portable Document Format (PDF) designed for multi-page documents primarily composed of raster images, such as scanned documents." "The "R" in PDF/R stands for "raster." - from <https://www.pdf2go.com/dictionary/pdf_r>

so it's like webm is to mkv? 🤔

here's a more detailed description https://www.loc.gov/preservation/digital/formats/fdd/fdd000493.shtml

so it's just worse pdf?

more limited, it seems

simplyfing - yes. but probably easier to implement in embedded devices like scanners

So it's djvu

I love the <:JXL:805850130203934781> community. Very peaceful and cool.

avif jumpscare

>AVIF.png

😹

Something wrong with discord-lilliput, the colors change when the preview becomes full size

progressive loading animation of that image, with jxl and avif

Behold

oooooooooooooh, thank god I'm not the only person experiencing this

I uploaded an image the other day and discord's preview image had its colors messed up

though I think they were messed up in the full size preview too

Yeah, it's because their lilliput backend server generates a webp preview of every image

yeah, but why would the colors get messed up?

And the colors in that webp always look weird because webp is atrocious

this wasn't just a webp thing

it's a very vanilla image, sRGB, SDR, etc.

Lilliput converts every image to webp. When you request the full size image you usually get the original.

well when I opened it in firefox it looked fine

so something on lilliput really screws up the colors

Yeah it has a history of doing that too, because it doesn't interpret the colors correctly a lot of the time when doing the conversion

I'd consider djvu more advanced than pdf/r because of all the layer separation stuff, and kinda different if djvu does its own image compression algorithms (which I'm 100% not sure it does) - pdf/r uses existing image compression standards

<@206628065147748352> by the way I have a jxl that fails to decode in jxl-oxide but succeeds in djxl

djvu has 3 separate codecs that can be mixed and matched and embedded in a single page or multiple page file

The 3 codecs are specific to djvu but based off existing research and technology

please open an issue or post it at <#1065165415598272582>

Wow Discord can display this

so that's what 96kbps network looks like

*JPEG XL.avif* 👍

Very recently lilliput was patched to include libavif support

That's why we get previews... but I'm not sure why this one didn't work?

is this the iso.org spec file?

Yes no-yes

oh this is interesting

promoted from bug to feature <:galaxybrain:821831336372338729>

Shhh

Not sure if anyone else saw, but maybe someone here has an idea what's wrong https://www.reddit.com/r/jpegxl/comments/1j0txiq/loss_of_color_in_lossless_encoding_getting_dull/

my knee-jerk reaction is this is some metadata/viewer problem

clearly, some linear data is passed where sRGB is expected or vice versa

Hello, is alpha-channel compressed by default as lossless? I want transcoded JPG for color channel and lossy compression for alpha, is it possible to achieve easily with command line or python?

1: idk 2: yes 3: yes

Idk if it's lossless by default but you can adjust the quality level of the alpha channel independently.

thanks

If you stick around here someone else will probably tell you the exact info. If you need API help I can pull up the info too

Ah, I just read more carefully what you're asking. You want to start with a transcoded jpeg as the base and then add an alpha channel.

Yes, some really stupid command line command would be helpful, I have monochrome pngs I want to embed as alpha channels

Okay... that will not be possible with the command line. It might be possible with the API? But I'm not sure...

okay I also remembered I wanted to squeeze 0-255 to 1-255 to have no fully transparent pixels

It's theoretically possible but idk if the API is flexible enough to add an extra channel after adding a JPEG frame

if it all gets recompressed it's not the end of the world but would be nice to have

Seems kind of random but ok, that would be done beforehand though since that has nothing to do with encoding to jxl.

yes I know

Eh... looking at the API reference, looks like it's probably possible to do what you're wanting

https://libjxl.readthedocs.io/en/latest/

You should try adding a jpeg frame and then adding an extra channel after that.

thanks I'll check the docs

And you won't be able to get the original JPEG back with current software, but you could theoretically with patched or custom software

Current software won't extract the original JPEG back out even though it's losslessly embedded and 100% feasible and possible

So you will just have a jxl with the same quality as the original jpeg, until someone writes or patches a decoder with the ability to extract lossless jpeg frames

:)

Just keep in mind what you are thinking of doing is uncommon and probably does not get tested as well

A frankenfile

After libjxl 0.9 Alpha channel by default is lossless

Alpha channel is stored lossless by default, but invisible pixels depend on settings. So if you do lossy, invisible pixels will be overwritten. If you do lossless, they're kept

IIRC

I figured that I better keep two files separate and do something with them hehe

That's adjustable in the public api

why is libjxl so bad at pixel art compression <:FeelsSadMan:808221433243107338>

What settings?

-d 0 -e <multiple> --streaming_input --streaming_output

it just loses to WebP lossless so often

or even ppm.xz

Oh, it's probably streaming input. But if not, is the art scaled? Ideally by 2, 4 or 8x

streaming input hurts in terms of compression, but not by much

the art is scaled but there's no consistent scale so I can't simply losslessly downscale and then upscale it back up with NN

oh, actually, I can do 1/3rd scale

but some of the art is like 1/6th

scaling it down made it worse 😆

this is the smallest <:JXL:805850130203934781> I managed to make, in the original (not downscaled) res

smallest ppm.xz (downscaled losslessly with NN to 720p)

and the smallest webp, also scaled down

JXL is 61% larger <:SadOrange:806131742636507177>

may I suggest https://github.com/Traneptora/xz-pixbuf-loader

I know but I want to make cjxl better

ah you're already familiar, okay <:kek:857018203640561677>

ideally jxl is just better tho

A better patch detection would blow any 1D dictionary coding away on an image like that...

WebP and general purpose compression are exploiting the repetitive stuff while jxl isn't really yet. It has coding tools for it, but using them effectively is tricky.

I bet

Even `cjxl -d 0 -e 10 -E 4 -I 100 -g 3` can't beat PNG for screentone images sometimes

Ahh, when you said pixel art, I was thinking of the more traditional type. I actually used Into The Breach to find a small bug with patches. The coordinates don't get scaled with --already_downsampled https://github.com/libjxl/libjxl/issues/2737

The main issue is the overlapping tiles, no? Like Factorio screenshots. There's a lot of tiles and sprites, but post processing and layering means they can't be detected

that would be my assumption

Where is the discord invite link

Anyone can share?

https://discord.gg/DqkQgDRTFu

Thanks boss

<@794205442175402004> Can we still use the 🧈 API?

The Butteraugli API was removed from libjxl a while ago, see https://github.com/libjxl/libjxl/pull/2576

Hello, can JXL save N arbitrary planes? I want to store YUV+depth for example. Not RGB.

that's hypothetical question

I won't be able to use it without an extreme PITA anyway

It supports RGB + 4096 arbitrary auxiliary channels (planes)

You could theoretically use Modular mode and store YUV data but it wouldn’t display correctly unless you have an ICC attached

As it expects either RGB or XYZ for the main image

Why can’t the input be RGB though?

it seems that converting RGB to something else consumes a lot of resources

Do you have RGB data? What format is the RAW in

idk, just plain 8-bit jpeg or png

That should be fine then

PNG is RGB and JPEG XL has first class support for YCbCr (jpeg colourspace)

~~*456 persons*~~

Are dynamic wallpapers theoretically possible with JXL? https://github.com/mczachurski/wallpapper As this repo reveals on macOS they are just HEIC containing JSON

I tried myself and it's true

Nothing magical

In GIMP 3, I have problem displaying images with specific ICC profile. I discribed the problem in https://gitlab.gnome.org/GNOME/gimp/-/issues/13139 using a HEIC file. However, I can reproduce it using JXL in GIMP 3 too. http://188.121.162.14/jxl/sky.jxl Is there a way to check if the ICC profile in the image is correct? Or is there a possibility the ICC profile is a new one with some CICP tag that is not parsed by some applications?

Try opening it in Krita, if colors are fine, then ICC is fine

Hmm nobody knows if dynamic wallpapers are technically doable via JXL?

from a technological perspective there is no reason why not

dynamic wallpaper?

Depends on the project, there are some which depend on the user providing multiple images which get switched at certain times. Since you use mac, why not try replacing your wallpaper with a JXL and see if it changes around?

I'm not the author of "wallpapper"

It's just metadata

I know, but you could still try my suggestion

Just don't know how to do

In the case of mac (or any OS), there is a wallpaper located in some directory. Have a look at thet file and replace it with a JXL encoded in a similar manner. Then see if it works or not

You can have up to 4096 extra channels, in addition to 3 channels for yuv/rgb/xyb

It can be depth, alpha, thermal, spectral bands, whatever.

by the way, how many frames (not channels) can you have in a JXL?

Dynamic wallpapers are actually just one container

Yes, "Appearance.heic" I believe they are called. Try recreating that file as a JXL

Well that's not a good sign https://www.reddit.com/r/jpegxl/s/Cpjzz2IaDA

Great embed, thanks Reddit

>>> https://youtu.be/SzsM4HMKmEI?t=1m34s avif just has more details and more compatibility than jxl, I think I will go for avif 😅

Ah, 200KB, that'll do it

Here we see an example where libjxl's steep quantmatrices and aggressive smoothing bites it in the ass, where it actually looks more vaselined compared to avif, leading to bad publicity.

If quality gets tuned in a future libjxl release, and libjxl gets better at preserving grain in the future, I suggest writing a press release or blog post of some kind, to bring more attention and publicity to quality/rdo enhancements.

That way, if/when libjxl improves, people might be more likely to forget about this embarrassing performance in the past.

And brush it off as "just a problem with the old version, fixed in the new release"

I don't want people to get a bad impression of the format because of problems with the reference encoder...

I should note, that even in this video, the avif file being compared looks even worse than the jxl in a lot of other parts of the image. Even worse blurring in some parts of the foliage too.

So the attempt results in a HEIF disguised as .jxl

I just wonder if "real" JXL could implement something like that

So OP is just an AVIF spy inside the JXL subreddit

If people want to investigate my self-made Dynamic Wallpapers for research https://files.catbox.moe/d9jtqt.heic

https://www.reddit.com/r/jpegxl/comments/1j9o9g4/comment/mhn0rmz/

> I tried XL Convert, AVIF looks better than lossy JPEG XL to me, at the same size. JPEG XL looks more blurry, is that normal?

people that only ever do LQ encoding baffled JXL's existence <:kekw:808717074305122316>

So it's not just that video. OP actually tried codepoems XL Convert and compared jxl with avif and saw the excessive blurring. Recent versions of libaom no longer have the same terrible smearing and blurring from before, while libjxl has mostly remained the same and still lacks automatic noise detection/synthesis

well JXL's grain synthesis is pretty awful

I was trying to replicate the video results, but all I did was find the desaturation regression instead

Main vs 0.8

Are you sure it's a regression? Even in really old versions of the encoder, it has similar change in color and saturation

0.8 is still worse than the AVIF, but better than main for saturation

Jyrki said a while back it's because the color quantization scaling factor is too naive and aggressive.

But I don't think anyone's tried tuning or correcting it yet

It mostly affects yellow/orange/red yes?

Looks like it

It appears djpegli is overwriting EXIF orientation as 1 for JPG -> PNG

but otherwise attaching the EXIF buffer. this can't be intentional, right?

I figure this is leftover information from JXL -> PNG, because you usually don't want to write the orientation tag for JXL

but djpegli isn't actually orienting the jpeg so I figure it should

good. 548 megapixels can be encoded and opened without any problems having 8 gigabytes of RAM in total

Huh, effort 1 seems slower than I'd expect

XnView can not open such file...

yes, it is slower than png, considering that standard png out 722 mb

and -e 2 is worse

I was hasty in saying that there were no problems with opening.

Can you try with this? https://discord.com/channels/794206087879852103/803645746661425173/1348643193734037514

No cropped or chunked decoding in libjxl currently, as far as I'm aware. You could try decoding with jxl-oxide using `--crop`, to see a region at a time without memory limits

try updating your version of Paint.NET maybe? the newest version is 5.1.6 and has somewhat improved JXL support

https://getpaint.net/roadmap.html

Strange that the bpp is higher, I was getting identical results. Guess something changed between those versions

this can't be a problem in any form. the decoder must comply with the stantatd legacy, or something was broken here from the beginning

I want to note that XnView also does not work. There is a memory jump and an opening error.

The image is around 1.5 GB just in memory, with decoding overhead it's likely hitting memory limits

and yet there is no problem in opening the original png image

PNG has very little decompression overhead, and streams the data

Jpeg XL lossless is divided into blocks. They are decoded independently, so where could be the problem?

with djxl there is no problem at all. and the memory used is not higher than when encoding

Oh, interesting

bruh. the bug

Yeah, for some reason `--disable_output` uses more resources than just outputting to `nul` with ppm

ok. the jxl image was good encoded, although I don't know how to open it, except for djxl decoding

<:JXL:805850130203934781> I hope in 5 years when I open it, it will open

VarDCT opens without any problems

One more bug

why every time i use jxl once in half a year it is always broken somewhere<:PepeHands:808829977608323112>

-d 20.1 and more caused a complete memory leak

-d 19.9 used 4 gb max

`-d 20` enables resampling, but currently it uses a very expensive and 10x slower downsampling method. I fixed it to use the faster version in this binary (And made `-d 10` resample with varying results)

-e 9, -e 8, -e 7, -e 6

why

Well I just can't use its. What are these leaks?

VarDct

The expensive resampling I mentioned is enabled at effort 7 and above

in Modular mode there are no such problems

ok. let's assume. why does resampling take 5 times more memory than the original image?

I donwscale the image by 2 times, this encoding is 11424 x 12000

It even has a comment saying to disable it <https://github.com/libjxl/libjxl/blob/main/lib/jxl/enc_frame.cc#L714>

So, I did <https://github.com/libjxl/libjxl/blob/2cd93c8b2a2f1eb1e290a6a8c2f7cc40e7954f73/lib/jxl/enc_frame.cc#L718>

Can Is it optionally disabled?

Almost works

-e 8 and -e 9 not

What about with `--patches 0`

💀

-e 6 -e 7 -e 8/9

I freed up some memory, but it still used to be about 2-3 times more, so I'll have to make do with -e 7 Which at least works on your cjxl 👍

<@238552565619359744> Nice to know that we are seeing real world examples where our changes are improving libjxl

<@238552565619359744> --resampling=1 -d 10 -e 7 --resampling=1 -d 10 -e 6

sad

Chunked encoding is also disabled under these circumstances: * When the image is smaller than 2048x2048. * Lossless Jpeg transcoding. * VarDCT at distances ≥20. * Effort 7 VarDCT at distances ≥3.0. * Effort 8 VarDCT at distances >0.5. * Efforts 8 & 9 VarDCT at distances >0.5.

No clue why

cjxl_jonnyawsom3.exe -d 10 -e 7 cjxl_jonnyawsom3.exe -d 9 -e 7

yep

only for d 10-20 works

It's an improvement, but doesn't fix everything

the bullshit

there is no point in doing any resampling at all, has anyone tested this? where are the tests? where are the graphs? Who said resampling makes jxl better?

I've always used -e 6 because of the better speed/quality tradeoff, but the fact that -e 7 forces resampling on low-quality -- is another argument for not using anything other than -e 6

e7 just enables the slow and memory hungry resampler, it's still enabled at all effort settings

Though, I have been contemplating moving the threshold to distance 15 instead, since at 10 it's best for photographic images but non-photographic struggles still

damn

Returning to my previous questions - why not just disable resampling on all qualities ?

Because it gives a significant quality increase at a size decrease

No, it doesn't

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

https://discord.com/channels/794206087879852103/804324493420920833/1348640701361160286

Well, some of them at least

some