JPEG XL

if that's what you want

also `align` is row_stride

but you can set it to 0 to mean "image width"

Didn't say it was unstable, but the jxl build process fails and asks for a package version that doesn't exist in the LTS package manager.

Yea, I mean there's no reason it couldn't be updated to Kinetic

Anyone run into this build issue/know how to bypass it? Seems like a warning. `libjxl/tools/libjxl_test.c:12:9: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]`

Got it, it's `CMAKE_C_FLAGS="-Wno-strict-prototypes"`

I just opened a PR: https://github.com/libjxl/libjxl/pull/1867

Thanks! Wasn't sure if it was a bug or just a quirk with the compiler.

nah it's just the C standard that is entirely ludicrous

I don't think the C standard is ludicrous for requiring that you declare your function arguments

well C++ is entirely fine with `()` being a zero argument function declaration, it's C confined by its past (older versions of C didn't have formal arguments at all, so `()` can accept any number and type of arguments while `(void)` should have zero arguments, but that's a very old version and one can say the older syntax should be just banned somehow)

I mean it is strongly discouraged, i.e. it's deprecated

ah, sure, but they could also remove the older syntax and make it mean what the `int main(void)` version means, it has been long enough xD

As of C23, I believe main() is fine

ah, nice

I noticed libjxl has a lot of code in header files which ends up getting compiled many times

I heard it was something to do with templates but is this really necessary? it makes libjxl super slow to build

This is a big problem across C++ code bases. Maybe if the templates are often instantiated with the same types, pre-compiled headers would be an option? But I do not know how those work.

much of the solution comes down to splitting the libraries even further than they are now.

they don't all have to be installed, but many projects compile lots of small libraries that get linked over and over rather than built over and over

is that why boost has a bazillion libraries

Question: I noticed there is a libjxr-dev on linux, is it planned a libjxl in near future. eg: next ubuntu releases?

-dev packages are the ones with the header files you need to build applications that link to the library

ok sure, but, I'm not sure if there is any dynamic linking (instead of static link). I'm interested on dynamic link on this question

libjxr and libjxl are unrelated

libjxl already can be linked dynamically

whether or not ubuntu packages it is up to ubuntu

ok I was asking "do you know if ubuntu will add it in future" ? 🙂

whether or not ubuntu packages it is up to ubuntu sorry I can't give a better answer than that

debian-based distributions are not known for having up to date software

ok thanks, that gives me an hint!

ironically, kinetic has libjxl-testdata

but not libjxl

fwiw, libjxl 0.7 is in debian-unstable

so probably

<@987371399867945100> what's the goal with the changes like https://github.com/libjxl/libjxl/pull/1897 you're making? Making a drop-in replacement for (decode-only?) libjpeg?

Yes, exactly, we want to have a new libjpeg-compatible library that has JPEG-XL inspired improvements in it. Eventually it would include the encoder too.

so is it possible to just replace the libjpeg(-turbo) libs/dlls and it will work (even for old apps)?

That's good strategy. It reminds me a situation from the past when some apps received AVIF support almost with no effort because libheif started to support it.

would it be feasible/desirable to also decode jxl files through the libjpeg api?

(obviously would only work in the no-alpha, no-animation case)

However developers and/or maintainers not always choose what is the best but what is the most convenient for them. For example MozJPEG has good reputation but many users end up using libjpeg-turbo only.

That is an interesting idea, so if you would run Chrome with this new library, then you could decode jxl files disguised as jpeg?

well not just chrome, anything that uses libjpeg-turbo right now

biggest issue is that it breaks alpha (and animation) and probably also HDR since most applications will only handle 8-bit RGB

but it could be a nice transition feature to have a drop-in libjpeg replacement that can also decode jxl (and does something sensible if there's alpha, say blend it to a checkerboard background)

and then if we can make the libjxl api also take legacy jpeg as input, there would be a nice transition path for applications: if they do nothing, they automatically get some basic jxl support (assuming people replace their libjpeg-turbo with a libjpeg-xl). If they're willing to update their app to use the new libjxl api (so they can get alpha, animation, HDR), they can get rid of the libjpeg dependency

didn't know until recently, but libjpeg-turbo is an official ISO and ITU-T approved reference implementation <https://github.com/mozilla/mozjpeg/issues/182#issuecomment-968127849> ```In more recent years, ISO and ITU-T have adopted libjpeg-turbo as an official reference implementation, making it more than just a de facto standard```

as I understand from previous posts, with the new decoder there will be less code and binary size needed to fully support libjxl, even if for now it is only a jpeg decoder as a transitional step, it would be nice to add support for jpeg transcoding, but although this would cause extra fragmentation

there are two approved reference implementations of jpeg: https://jpeg.org/jpeg/software.html

it is important to make the substitute library as portable as possible ideally with no or only common dependencies.

is JxlDecoderSetOutputColorProfile done?

no, not yet

hm, this jxlart: https://jpegxl.info/art/2021-08_totocaca.jxl no longer gets decoded by libjxl, probably because of stricter spline limits

which reminds me: if we want to enforce stricter spline limits (which does make sense from a DoS pov), we should define them and put them in the profiles & levels part of the spec

What did it used to look like?

jxlatte produces this, I don't know if that's how it's supposed to look

is it known how/why this happens with transparency?

<https://discord.com/channels/794206087879852103/878599623843913728/881994888844021760>

If asking about modified values of transparent pixels at encode time, it's to improve compression.

so how do i not get this when using decode api

~~oh, i'm guessing it's JxlDecoderSetUnpremultiplyAlpha~~ it wasn't

does libjxl produces JXL files atm with more than one pass?

Yes, if you use --progressive

what does a second pass even accomplish other than twice decoding time?

as far as I'm aware the cpu required to decode the first pass is the same to decode a pass-free image

so I'm not entirely sure how that improves responsiveness

Well you don't have to go through the rendering at each pass, if the data arrives fast enough.

but I meant, if you produce an image with 4 passes vs choosing to produce an image with 1 pass

you just have 4 times as many pass groups

like it would only make sense if the earlier passes can be made significantly smaller

is that the case?

On a slow enough connection, or if you would use range requests to only fetch the first passes (since the full res is not needed for the given viewport width), it does make sense to send multiple passes

Of course they are smaller, overall file size will not go up much when doing --progressive

ah, okay

how is this accomplished?

Early passes only contain the lower frequency coeffs

ah so in theory they can contain any coeffs in any pass but it goes into "why would you ever do that" territory?

Later passes only the higher ones, and with coeff reordering the low freq ones get pushed to the end so they are absorbed by the nonzerocounts

I see, this makes sense

why you would do that: to send more detail earlier in the salient parts of the image. In principle you could send the 1:1 data for the face early while the body and background is still blurry...

libjxl currently does not do that, but the bitstream allows this and it could be a powerful mechanism for mobile use cases where connections are flaky

so this (vardct transparency) also happens with djxl pfm and of course decode_oneshot

does djxl allow decoding to pfm if the image has transparency? that's probably a bad idea, or at least it should give a clear warning that alpha was dropped

But JXL saves so much bits that the entire image is already sent before you have the opportunity to use progressive decode!

Don't underestimate how slow 3G can be, and how many image pixels a web page can have...

I don't quite recall, but with jxl, the default mode has the DC first and then a progress grouping of all the AC valdes, right?

it's not the default mode, that's just how it works, period

Yeah we made it so you always get at least a 1:8 preview when doing lossy

Right. DC always first. But the second thing I said is a default right? All AC as a single pass top to bottom?

Yes

You can also do more passes and/or change the order of groups

Cool.

Honestly I think the default fits with what I like. I liked your (I think it was yours anyway) demo a few years ago showing a jpeg designed to progress with first a low quality version and then went straight to full quality.

I notice that flif progressive decode has a lot of high frequency details and texture early on.

compared to jxl

is there a way to tell if an image is modular only/vardct only?

libjxl doesn't expose that via the decode API, currently

What would you do with that information?

i have to multiply the transparency

so i figure maybe i only need to do it for vardct

Multiply the transparency?

There's no difference between vardct and modular in the semantics of alpha

like i want rgb, but for vardct i get this

You want RGB without alpha?

`--codec=jxl:m:1,jxl:m:9` iirc

We don't currently have a way to get rgb without alpha. Can't you just get rgba and blend it to a background color of your choice?

yeah that's what i'm doing

Very possible. Non-photo lossless compression is a weird thing where small differences in encoder choices (like palette order or predictor choices) can make huge differences in compressed size

does libjxl currently produce files with orientation != 1

not counting JPEG reconstructions

No

I think

Maybe if you give it a png with exif orientation as input, it does?

I attempted to create JXL with all orientation here: https://invent.kde.org/frameworks/kimageformats/-/tree/master/autotests/read/jxl

thanks, that's what I was looking for

So `cjxl` doesn't transfer exif?

Add `--compress_boxes 0`

Thanks!

I think this setting should be explained more clearly in `-h`

it does. it compresses them with brotli, but exiv2 doesn't support `brob` boxes yet

`exiftool` too?

So we have to wait till future release of Exiv2 and till the new version reach various distributions.

https://github.com/libjxl/libjxl/pull/1909 <@987371399867945100> So jpegli is a decode-only libjpeg that decodes jpeg to pixels. Could we eventually make a libjpeg-xl that contains _both_ the (simplified, high-level only) libjpeg62 api and the libjxl api, and that does the following: - through the libjpeg62 decode api, it decodes both jpeg and jxl (in case of jxl with alpha, it blends it to a white background or something) - through the libjxl decode api, it decodes both jpeg and jxl - through the libjpeg62 encode api, it produces a legacy jpeg bitstream with your encode-side improvements (with a new option to produce a jxl-recompressed version of it instead, and maybe an option to use xyb or not) - the libjxl encode api is just what it is now ?

Such a libjpeg-xl could then be a drop-in replacement for libjpeg-turbo that would give applications a very smooth transition path: if they don't do anything, they get better jpeg decoding and encoding and basic (no-alpha) jxl decoding, if they opt-in to produce recompressed jpegs (which would be a one-line addition in their code) they get another 20% compression improvement, and if they have time to do a more serious rewrite of their code, they can move to the libjxl api and get alpha, animation, HDR etc.

jpegli will eventually support encoding to jpeg as well, as for the combined jpeg+jxl library, that would be a separate project

right now is it possible to compile a windows dll to replace libjpeg62 for example?

not likely, it is far from ready, I only tested it on linux, and only with the benchmark_xl library

sad and it would be easier to make comparisons if cjxl could also be able to encode to a new jpeg (with or without xyb), for example benchmark_xl cannot encode to a given size (or I have not found this option)

theoretically, can libjpeg-xl be able to decode jpeg-xyb correctly if the app with the legacy libjpeg does not support ICC v4?

Theoretically, yes, it could detect certain profiles, do the conversion, and return e.g. an sRGB image with an sRGB profile. Assuming the app is not doing something funky like getting the icc profile in a different way than through libjpeg...

atm the code doesn't do that though, right?

I would assume not, but <@987371399867945100> is the one making this

no, it does not, and for that we would need to somehow recognize our XYB profile from its numeric representation of the A2B0 tag, which seems a bit brittle

I see

could just detect only a very specific icc profile (as in: exactly equal to what the jpeg encoder produces), but I agree this is kind of brittle

another option could be to just depend on a cms, detect when an application is doing a decode without getting the icc profile, and auto-convert to sRGB using the cms in that case.

<@811568887577444363> <@456226577798135808> is this wasm demo online somewhere? https://github.com/libjxl/libjxl/tree/main/tools/wasm_demo

I think it's the same one that's here: https://github.com/eustas/jxl-demo

are there any step by step thing anywhere to compile fjxl or do I compile from the regular instructions and it'll pop up too

btw... `I'm not a programmer and I suck at anything CLI so I'm pushing my luck as it is`

You need to compile it separately, it's not officially part of jxl

but on the other hand, because it’s ± self-contained, it might actually be easier to build

where is fjxl source code?

<https://github.com/libjxl/libjxl/tree/main/experimental/fast_lossless>

I've uploaded the libjxl WASM demo here: https://niutech.github.io/jxl.js/libjxl/

I didn't imply it was part of jxl

however, it is technically in the source code for libjxl

yeah I just mean it gets ignored by the libjxl build scripts

fair enough

I cannot find instructions anywhere

this requires some compiler environment and just run ./build.sh

windows builds if needed

Got progressive rendering working on `canvas`/wasm: https://discord.com/channels/794206087879852103/1036951308294434857/1045481067664134154

<@179701849576833024> Where can I find the base quantization table for libjxl?

quant_weights.cc

but it's not immediately obvious

Thank you. Am I allowed to borrow the quantization weights for something else? 🙂

sure... assuming you manage to get them 😛

I mean, it doesn't seem too complex at first glance 😛

Oh, it actually is...

~~use printf~~

That could be a good way to do it. Nicely enough, I don't need to look at any of other transforms, just DCT2. This should be a good exercise to translate this into a 8x8 DCT table that I can use for something I want to make 🙂

Essentially, the reason I want an 8x8 DCT quantization weight table from JXL is that I want to actually make a base variant of PSNR HVS that uses JXL quantization tables for its frequency weighting as a start.

jxlatte has the table dumped to a file

each orderid in full, in raster order

in single and double precision

Tests are failing again on Arch Linux (`-Wp,-D_GLIBCXX_ASSERTIONS`), like in https://github.com/libjxl/libjxl/issues/1644.

Should I open a new issue or comment on this closed issue?

new issue is best

Why does the decoder need a lot more memory when the image is encoded with noise?

Does it? That's unexpected...

The generated noise pattern is pretty heavy

I mean, 3 floats per pixel

But it's done per group, right? Not full image?

Hmm. Decoding an image in wasm without noise requires one amount of memory and with noise requires about twice? I can't say for sure, I can do more testing this weekend, but it seems to be quite a lot for some images.

I am starting to work on getting animations working so that is primary focus.

it could require 2x yeah, if the image is not very big

it's done per group but it's generated at group decode time

why does libjxl encode LF Frames for high distances but not for low distances?

high being, say, d5 as an example, and low being, say, d1

It no longer does that, actually

hm? it doesn't use LF frames anymore?

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

Not by default

It still does if you ask for it, but my testing indicated that it didn't really help for compression, so it made more sense not to change strategies at some arbitrary distance setting, to avoid discontinuities...

I was under the impression that it was not for comprsesion

but it was because high distances tend to be used because you want ultra-responsiveness

Ah, that would also make sense, but no, we originally did that because it seemed to compress better

If you encode the frame with VarDCT that makes sense

but for modular you're just skipping dequant

So is ssimulacra2 now used instead of butteraugli in libjxl for determining quality targets?

Not really, but in any case we only use butteraugli at e8 and e9, below that it was used to inform heuristics tuning but not really used directly.

Makes sense... So at e8 and e9 it DOES use butteraugli then?

Yes, to inform adaptive quantization.

I noticed e7 -> e8 has a discontinuity

where e8 is way slower than e7

there's no equivalent elsewhere

is that because of butteraugli?

No idea but someone said e8 and e9 are single threaded

e8 and e9 vardct are doing butteraugli iterations and that makes them have guetzli-like speed

I think e6 and e7 are the ones that make the most sense to actually use

Maybe e5 too

e3 and e4 come at too large a cost in compression to be worth the speed gain imo

And e8/e9 come at too large a cost in speed to be worth the small compression gain

hoh. well

today

I found the biggest bug look this image (album cover) when encoding on the parameters e5 e7 e9

and here are the comparisons of the original e3 e5 e7 e9 all on d 1

big color shift

oddly enough I don't notice anything

Wait maybe a little bit brighter on the right side

The green parts I mean

the colors are slightly different but not something noticeable at 900px viewing distance of an image of that size

the image is just spoiled, it shows something that shouldn't be there at all In case you haven't noticed, e3 works fine

I don't see that, just the color issue

yeah no that's bug territory

there are lots of green areas straight up turning red

<@794205442175402004> what do you say about this?

perhaps you didn't understand - the image is completely ruined, I can't use the format at a speed higher than 3 after that, these are critical artifacts at a NOT low compression level

maybe then you can tell me what happened to the colors of the text? Where ogirinal | e 3 | e 5

escaped

I want to note that compressed Modular e9 d1 give an almost identical result in file size and visibly quality as vardct e3 d1

interesting, might be the block selection heuristics making a bad choice?

e3 just uses 8x8 for everything

here the culprit could be using too big blocks, making the X component get a bit wonky

does e3 really use 8x8 for everything?

Yes.

does e3 make jpeg-compatible JXLs?

cause if they're all 8x8 might as well

not really, since it still uses XYB, gaborish (I think), and I don't think the quantization factors will be representable in jpeg (which requires them to be integers)

but it's pretty close to just jpeg

yea that just sounds like xyb jpegs

I'm not a developer, I'm just helping point out the average color is deviating abnormaly

I don't think e3 uses gaborish

isn't it possible to make a JPEG with an XYB color space?

Not sure if any jpeg decoder will be able to display it properly...

An image scaled down this tiny is hard to see. Most details in this image are only 1 or 2 pixels.

Lossy encoding is a bad idea for an image like that.

But I think JXL encoder has settings you can tell it that the image is going to be viewed a certain way, and it can adjust some compression settings based on that?

Or you can decrease the Distance setting, say d0.5

Although the real problem is that the image is too small

I am red-green color blind but if I look hard enough I can see there are some green areas that turn red and that's probably bug territory

But just a few pixels are hard to notice from a normal viewing distance

it already exists

look in forum, below these channels

requires icc-v4 but other than that it's a thing that exists and works

Yeah, the way xyb is used in jxl is a bit different than how it is used with an icc-v4 color profile though, not fundamentally but the scaling is a bit different to make the 3 components use the same range (needed to make it work in jpeg)

But it should be possible to make a jxl e3 style thing that corresponds exactly to something that can also be represented in jpeg

Just the current one was not made with that constraint in mind

So, is there a simple guide on how to get the tables dumped in a file? Do I increase verbosity or do I use the library differently?

Since e3 doesn't use any form of proper AQ(outside of trellis-deadzone quantization), it should be fairly trivial to get a basic JXL DCT table.

How?

e3

this is not an argument, it can't break the color, because the block size is almost the same on e3

also, I forgot to say that e4 works just as well as e3, although by my observations, some complex functions with color start with e4, but it is at e5 that everything breaks

why some distant part of the image Ruin all of the picture so much, it's an unthinkable bug

or, for example, this part with text, e3 and e5, What happened here??

and

butteraugli 1.png 1.png 0.000000 butteraugli 1.png e3.png (d 1.0) 1.463788 butteraugli 1.png e5.png (d 0.75) 1.511219

thanks for ruling out that it's the block selection

then I guess it's either gaborish or chroma from luma

what happens with `--gaborish=0` ?

cjxl --gaborish=0 ?

yes

the problem is the same, although the images are no identical

with | without

ok, good to know

then my remaining guess would be chroma from luma, but I don't think we have a switch for that

I want to note once again that this is a critical bug, and in the cases of this image, the speed of e3 is much better quality than something slower

the bug on all quality ranges from 0 to 99

I had code to generate them

and then I wrote it to stdout

now it's just an asset, and that code has been removed

Oof, I thought it was still there.

Guess I'll have to dump it myself then 🤔

why not just use the jxlatte asset?

Oh, that works as well. How do I use it?

it's just a list of IEEE floats dumped to a file

each parameter index in full, in raster order

How can I play with the DCT coefficients? I want less compression in the center of the image and more compression outward.

As someone with deuteranomaly, I literally cannot tell the difference lol.

That sort of thing is usually expected to be handled automatically by the encoder without human guidance or intervention, and there are very few image processing tools that are designed to offer that sort of manipulation and customization of the encoding process, usually those tools are not even exposed at a public-API level, but Google did recently release a progressive-JXL encoder that orders the image data in order of saliency determined by their center-of-attention AI model.

terrible -- do you have ability to recompile from source if I suggest changes?

I'll figure this out

no, I don't have such possibility, besides I use Windows. I will be able to try something only if you make a build

thank you for raising this -- please file a bug to libjxl about this

I'll debug this, try to get the fix submitted and then there will be a new windows build

well, wait build here? - https://artifacts.lucaversari.it/libjxl/libjxl/

yes, in a week or so 🙂

🛌

good news, I have a candidate fix

it relates to adaptive quantization so it will need extensive testing with photos, too

I'll need to think a bit on what is the safest way to do this fix without creating havoc in photographic density, while being more appropriate with pixel/drawing images

what kind of effect does this have on density?

I can control it

it does add bits naturally

yeah I mean in terms of effect on the BA 3-norm or ssimulacra 2 curves

I anticipate 1 % degradation in BA 3-norm

I'm working with v0.6.0 -- looks like our report generation has been broken in v0.7.0 and head

benchmark_xl ... --save_decompressed --write_html_report check-faults

Hmm is it normal for effort 9 VarDCT output to have a bigger filesize than effort 7 VarDCT? I thought the effort parameter is supposed to be like how much space should be saved. I guess that assumption only applies to modular lossless?

for lossy, it controls more the rate-distortion curve than the specific filesize

i.e. it can be expected to get bigger filesize if you also get better quality

for lossless, more effort should mean smaller files (if it doesn't, that's kind of a bug) for lossy, more effort should mean better visual consistency and better quality per byte

I see, that makes sense to me, thanks

effort 9 VarDCT hasn't been a priority to verify and it has logic mistakes -- like it really tries hard to optimize for distortion, but not rate-distortion compromise

sometimes it adds distortion without saving anything much

this is still valuable info because it means the error is in the X channel

correct. that would make sense.

X is indeed exactly the channel that is redundant for people with protanopia or deuteranopia.

(and B the one that is not visible for people with tritanopia)

"Progressive decoding for automatic low-quality image placeholders, including saliency progression to prioritize more critical parts of the image first (like face details)" Reference: https://jpegxl.io/articles/faq/#%E2%8F%A9generalinformation

How can I do that? Especially face

"There are two more advanced progressive encoding options in JPEG XL: Middle-out scans: In JPEG, scans are top to bottom. In JPEG XL, where encoding occurs in groups of 256x256 pixels, you can reorder the groups. As a result, you should start all scans with the groups in the middle, likely to contain the most exciting parts of the image. Progression of saliency: In progressive scans of JPEGs, each image part is given the same amount of detail. This is not the case for JPEG XL. That means ***you can encode images progressively based on saliency, such as encoding faces or foreground objects in more detail first, followed by the background***." Reference: https://jpegxl.io/articles/faq/#%E2%8F%A9generalinformation

Can I use the "constant quantization"

And, then why is e3 do well?

e3 is already doing everything perfectly, need to understand

Can we ask for help to review CMYK+A export in GIMP 2.99, please? https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/793 I am unsure if it is OK to call JxlEncoderSetExtraChannelBuffer after JxlEncoderAddImageFrame and if JxlPixelFormat::num_channels can have higher value than 4.

calling JxlEncoderSetExtraChannelBuffer after JxlEncoderAddImageFrame is correct

setting pixelformat num_channels to higher than 4 is not correct, it can be e.g. 3 to set CMY with JxlEncoderAddImageFrame and then 1 to set K with JxlEncoderSetExtraChannelBuffer

you can set Alpha either by giving it separately with JxlEncoderSetExtraChannelBuffer, or by setting num_channels to 4 and passing CMY+Alpha in JxlEncoderAddImageFrame

Is there a way to concatenate pre-made JPEG XL files into an animated JXL without re-encoding?

Lossy JXL?

There is no tool for that atm but it should be relatively easy to do. Just need to keep only the image header of the first, add an animation section to that header, and set `is_last` to false and `duration` to something in all frame headers

provided they all use the same parameters, it could be done, although I don't believe there's an equivalent of apngasm atm

They do need to use the same colorspace. Dimensions can be different between frames.

hello it's me again 🙂 I noticed a compression anamaly on the 98 quality for this picture, on the E 3 quality it compresses strongly, more than expected, but this is not particularly important, what is important is that the quality of E 7 gives a size 3 times larger, and E 9 gives a size 6 times larger than E 3

and also a giant anomaly of 0 quality, (from JPEG hah), which is on E 3, but which disappears on E 4 quality

This is the first time I see artifacts like this in JPEG XL

the e3 one is smaller, but also much lower quality than you targeted, its closer to d1 (or q90 iirc), e7 targeting the same quality is only 1570 bytes (e9 is 1362)

yes, but then why does e3 already smooth the surface to a flat state, erasing noise, and other parameters do not do this... after all, I exhibit one quality, - where is the stability? here I think the problem is in E 3 which smoothed out what was not necessary

I don't like this kind of artefacts, they are so unnecessary because almost no information is needed to avoid them -- and they look super irritating, especially red-green stripes in dark areas (looking at you video coding/netflix/youtube etc.)

it is caused by masking estimates being different by heuristics masking and what butteraugli considers masking

I believe e3 doesn't use adaptive quantization 🙂 ... then the inefficiencies in adaptive quantization do not come to play ... but even better to fix those inefficiencies

Well, in this case, the difference is 6 times, and butteraugli considers it a similar quality?

it could be that the dc quantization is too bad

if we made dc quantization too bad, then butteraugli gets upset and ramps up the ac quantization

could be many other things, too... would you mind filing an issue on libjxl ?

issue? where? if it's somewhere where force registration is needed, then no I can't

I think they force registration

Does this implementation already exist?

is this a fix for -e 1 or just using a higher effort for animation? https://github.com/libjxl/libjxl/pull/1982

It uses the old e1 instead of the fast one for now

because I mostly need animation for burst "merging" large lossless images, though the old efforts are also pretty fast, but higher speed still be useful

<https://github.com/libjxl/libjxl/pull/1983> adding ssimulacra2 to the benchmark would be very useful is ssimulacra2 already used in cloudinary? I wonder if it can be faster like fast ssim variations or most slowest (in overall calculations) is blur?

<:KekDog:805390049033191445> <https://github.com/libjxl/libjxl/pull/1984>

I'm using it to benchmark encoders and make recommendations on what to use, but we're not directly using it atm.

nice to see the CI in green again, that does give a better impression 🙂

btw if someone feels like taking a look at the code coverage report (https://app.codecov.io/gh/libjxl/libjxl) and do things to improve it (i.e. adding tests for code paths that aren't covered yet, or removing code that is not actually used anymore), I'm always happy to review such pull requests. It's nice if we can get a good coverage % there, even if it doesn't necessarily mean that much (you can have bad bugs with 100% code coverage and excellent software with 0% coverage).

You know ever since that guy pointed out the weird blocky color in lossy JXL now I cannot unsee it every time I use lossy JXL in any image

I notice pretty much any image is susceptible to it when you have a continuous field of relatively smooth subtly changing color, it gets turned into awkward blocks of color

But to be fair you have to zoom in a lot to see it.

Still... awkward.

It looks out of place to have some parts of the image stand out more than the rest of the image

in terms of compression artifacts

You expect the compression to be visually uniform

perceptually

Yeah, there's a lot of distracting macroblocking color distortion

in pretty much every image I use lossy compression on

the red green stuff right?

At this point, you might just be experiencing loss of dithering. That, or normal pictures are dithered, but the JXL ones aren't. I've seen what DzGas posted, but I can't really see what you're talking about.

Hmmm...

What's a good test image, I'll try to encode it with lossy and show you what I'm talking about

because like I said I can't unsee it now in every image I encode

I'm using 0.7.0 though

what I tend to see is chroma "serration" or staircasing, specially in sharps transitions into a smooth gradient.

with some luck it might be fixed with the newer patches

Yes

That's what I see

That's exactly what I'm talking about that's impossible to unsee now

Staircasing or macroblocking in the chroma

which means it has probably nothing to do with dithering or whatever blue meant

Yeah, I know. And it's in literally every lossy image I compress, too. Unless I do -q 94 or higher

Maybe try with current git version to see if it improved

interesting, could you give a link?

Yes

It's very hard to notice for me in this example because of my deuteranomalous color vision

But this is an example of it

It's more noticeable to me in other images

🙂

The same issue. Like I said I can't unsee it now. It's in every lossy image unless I use like -q 94 or higher

Someone else described it as "chroma stairstepping"

I would maybe describe it as "chroma macroblocking"

the error with colors goes up to q 99

that is, I see it on all ranges from 0 to 99

in fact, I still notice the remnants of this bug in photos with a quality lower than 85

It's unexpected since JXL is known to have extremely good color compared to other formats

since the more visible part of the bug has already been fixed, it is now much more difficult to indicate this, but I clearly noticed it in one of my test images

Is it a recent regression or has libjxl done this for a long time?

the bug always show itself exclusively on dark shades of red, which is the border to white, as well as the bug manifests itself only on large images and does not appear if you cut out the part where the bug was from the picture

I sometimes go to encode.su , you can just look at my nickname there

for example, I have such an image, it was generated by a neural network (and it is also blocked by discord), but this is not so important, important is that a bug with red blocks is extremely noticeable on it

q 80 e 7

is it really a bug if we are talking about lossy compression? I would assume there's always going to be artifacts when you are not doing lossless

in this case, it's a bug.

I showed exactly the same bug a year ago, and it was solved, but the quality of q 95

you might be right. in the above image I do see the issue clearer, unlike the album cover image. it might have something to do with my red-green color deficiency...

in this case, it turns out to be completely different problems caused by different mechanisms

let's try to improve -- I'll look into this, too

Does libjxl still call abort()?

I didn't realize it does that... That's a huge dealbreaker for using the library...

It shouldn't except when out of memory or when using the api incorrectly, I think

I was just looking at the open milestone issues

Even in those situations it's best to give the calling application the opportunity to catch and handle the error

I agree we should make it return error when out of memory.

libjxl using abort() is a blocker for paint.net having default support

When using the api incorrectly, I think it's better to abort and force the application dev to fix it.

What do libjpeg and libpng and co do when out of memory? Do they handle that nicely?

I think we need to look at our allocations more carefully, besides oom we also seem to just be doing lots of allocations, which might be causing some avoidable time spent in system calls...

Forcing the calling application to abort can have consequences like losing important work.

If you want to force the devs to fix their API usage there are other ways to fail

Api usage bugs are static bugs like trying to set the bitdepth to 123

I agree that dynamic bugs like passing an invalid jpeg file to be recompressed should return nice errors

But api usage bugs should just be fixed, if you're just calling things in incorrect ways, it's better to abort than to confuse the dev by returning errors they're likely not going to look at anyway and marching on.

Well you don't have to march on either, but there's probably a better way for libjxl to give up without forcing the calling application to abort

But why? These are basically compile-time errors that we just cannot catch at compile time...

When using a debug build of libjxl, you'll get a nice error message saying what you did wrong, and then it aborts.

yeah but that will sneak in a runtime build at some point or another

or some weird bug will

we *could* setjmp and longjmp

or do weird signal handler magic

well, no, both are a terrible idea

maybe exceptions

I think there's a difference between bugs like calling libjxl functions in the wrong order (which will be a problem every time that code path is executed) and bugs that could plausibly depend on runtime things.

For the former I think aborting is the most dev-friendly thing to do, makes it clear immediately that they need to fix their code. For the latter returning error status is better.

It's more expected that the JXL related functionality would cease to function.

rather than an abort.

i dunno, I'm kind of used to getting aborts when calling libraries in the wrong way

Excessive use of abort() call in libraries seems to be a GNU coding practice

every library that does that is doing the wrong thing

it requires anything with any kind of plugin support to run separate processes or buggy plugins take down the whole program

especially if the invalid code path is rare

(say, something like forcibly enabling lossy modular is done incorrectly)

I think it's a matter of api contracts. A library should guarantee that if the api is being used correctly (i.e. as prescribed by the documentation), it never aborts, only returns error codes that can be checked and recovered from. But if the api is being used incorrectly, then I think aborting is clearer than returning an error code that very likely will not be checked anyway, causing hard to track bugs further down the execution. If necessary, it's the application's responsibility to do the runtime checks needed to ensure it is using the api in the correct way.

If shell "uses API incorrectly" (i.e. for thumbnails, etc) in rare code paths, would it cause the whole OS shell to crash in release build?

IMO no, libraries should not abort

How does mozjpeg handle those types of errors?

I don't know, I assume in a way that's compliant with libjpeg's api

I think if other file type libraries do not crash parent process, neither should libjxl.

Has anyone built libjxl successfully on linux armhf and arm64? We couldn't get Pale Moon with JPEG-XL support built-in on those platforms: https://forum.palemoon.org/viewtopic.php?f=3&t=11466&start=700#p234135

Do note that we're using a libjxl slightly older than 0.7.0, but looking at the changes between the tree of the commit I used for the initial PR and 0.7.0, the changes doesn't seem to be significant

Yes!

Welp guess I will upgrade our in-tree libjxl to 0.7.0 and see if that works for the package maintainer

I'm not 100% sure, but let me check <:PepeOK:805388754545934396>

might have to also update highway

if it's not required it's still probably good to do anyway

<@707907827712131102>

For reference, here is what we use https://github.com/OpenMandrivaAssociation/jpeg-xl https://github.com/OpenMandrivaAssociation/qt-jpegxl-image-plugin

Looking at the changes, the only thing that seems to affect us is the addition of `hwy/per_target.cc`, but other than that it seems upgrading our in-tree highway is indeed optional

But I'm gonna upgrade it anyway cuz why not

Anyway: https://repo.palemoon.org/MoonchildProductions/UXP/pulls/2062

me and demez where thinking of doing the same with our waterfox pull request (we even had it ready) but we decided it would be a better idea to leave it out so the pull request wouldn't have a giant log of changes so it would be more likely they would merge it

Yeah, good thinking, just do the library updates in a future PR :)

If Waterfox decides to merge it in I might try porting it to SeaMonkey as well

Waterfox Classic I mean

Since they're different codebases

I said in the past that SeaMonkey is unlikely to accept libjxl support from their IRC logs, but if WC decides to go libjxl, I don't see any reason why SeaMonkey wouldn't do the same, since their developers are collaborating in keeping up-to-date with mozilla-central

the pull request we did is currently for non classic waterfox however we are definitely planning on doing one for classic at some point (hopefully soon) based on the work you have done

Yes, I should have explained more on the bug. When using a subsampled XYB JPEG, then it won't be compatible with lossless JPEG transcode, similar for RGB JPEGs. So the failure you are seeing now is exactly the intended behavior that we were trying to create in e51e0e56; this way at least cjxl is not permitted to create files that can't be read by djxl

Maybe only in debug builds with certain compile time flags enabled would it ever make sense for a library to intentionally call abort() in any circumstance whatsoever, even if the API is being used in an undefined way

But maybe if you're using a library that does that, you deserve whatever is coming to you

Still I feel like that is taking us backwards, and not bringing us into a future where computers are more reliable and less fragile

This is a perfect example. In complex piece of software there could be circumstances down a rare code path where libjxl API gets called in an incorrect order or something, it's just downright malicious for libjxl to intentionally crash the parent process in any situation.

It's just not the type of behavior a library should do, hijacking control away from the calling application like that.

It doesn't help computers get more reliable

I was touched, in a bad way, that jpeg xl only loads completely. Why? Can't I upload parts? Although by blocks? Or after loading the full Line ready for display. My question is <#848189884614705192> A little bit refers to this.

webp and jpeg just can this

JPEG XL does support reading specific groups, say, of a massive image. However, there isn't any decoder that does this at the moment.

But it could be written

it seems to me a little embarrassing that, along with all other codecs with a Block structure, suddenly Jpeg XL cannot display blocks during decoding

The format can. It's just not currently implemented by any decoder

well, Jpeg XL is still to do and do ;P

Yea, there's a lot left to do

Same is true for avif, btw.

At least libjxl can already do progressive and incremental decode

Just not cropped decode

I think only jpeg 2000 libraries may have an api to do cropped decoding

Libjpeg and libwebp don't have it afaik

it's hard for me to call it the block codec to the extent that JXL or WEBB, it has such long vector functions that can take up half of the image

in fact, at one time many years ago, I was amazed to learn that the WEBP of the video codec can be decoded block-by-line

That is why I would be interested to know the answer to my question, because progressive decoding is now the only thing that will fix this situation. https://discord.com/channels/794206087879852103/848189884614705192/1058677406199726171

https://github.com/libjxl/libjxl/pull/2012 <@853026420792360980> <@461421345302118401> I think there is some confusion here. Using xyb or not should be unrelated to being able to get the icc profile or not...

we had an earlier discussion that libjxl should be able to request pixels in a specific profile provided that it's a build that has a CMS

I don't know where that ended up going though

if so, then you could XYB-encode an image, and still request pixels in a space that the original profile describes

but that ended up not happening

Ah, no, but you could get the pixels in some space (linear sRGB probably) and then get the original profile separately

yea, the intent here is that disabling XYB would allow you to preserve weird spaces, at the cost of losing the XYB optimization

but in the case where the profile describes something relatively mundane (e.g. Adobe RGB), then you could in theory convert from linear sRGB to that space with a CMS quite easily

it would be nice if libjxl could call the CMS for you in this case since it's built-in (though not libjxl_dec)

I don't know if vardct without xyb does anything useful atm

does lossy modular outperform vardct for nonxyb?