JPEG XL

jpegli does not support lossless compression, does it not? Why are you using it for this project?

It could be using invalid jpeg files that other decoders ignore the errors for. Jpegli is a lot more strict currently for some files that work elsewhere

I've been exchanging emails with w3c's PNG spec team, and `cLLi` and `mDCv` are going to be changed to `cLLI` and `mDCV` (note difference in capitalization). The change landed in the repo already: https://w3c.github.io/png/ and will land in the published spec once it's released. For this reason I suggest that we start writing `cLLI` immediately instead of `cLLi`. Chris Blume of W3C PNG spec team said that he's adding the new chunk conventions to the next release of Chrome, and I've already sent a list to the ML to patch FFmpeg, and Mediainfo already supports both (the three known implementations of `cLLI`). I believe <@179701849576833024> you're the author of this?

I'm certainly not the author of the spec, but I'm the author of the chrome code IIRC

I meant the author of the PNG writer that writes `cLLi` chunks in libjxl

we should probably change it to write `cLLI` instead

apparently, we wrote it `cLLI` in the original PR description https://github.com/libjxl/libjxl/pull/2711

so maybe that points to that spelling being more intuitive

does anyone know jxl viewer with animation support on android

It's working. the only problem is that it completely decodes before the show. you have to wait about 5 minutes maybe someone else knows some kind ?

has anyone tried updating the pix-jxl thing to latest, maybe that would work better.

Progressively decoding animated JXLs frame by frame? Does such a program even exist yet?

ImageToolbox on Android does at least, unless it's decoding the entirety of Shrek in less than 0.2 seconds

Does ImageToolbox support animated JXL? It could just be decoding the first frame and that's it.

I didn't have to wait 5 minutes. My Pixel 8 opens and starts playing shrek.jxl within 8-10 seconds.

Editing is a single frame, but the file preview correctly animates in both the thumbnail and 'full' view, starting immediately on my 8 year old phone instead of preloading the entire file

The application is overcomplicated and not viewer specific, but it works faster

Neat, it decoded all frames without crashing or lagging.

There a new version on the way that should be faster. Do you have any images I can test for performances ?

it take only a few seconds to load oO. If you want to try it I made a pre-release, it is signed with the same key used to sign the release on izzyondroid / github.

40 seconds "pre decode" before show gamma is dead samsung j4 2018

imagetoolbox show after 2 sec wait. normal gamma the speed of your smartphone just did not allow you to see how unoptimized this playback is so this is clearly not my problem and not a smartphone problem. No matter how old is is, it was not av1 1080p cpu decode

late reply but at least in my quick dirty test, either dividing by maxval rather than multiplying with its reciprocal _or_ multiplying with the reciprocal as a double and then casting back to a float, makes an 8-bit image and an identical 16-bit image convert to the same float <https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=34bb65dc370152dcc2f27beda9f68687>

When 4x4 blocks?

When 256x256 blocks (could be useful for compressing a plain colour)

A modular patch would be better for that

probably yeah

why hasn't this been merged? https://github.com/libjxl/libjxl/pull/3905 is it because <@263300458888691714> hasn't approved it yet?

Nothing to do with me, I'm not on the dev team ...

Odd, maybe it's just being overlooked I guess

<@&803357352664891472> can this be merged? The documentation is super old, like 0.6 old

Done

Does djxl return an error code when using disable output? If so can I use that to detect if a JXL is malformed?

WebP 2.0 was not officially released. I wonder what it will do about their 4x4 square pixels prediction model that I hate (destroying image quality to accommodate smaller file savings)? <@794205442175402004> ?

If JPG XL permits to have layers, can these layers have transparency masks?

Layers can have extra channels, yes. Assuming that's what you mean

The typical way to use layers is by having an alpha channel in each layer and alpha-blending (kBlend) them on top of one another. It's not obligatory to do it that way: you can also have layers without alpha channel that are just stacked opaque layers (kReplace blend mode), which is fine if it's just a composite image consisting of non-overlapping layers; alternatively you can use kAdd or kMul blend mode which can be useful for overlapping layers without requiring an extra channel.

You can even have multiple alpha channels and do weird kinds of blending that cannot be represented as a simple chain, i.e. a linearly ordered blend stack (like how it always is in image editors), but is a more complicated DAG of dependencies between layers.

Are layers the same as multi-frame/animation?

yes, frames are either: - a layer if it has zero duration (which is the only possible duration if the image is marked as a still image and not an animation) - an animation frame if it has nonzero duration - a page if it has the maximum duration value, which is a special value

and frame blending works the same way regardless of duration. But of course doing a full-sized kReplace blend doesn't really make sense for a layered image (it makes all previous layers irrelevant) while for an animation frame or a new page this makes more sense.

Thanks. Layer support is on the long-term plans for the Paint.NET Jpeg XL plugin, but the only reference implementation of that feature I am aware of is the libjxl GIMP plugin.

I am somewhat confused by what actions are required for an app when disabling coalescing to read layers. The [documentation](<https://github.com/libjxl/libjxl/blob/main/doc/format_overview.md#frames>) appears to imply that you would need to handle cropping frames that are outside the bounds of the main image in addition to repositioning smaller frames that are offset.

I may wait to implement that feature until there are more libjxl consumers which handle layers that I can use as a reference for my implementation.

yes, when disabling coalescing you get the frames as they are, which means they can be smaller or larger than the canvas (which is also how it typically is in image editors), and which also means you need to blend them yourself if you want to show a merged image (which is something image editors can already do).

Can someone link me to a resource to help me understand how range ANS works in JPEG XL

there are lots of materials, videos, e.g. https://m.youtube.com/watch?v=RFWJM8JMXBs

I have seen that one and it is very good, I meant more specifically range ANS

https://community.wolfram.com/groups/-/m/t/3023601 do you have some specific question?

If possible can you export it as PDF? It’s crashing my web browser!

https://encode.su/threads/2078-List-of-Asymmetric-Numeral-Systems-implementations dozens of explanations

jxl uses alias mapping rANS. the idea is, first start with evenly divided range for all possible symbols, and more likely symbols "borrow" ranges from less likely symbols by creating an alias pointing from less likely to more likely (so more likely symbols have more effective ranges).

Alias trick was proposed by Fabian Giesen: https://fgiesen.wordpress.com/2014/02/18/rans-with-static-probability-distributions/

does libjxl have a roadmap?

Hi there, I would love to contribute to https://github.com/libjxl/jxl-rs in my free time. I noticed that there is a tracking issue https://github.com/libjxl/jxl-rs/issues/58 and it seems like a good point to start. How could I collaborate on this? Thank you.

other than the stages, I'm fairly close to having things ready enough for starting to implement the actual processing of modular transforms (and that whole logic will also need about a billion tests, at some point or another...) I sent you a DM 😉

Is basic image decoding functional yet? Like a VarDCT image with no restoration filters or patches

nope, we're hoping to get to that point in a month or so

what are the plans in relation to when jxl-rs gets to the optimization stage if Rust still don't have portable SMID when the time comes?

oh there's options, https://docs.rs/pulp/latest/pulp/index.html is one, and otherwise macros 🙂

That reminds me, I recently read a post from the image-rs guys about how removing manual SIMD and instead writing the Rust code in such a way that it's easy for the compiler to autovectorize, resulted in better SIMD code and better performance in general, leading to it outperforming the C PNG decoders. I'm not really an expert on this and I don't want to backseat develop this software, but, it seemed very promising, I was wondering if this approach has been considered [The post](<https://redlib.nl/r/rust/comments/1ha7uyi/memorysafe_png_decoders_now_vastly_outperform_c/>) relevant things from the post: [writing code so the compiler knows it can vectorize it](<https://matklad.github.io/2023/04/09/can-you-trust-a-compiler-to-optimize-your-code.html>) > The drawback of automatic vectorization is that it's not guaranteed to happen, but in Rust we've found that once it starts working, it tends to keep working across compiler versions with no issues. When I talked to an LLVM developer about this, they mentioned that it's easier for LLVM to vectorize Rust than C because Rust emits noalias annotations almost everywhere.

its hard to do, works some times, but compilers are finicky beasts

autovec is limited in cpu features decided at compile-time, so we need some kind of dynamic dispatch on a set of functions compiled with various cpu features (which pulp seems to support). and something like DCT doesn't get autovectorized very well so we need manual SIMD for those

yeah autovec is... limited, we're pretty far away from being able to get optimal performance out of it in a lot of very relevant cases

Would it be be preferable to write good-for-autovectorization code (like code that works on chunks of statically known sizes), see if the compiler can autovectorize it, and only do manual SIMD for cases where it can't or where the code turns out to be suboptimal? I feel like there might be some value autovectorized code over manual SIMD where possible since I imagine it's a lot easier to maintain. Or would that be like, not worth it given how rarely it actually works well

doubtful, `good-for-autovectorization` is very limited. it's really good when it works, but it hardly ever works and you almost always just fight with yourself aside from some basic stuff

yep, and vectorized code *can* be quite reasonable to maintain with good library support - not so much if you write asm or intrinsics, but IMO you shouldn't be doing too much of that if you can avoid it

just don't let whoever runs the ffmpeg twitter account hear you say that

Write the entire library in pure ASM for maximum efficiency

cjxl with argument parsing written in handcrafted AVX-512

depends on what you mean by “easier to maintain” – maintaining correctness, sure; maintaining autovectorisation, maybe not so much

I wouldn’t fancy having to periodically check that the assembly is still vectorised

I propose that in addition to lossy and lossless encoding modes, the codec should also be capable of foxy and foxless encoding.

Otherwise it will never be practical for real-world applications, in my view.

`cjxl --foxes=1`

In foxy mode, a fox nibbles up unnecessary bits to make your images lighter. Foxless mode doesn't have any foxes.

cjxl --foxes=0 👍

During JXL_DEC_BOX_NEED_MORE_OUTPUT event, can I skip further decoding of the current box (for example the decompressed data is too big) just by using JxlDecoderReleaseBoxBuffer only and not setting a new buffer?

I doubt it, but that would be a nice addition. Probably requires an extra function to do the actual skipping, I think...

Is this alias trick by Fabian Giesen the same thing as the AliasTable we have in jxl? <@179701849576833024>

If I understand correctly then the idea actually dates back to 1974? https://en.wikipedia.org/wiki/Alias_method

yep

its application to rANS was Fabian Giesen idea

I started getting this: ``` error: Scalable vectors function return values not yet supported on Darwin for function: _ZN3jxl5N_SVE14InterpolateVecEu13__SVFloat32_tPKf. Consider always_inline. fatal error: error in backend: Unsupported feature clang++: error: clang frontend command failed with exit code 70 (use -v to see invocation) Apple clang version 16.0.0 (clang-1600.0.26.4) Target: arm64-apple-darwin23.6.0 Thread model: posix ```

is highway doing cutting edge stuff again or something?

oh wait why is it using Apple clang 16 and not the clang 19 I installed with homebrew

still getting issues with clang 19 though

``` FAILED: lib/CMakeFiles/jxl_dec-obj.dir/jxl/dec_group.cc.o /opt/homebrew/Cellar/llvm/19.1.6/bin/clang++ -DFJXL_ENABLE_AVX512=0 -DJXL_INTERNAL_LIBRARY_BUILD -D__DATE__=\"redacted\" -D__TIMESTAMP__=\"redacted\" -D__TIME__=\"redacted\" -I/Users/jonsneyers/dev/libjxl -I/Users/jonsneyers/dev/libjxl/third_party/highway -I/Users/jonsneyers/dev/libjxl/third_party/brotli/c/include -isystem /Users/jonsneyers/dev/libjxl/build/lib/include -DJXL_IS_DEBUG_BUILD -fno-rtti -O2 -g -DNDEBUG -std=c++17 -arch arm64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX15.1.sdk -mmacosx-version-min=14.6 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -fmacro-prefix-map=/Users/jonsneyers/dev/libjxl=. "-DHWY_DISABLED_TARGETS=(HWY_SSSE3|HWY_AVX3|HWY_AVX3_SPR|HWY_AVX3_ZEN4|HWY_RVV)" -funwind-tables -Xclang -mrelax-all -fno-omit-frame-pointer -Wno-builtin-macro-redefined -Wall -Werror [...] -DJPEGXL_ENABLE_SKCMS=1 -DJPEGXL_ENABLE_TRANSCODE_JPEG=1 -DJPEGXL_ENABLE_BOXES=1 -MD -MT lib/CMakeFiles/jxl_dec-obj.dir/jxl/dec_group.cc.o -MF lib/CMakeFiles/jxl_dec-obj.dir/jxl/dec_group.cc.o.d -o lib/CMakeFiles/jxl_dec-obj.dir/jxl/dec_group.cc.o -c /Users/jonsneyers/dev/libjxl/lib/jxl/dec_group.cc fatal error: error in backend: Invalid size request on a scalable vector. ```

Not related to this, is it? https://github.com/libjxl/libjxl/pull/4060

ah, yep, that's the culprit

synonym for undisable: enable

re-enable, to be more exact

but now we will have to re-disable I think, at least I had to do it to get it to compile without making clang crash

Then you have to re-re-enable in the future 😄

unredisable?

Updating the highway submodule to <https://github.com/google/highway/commit/1d5cc073467fe38c79de229797e90d07ea287cf7> ought to fix that.

I thought we already did that

<@794205442175402004> did you `git submodule update`?

Yes I did but I still get clang crashes when trying to compile current git head. If I add back the disabling of `HWY_SVE|HWY_SVE2|HWY_SVE_256|HWY_SVE2_128|HWY_RVV` then it compiles fine.

I get the same thing as https://github.com/libjxl/libjxl/actions/runs/12786076550/job/35642428301?pr=4066

Unfortunately, that commit is not part of any released version of Highway. The submodule currently points to version 1.2.0 (<https://github.com/libjxl/libjxl/commit/4ba6e969025fba2b7487c1b7214af1591fb83b25>).

I suppose we can for now just copy the condition in https://github.com/google/highway/commit/1d5cc073467fe38c79de229797e90d07ea287cf7 to libjxl and then drop it again when there's a new Highway release

It looks like PR https://github.com/libjxl/libjxl/pull/4065 is going to fix this. You could also try to build with `-DJPEGXL_FORCE_SYSTEM_HWY=ON` and install Highway via Homebrew as a potential workaround (see e.g. <https://github.com/Homebrew/homebrew-core/pull/187722>).

Hi, I am here to speak about licensing 👀 about butteraugli jxl and butteraugli google I ve seen that google butter is on apache 2.0 and jxl is BSD 3 I think And I am trying to rewrite butter (mainly from google one) on GPU vapoursynth plugin in vship https://github.com/Line-fr/Vship/tree/inprogress (ongoing) I did put my code as MIT license will it be an issue? if it is, do you have the contact information of the people I should ask for permission to do this?

I observed that people who work with CMYK are confused that zero in one software means no ink (white) and full ink (black) in another software. I suggest that there is short info in headers, that in libjxl, zero is full ink and 255 no ink.

You mean for people implementing libjxl?

I mean it is useful information for people using libjxl - to know how to interpret values decoded by libjxl.

do jxl-oxide developers hang out here?

<#1065165415598272582>

this is something that is confusing in general for a lot of people, many different things have the reverse of others.

It all began with 1-bit images (black&white) where the convention was often 1=black for some reason, I guess because 1=ink, 0=no ink kind of makes sense.

For screen display, 1=light, 0=no light makes more sense though.

In the light-based models like RGB, having 0=black, 1=white makes sense.

For CMYK, if you define it as 0=ink, 1=no ink, it maybe makes less sense semantically, but it does kind of work nicely since you get the same 0=black, 1=white as in RGB, and in fact you can even misinterpret the CMY as RGB and still get a reasonable picture (it will not do proper color management of course, but it will be roughly correct since Cyan ink absorbs red light, Magenta ink absorbs green light and Yellow ink absorbs blue light).

This is also the convention used in CMYK jpegs, and a lot of software actually just shows the CMY misinterpreted as RGB.

So it seemed natural to follow the same convention. That way at least in principle the CMY channels of a CMYK jpeg can be losslessly transcoded (the K still has to be encoded as pixels though).

While investigating why my lossily compressed float images with float extra channels become significantly larger than expected, I noticed some potentially problematic code in method ModularFrameEncoder::ComputeEncodingData(), file enc_modular.cc at line 924: ```cpp for (size_t i = 0; i < extra_channels.size(); i++) { int ec_bitdepth = metadata.extra_channel_info[i].bit_depth.bits_per_sample; pixel_type ec_maxval = ec_bitdepth < 32 ? (1u << ec_bitdepth) - 1 : 0; bitdepth_correction = ec_maxval / 255.f; float dist = 0; if (i < cparams_.ec_distance.size()) dist = cparams_.ec_distance[i]; if (dist < 0) dist = cparams_.butteraugli_distance; quantizers.push_back(quantizer * dist * bitdepth_correction); } ``` I find this behavior suspicious because the value of ec_distance is effectively ignored (multiplied by zero) if the extra channel is float. Since ec_distance is set by JxlEncoderSetExtraChannelDistance, it should be relevant to my use case. This function is also relevant because it is called for my float images with extra channels, but not for my float images without extra channels. Interestingly, I observed that lossy float images with uint8 or uint16 extra channels have sizes proportional to their components, as expected. However, when I hard-code bitdepth_correction to 0 in this function, their sizes increase to a level similar to images with float extra channels. Could you clarify whether this behavior is intentional or if it might indicate an issue with how ec_distance is applied to float extra channels?

Good question. The lossy approach for extra channels kind of assumes integer data; applying it to float data probably would behave a bit weirdly (though maybe it would kinda work), which I guess is why that code does something weird

I get results like this with float extra channel: Image alone (lossy): 32 169 bytes, extra channel alone (lossy): 36 080 bytes, Image plus extra channel (both lossy): 715 466 bytes. In this example, the extra channel would have been 511 935 bytes if compressed losslessly, so it looks like the extra channel has been expanded, not compressed.

I would've assumed it's doing the same as `cjxl -m 1 -d 1` on the float data. What's the source of your float images? Is it lower bitdepth scaled up by any chance?

The images are photos I have shot, exported as jxl from Lightroom classic. In the last example, they were exported as lossless jxls, with small dimensions (512x384). The sizes I quote, were determined by saving the component files from the same program that created the composite. The extra channel was created by extracting the green channel from an image with the same dimensions as the main image. The photos were stored as raw files, i.e. 16 bits, and exported as jxl 16 bits. Lightroom does not have an option to save as float.

So 16-bit ints converted to float? I always think of this whenever floats and density is involved, but it might be worth checking if they're float16 or float32 being fed to libjxl https://github.com/libjxl/libjxl/issues/3511 (I forgot this is <#848189884614705192> so slowmode is enabled)

They were converted to float in my program by DecodeJpegXlOneShot() from the test programs I've now submitted a bug report about float extra channel problem: https://github.com/libjxl/libjxl/issues/4082

What happens if a modular predictor predicts a value outside of the bounds of the channel's bitdepth? Does it wrap around? Does it clip? What happens to the next pixel?

(As far as I can tell) None of the predictors can go above existing pixel values, that's where the MA tree comes in

Since it inherits whatever C++ does, unsigned integer arithmetic overflow is wrapping, and reversible: ```rust #[allow(overflowing_literals)] fn main() { let mut px: u8 = 70; let delta: u8 = 1000; // prediction outside unsigned 8-bit range println!("pre-prediction: {px}"); px -= delta; println!("post-prediction: {px}"); px += delta; println!("reconstructed: {px}"); } ``` ``` pre-prediction: 70 post-prediction: 94 reconstructed: 70 ``` (code is rust, but it handles arithmetic overflow the same as c++, this is just for demonstration) I didn't see any code that attempts to detect overflows in the predictors, but I don't know anything about what it does regarding this in MA trees like jonny mentioned.

Note that I am not a jxl dev, I just know predictor arithmetic is C++ arithmetic from looking at the code

no, as in goes outside the bounds of the *pixel's* max and min. The modular arithmatic is handled using 32 bit integers, even if the frame is only 8 bits

Oh, I didn't know that 👀 That explains why some of the more complex predictors internally overflowing isn't an issue. I think what jonny said about predictors never evaluating to something larger than the inputs is right, like things are averaged or clamped to the max value of the observed values (but I didn't check the self-correcting predictor) so it shouldn't occur

```c // Clamps gradient to the min/max of n, w (and l, implicitly). static JXL_INLINE int32_t ClampedGradient(const int32_t n, const int32_t w, const int32_t l) { const int32_t m = std::min(n, w); const int32_t M = std::max(n, w); // The end result of this operation doesn't overflow or underflow if the // result is between m and M, but the intermediate value may overflow, so we // do the intermediate operations in uint32_t and check later if we had an // overflow or underflow condition comparing m, M and l directly. // grad = M + m - l = n + w - l const int32_t grad = static_cast<int32_t>(static_cast<uint32_t>(n) + static_cast<uint32_t>(w) - static_cast<uint32_t>(l)); // We use two sets of ternary operators to force the evaluation of them in // any case, allowing the compiler to avoid branches and use cmovl/cmovg in // x86. const int32_t grad_clamp_M = (l < m) ? M : grad; return (l > M) ? m : grad_clamp_M; } ``` <https://github.com/libjxl/libjxl/blob/main/lib/jxl/modular/encoding/context_predict.h>

Also note that sample values are allowed to be outside the nominal range, e.g. 8-bit is nominally [0,255] but if you want to have negative values or values > 255, this is allowed. You can expect decoders to clamp it to the nominal range when representing the image in a uint buffer, but only at the end. So you can have layers with negative samples (or even negative alpha) and they do not get clamped before blending, etc.

so it only wraps at the 32 bit integer limit? or is that undefined behaviour

It's not a conforming bitstream if it overflows int32_t (in the sample values or in any intermediate modular buffer; though predictors like (W+N)/2 have to be computed without overflow in their arithmetic). If the header field modular_16_bit is true, then it is not a conforming bitstream if it overflows int16_t.

so things like `(W+N)/2` have to be done either in 64 bit, or something like ```W>>1+N>>1+(W&N)&1``` to stay within int32_t ?

Yes, local arithmetic has to be done to avoid overflow in intermediate results (assuming inputs fit in int32), but any values stored in buffers can be assumed to fit in int32 / int16 (if it doesn't, it's a non-conforming bitstream so decoder behavior is undefined).

it just predicts it outside of the bounds. modular allows you to have negative, etc. values. modular is specified as an array of integers

clamping is done on render, not on decode

I wouldn't be so sure. Better to ask Jyrki and _wb_ directly.

Btw, while I think butteraugli "sees" sRGB-tagged images as Gamma 2.2 (and Gamma 2.2 tagged images generally incorrectly), this doesn't seem to apply to ssimulacra2.

at least there is no concencus on how to decode sRGB (or even encode for that matter) images so that is at least not too bad

If you encode using gamma 2.2 and tag as sRGB anyway, it's actually an improvement. But this error, if it exists, and if it is of the nature I assumed, should affect everything, any transfer curve.

Hi, I'm an Ubuntu Desktop Developer. We would like to include JPEG XL in Ubuntu 25.04 but this is blocked on finishing a review from the Ubuntu Security Team. Could someone look into https://github.com/libjxl/libjxl/pull/4111 ?

pinged this to someone that can probably give it a look soon!

looks like it's been merged today.

Is there a way to take a container-encoded JPEG XL and get the raw codestream from it?

I made a python script that does exactly that (and can also pack a codestream back into a container)... it's not public yet but I'll put it on github soon-ish if it's any use to people. I'm not aware of any other tool that does it.

Nice, I was thinking about writing one too 😅. Would you send it to me now?

Yeah, let me tidy it up a little bit...

https://github.com/alistair7/boxcutter There you go. It's way more complicated than you need, but it should do the trick. ``` $ ./boxcutter.py list fog.jxl seq off len type ---------------------- [0] 0x000 12 JXL [1] 0x00c 20 ftyp [2] 0x020 269 jxlp [3] 0x12d 146 brob : Compressed Exif box. [4] 0x1bf 696 brob : Compressed xml box. [5] 0x477 2117651 jxlp $ ./boxcutter.py extract-jxl-codestream fog.jxl fog-raw.jxl $ ls -l fog*.jxl -rw------- 1 al al 2118794 Mar 20 2023 fog.jxl -rw-rw-r-- 1 al al 2117896 Mar 13 21:25 fog-raw.jxl ```

Thanks! Is that something that devs want in a main tool, like cjxl? I can submit a PR

It probably belongs in the mythical jxltran utility 🙂 https://github.com/libjxl/libjxl/issues/871

Metadata remains one of the pain points for me, I have dozens of TIFFs with extensive metadata which does not stay the same when the conversion to JXL takes place. Even if exiftool is used to copy over metadata afterwards Which is a real shame, since there are massive savings to be had. One 3.9GB File was reduced to 2.5GB at e2. I would have used e7, but the difference in opening the file at e7 is 20-30 seconds longer than with e2

I can give that a shot 🤔

They'd probably want a C++ implementation for the official tool rather than [my questionable] python. I'm intending to add a few more container-level features to the script, but I hope jxltran will make it redundant.

Sure, I was thinking of doing that in C++ too

What kind of metadata? It's surprising that even exiftool, the holy grail of metadata hacking, isn't up to the task.

You could always just make up a new box to stuff it all in

Just use xml

no use RON <:Stonks:806137886726553651> edit: oops this is the contact-devs channel, sorry for meming

kdl [av1_chad](https://cdn.discordapp.com/emojis/862625638238257183.webp?size=48&name=av1_chad)

Could someone double check I'm giving the right information with regards to jpegli's API version? There's no documentation anywhere and [the repo](<https://github.com/google/jpegli?tab=readme-ov-file#usage>) says it's only compatible with `so.62.3.0` https://github.com/RawTherapee/RawTherapee/issues/7125#issuecomment-2745395327

I'm... *Pretty* sure libjpegli can do `so.8.3.2`, right?

It's a compile flag which libjpeg API to use.

Yep

Would you mind leaving a comment on the [RawTherapee issue](<https://github.com/RawTherapee/RawTherapee/issues/7125#issuecomment-2745404354>)? They seem to think it's only a version number change and not an actual API change. Without documentation they have no reason to believe me

Major version number changes in libraries are generally a sign of breaking API changes

could you maybe link to https://github.com/google/jpegli/blob/bc19ca2393f79bfe0a4a9518f77e4ad33ce1ab7a/lib/jpegli/decode.h#L75-L77 as evidence that the variable is used to control what API jpegli exposes?

(+ https://github.com/google/jpegli/blob/bc19ca2393f79bfe0a4a9518f77e4ad33ce1ab7a/lib/jpegli.cmake#L19-L25 for the connection from the variable you mentioned to the one that is used in that header)

Linked to both, hopefully they don't just say 'that's just changing the version number' again. Thanks for the help

Still nope

oh god is this about system compiled libs 😭. literally one of the main reasons I hate trying to work with a lot of Linux projects is because a bunch of them rely on system provided libs rather then self bundling/compiling them which means that if something needs to be changed in one of them then there is just no solution and you are screwed.

“as previously stated”, but back when they stated that, they appeared unaware that it could be configured for a different API version at all

The issue is about replacing libjpeg-turbo with libjpegli in RawTherapee for higher decode quality using int16/float32 decoding (It allows decent exposure adjustment without RAWs). I pointed out they already build libjxl and libjpegli is a drop-in replacement, so it should be simple. They then said the Turbo API is SO 8 not 6, so it's incompatible. I told them how to set jpegli to 8 using the cmake header, but they said that's just changing the version number, not the API. So then I linked to the API being changed, but they still say it's incompatible until I show them a Linux system using the swapped library... I'm on Windows 10 and have never touched Linux in my life, hence asking for help here. I suppose I could link to [this](<https://github.com/libvips/libvips/discussions/4177#discussioncomment-10810561>) but I think they'd take an actual developer's word over my 7th link in the past 2 days...

I think they mean when they tried with it set to the SO 6 API, and still don't believe the cmake flag changes it... Maybe they think those commits automatically change API version based on the replaced library, or handle both versions at once or something? (5 minute slow mode my beloved)

ah, right, I’m immune

<@877735395020927046> I assume that's you? Could you clarify what you mean? (Maybe move to <#805176455658733570> for longer discussion) Hmm, last message here was 2021, so maybe not...

might be them idk 🤷. I will say though that account isn't dead because it was last active at-least 3 days ago

I only just realised why you said that. So long as it's `SO.8.x.x` the API should be compatible regardless of other version numbers. I'll try and explain that with a link to the libVIPS example, but I feel like I'm talking to a rock

[Hmm](<https://github.com/RawTherapee/RawTherapee/issues/7125#issuecomment-2746670684>)

It can be used as a drop-in replacement either by compiling it with the correct API version at compile time or by source code changes (replacing `jpeg_` prefix with `jpegli_` in the API)

Wait huh?! This is dumb, the libjpeg api version needs to be set too even for the new `jpegli_` api for some reason...

It only needs to be here in this file https://github.com/google/jpegli/blob/main/lib/jpegli/libjpeg_wrapper.cc

libjpegli would have to get rid of those conditionals in the `jpegli_` namespace and expose all of the v8 functionality so software like rawtherapee can switch over by just find/replace `jpeg_` with `jpegli_` and use either a static or dynamic linked jpegli. Also the wrapper would have to expose the jpeg12 API for libtiff/rawtherapee and a bunch of other software to work with the 12 bit api.

Hey, two days ago, I made a [PR](https://github.com/libjxl/libjxl/pull/4161) for `libjxl`. How can I get it reviewed?

wait

I will take a look later today

Thanks!

This is great and I'll try to put some work into it too

Thanks, I'm really going steps by steps on this one

I wonder, how would I turn an ssimulacra2 score into a distance score? I assume a piece-wise function is needed, as scores beyond transparency behave differently? Asking here in case this was already done somewhere, or such a relationship was considered in the design of ssimulacra2.

Mapping ssimu2 to JND units you mean?

Not sure in this context... I was thinking of butteraugli-style distance values, the distance relative to reference distance at which the error in an image becomes imperceptible. What I'm looking for is basically, a rough formula to predict Butteraugl (3-norm I guess) distance scores from ssimulacra2 scores.

Maybe check the data at https://discord.com/channels/794206087879852103/803645746661425173/1067108316221816962 or generate some data based on <https://cloudinary.com/labs/cid22>. Predicting precisely per-image seems impossible, but you could correlate ranges of scores.

the goal of ssimulacra2 is to roughly match jpeg quality so you could use the same function used to map q2d. but this isn't guaranteed to actually work, you may need to tweak it. ```c static float quality_to_distance(float quality) { if (quality >= 100.0) return 0.0; else if (quality >= 90.0) return (100.0 - quality) * 0.10; else if (quality >= 30.0) return 0.1 + (100.0 - quality) * 0.09; else if (quality > 0.0) return 15.0 + (59.0 * quality - 4350.0) * quality / 9000.0; else return 15.0; } ```

Since ssimulacra2 can have wildly negative values for uncorrelated images this isn't perfect. but a start

Hi there. Do you have some pointers as to how to use the chunked API ? I couldn't make it work so far :/ Is there an available example I can use ?

Because right now I'm just chunking the image manually and making 4x4 smaller jxl files, that I have to then decompress and recombine when I want to use them.

I swear it's not an april fool's joke =_=

https://github.com/libjxl/libjxl/blob/0c1aba1d51ed32f61be4de638f075f2b199082d0/lib/extras/enc/jxl.cc#L368 maybe this helps?

Small bump for <https://github.com/libjxl/libjxl/pull/4165>

Thanks to that I noticed I had swapped two arguments, (channels and offset) which of course broke everything, it now works ! I will check if the amount of chunking satisfies the memory requirements of the raspi 🙂 great stuff!

Is your chunked frame code open-source? I have previously attempted to use the chunked frame API, but I was never able to figure out the offset system.

It's not online, it's just a POC for me, but I can give you what I have

From what I've understood, the `*row_offset = width*bytesPerPixel` , so with 3 channels in 16bits, it's `width*6` Similarly, when computing the offset in the callback, you have to be careful to count the bytes per pixel instead of the number of pixels `offset = image.data() + ypos*width*bytesPerPixel + xpos*bytesPerPixel;` the `*row_offset` doesn't change if your image doesn't have some exotic configurations

parameter comments + https://clang.llvm.org/extra/clang-tidy/checks/bugprone/argument-comment.html can help find such issues

Good to keep in mind, thanks 🙂

What's does the underscore indicate, for example `cparams_.IsLossless()` and `cparams.IsLossless()`?

a private class member

https://google.github.io/styleguide/cppguide.html#Variable_Names

Would there be any downsides to making the default group ordering be middle out instead of "top down" in libjxl when encoding? In most images wouldn't the center of attention be closer to the middle rather then the top left so why should the default be the top left then?

Not sure how that would work for streaming input

Not to mention buffering has already broken progressive https://github.com/libjxl/libjxl/issues/3823

How significant is the issue of JPEG XL decoding speed? How much does it affect the adoption of the format? **Has anyone conducted such research? ** - I am concerned by the fact that instead of transitioning to new formats, there is a continuous improvement of old ones. The problems with the transition to AVIF and AV1 are undoubtedly directly related to performance, just as Google's rejection of AVIF in YouTube video previews and the use of JPEG previews in images.google.com - I also noticed that there are practically no tests of decoding speed, because, as I understand it, this question was never on the agenda, After all, it is quite expected that time goes by, and technology too. But this time has passed. - Looking at the actual difference in JPEG XL decoding speed, I could conclude that the update to it is not happening solely because it is much faster to transmit 5 times more JPEG information, which will instantly open on a smartphone, than the speed of waiting for decoding jxl on the same smartphone. This undoubtedly gives a complete advantage to WebP and JPEG. -- And it also kills my hope for the future, because no one is making competitors for these formats, everyone is making "codecs of the future"

Have you tried --faster_decoding? Especially for lossless

I've done some benchmarks here https://discord.com/channels/794206087879852103/1358733203619319858 (lossless) and here https://discord.com/channels/794206087879852103/803645746661425173/1321342478376505365 (lossless & lossy). Lossy JXL is quite fast, on my machine it's just as fast as AVIF if not faster. And with faster_decoding, it blows AVIF out of the water, so I don't think decoding speed is the main issue here.

high resolution images on the web won't be lossless

unless you have a gallery

I think that fast-decode gives a ridiculous difference of tens of percent, when it is necessary to do it several times for lossy. the problem with losseles is a separate problem, and I think that the problem with lossy is much more important Thanks for your answers, but in the developers' chat I would like to get a big answer from the developers

how are you generating and decoding the image? those numbers look super off

because decoding in 1 thread for all - in fact, i measured not the speed, but how much more complex the different codes in the decoding device really are. and yes, in the time (amount of power) it takes to decode jpeg xl, you can decode 26 times more jpeg pixels - it is important to see that uncompressed data takes even longer to decode, because such delays in reading from the disk and subsequent movement in memory - I was surprised by bmp myself. but that's what we have, maybe the decoder is very bad, maybe haven't update it for 30 years

even when using 1 core, these numbers are still wild. whats the cmdline used to decode and encode the image? jxl is for sure on the slower side, but these numbers are way out there

here we are getting close to my original question: where are the real big objective tests and resersch? i did this for myself, to roughly understand what is what. One thread, one computer, one set of pictures, I "think" 100 random pictures in folder. and the total decoding speed of everything is divided by their number. i used ffmpeg for everything. i did the tests half a year ago and i didn't save any keys of it

Personally has an ex developer of various programs and websites (I hardly do much coding any more), why I would or wouldn't choose jxl would depend on the clientele, but I have yet to find a case where decode speed has played a significant issue, aside from video editing, which is served perfectly fine with faster decoding. everyone has likely done their own testing, personally I found that jxl trounced avif in terms of decode speed on a set of 20k images when decoded on my phone by nearly 20% speed, 10% battery life and temperatures were far better with jxl when doing a purely sequential test loop. But it's really hard to comment on the numbers you got when you haven't provided an even basic replication case. I also didn't bother limiting cores since that's just not applicable to my use case. EDIT: for context on speed. I have an older, and slightly low ram/cpu powered LG G7 thinq (SDM845 4G ram), primarily use JXL for image storage, 16gb worth, and have no issues with decode speed, and using a gallery app is far faster then when I had tested with avif, both were at the time using a sample size of 10k images

I'm doing some benchmarking of my own following dzgas's settings in ffmpeg, and I am getting numbers nowhere near what is shown here. JXL is around 3-5x slower than JPEG, not 26x slower. Also I normalized for filesize, so JXL is achieving much higher quality than a simple progressive 420 JPEG.

It will depend on the specific CPU too. But something like 5x slower than JPEG seems reasonable (for lossy jxl). Using 8 cores, jxl is probably about as fast as jpeg decoding. Using more cores it can in principle be faster.

But then the issue is if you’re doing a batch convert job JXL would take longer as JPEG you can do one on each thread but JXL you can either do one image on multiple threads but you then have less concurrency or you could give each process a single thread but now it takes 5x as long

Yes, better compression does come at a cost in CPU. Then again jpeg is super fast on current machines, it was designed for the 1990s...

decode 8 times slower when encoding -e 7 - in single-threaded comparison. I probably did the initial tests on -9. - I don't have the opportunity to check this again now, because 24 GB of RAM is still not enough to encode a jpeg xl -e 9 picture of 12k x 12k on which I do the new tests, since it is more convenient than having scripts and folders with pictures

I know on Jon's Mac the gradient predictor is significantly faster than on my AMD system, so that could be slowing down lossy somewhat

is there any JXL mode that is as fast as JPEG with better compression?

VarDCT e3 gets close to just JPEG. But it still does XYB and uses ANS entropy coding. It could be sped up by doing YCbCr with Huffman instead — at which point it basically just becomes JPEG with somewhat better compression.

i'm thinking like how there would be parts of JPEG XL that lend themselves better to SIMDing

Are there better alternatives for YCbCr that have the same computational complexity coming from R'G'B'? Are there good options in-between YCbCr and all those expensive perceptually uniform colorspaces where you have to go through LMS first?

imo YCoCg is at least as good as YCbCr and it has the advantage of not needing any multiplications and being reversible so also suitable for lossless. But in jxl you cannot really do anything except XYB and YCbCr when using VarDCT.

yeah... btw, might faster lower precision R'G'B' <-> XYB be feasible? maybe even using a high precision 3D LUT? Would need to be precomputed at compile-time though to be faster, so couldn't support everything. When doing directly between R'G'B' <-> XYB anyway. Also not good for memory consumption.

Why 1 when any smartphone have 8. 24 Gb ram enough for 12k x 12k lossless, for LOSSY use effort 7 varDCT

any devs who could answer this, it'd be much appreciated. As far as I understand, the way BD-rate is currently measured in an image dataset is: 1. Aggregate size and metrics from each image in the dataset for a lossy encoder 2. Create RD curves from aggregate image data 3. Compute BD-rate on the final curves To me this feels like treating the dataset as if it were one large image. I don't know how good or bad that is, but an alternative approach could be: 1. Build RD curves for each image in a dataset individually, and compute BD-rate 2. Create a running list of the BD-rate for each image 3. Compute a final average BD-rate by averaging the BD-rates in your list

An example on the CID22 Validation Set with `cjxl -e 6`, avif (aom 3.12.1) speed 8, and libwebp m6: Final Overall BD-rate (commonly used method): ``` libwebp vs libjxl: Final Overall SSIMULACRA2 BD-rate: -12.301 Final Overall Butteraugli BD-rate (3-norm, 80 nits): -11.511 Final Overall Butteraugli BD-rate (3-norm, 203 nits): -13.522 libavif vs libjxl: Final Overall SSIMULACRA2 BD-rate: 4.904 Final Overall Butteraugli BD-rate (3-norm, 80 nits): -0.826 Final Overall Butteraugli BD-rate (3-norm, 203 nits): -2.415 jpegli vs libjxl: Final Overall SSIMULACRA2 BD-rate: -29.672 Final Overall Butteraugli BD-rate (3-norm, 80 nits): -25.973 Final Overall Butteraugli BD-rate (3-norm, 203 nits): -26.462 ``` Average BD-rate: ``` libwebp vs libjxl: Mean SSIMULACRA2 BD-rate: -5.816 Mean Butteraugli BD-rate (3-norm, 80 nits): -0.901 Mean Butteraugli BD-rate (3-norm, 203 nits): -3.059 libavif vs libjxl: Mean SSIMULACRA2 BD-rate: 12.095 Mean Butteraugli BD-rate (3-norm, 80 nits): 6.942 Mean Butteraugli BD-rate (3-norm, 203 nits): 5.383 jpegli vs libjxl: Mean SSIMULACRA2 BD-rate: -29.410 Mean Butteraugli BD-rate (3-norm, 80 nits): -24.637 Mean Butteraugli BD-rate (3-norm, 203 nits): -25.289 ``` To me, it seems like average BD-rate is probably more representative of how good the encoder is most of the time; not sure though

I think BD-rate is not a great way to compare encoders, see also https://arxiv.org/abs/2401.04039 and https://cloudinary.com/blog/contemplating-codec-comparisons

BD-rate can be OK if three conditions hold (that rarely hold in the way it is often used in practice): - The metric actually correlates strongly with subjective quality and does not suffer from codec bias - The overlap in distortion range covered by the various codecs and source images corresponds to the range of interest - The metric scores are on a scale that has equal spacing for equal jumps in visual quality (e.g., not like most metrics that have a saturating behavior where e.g. the jump from ssim=0.8 to ssim=0.9 can be visually about equivalent to the jump from ssim=0.96 to ssim=0.98)

I think a better way to do it, instead of integrating over the curve, is to just compute the bitrate gain per-image at a few quality points of interest (say ssimu2=50, 70, 85) and report the average and stdev of that (aggregated over various source images). Then additionally it can be interesting to consider encoder consistency: ideally you don't just want an encoder to have good curves, you also want an encoder setting to produce reliable results, i.e. the same setting shouldn't produce a great image for one source image and a crappy one for another (that would be poor consistency). One way to look at that is to plot curves where every point is an encoder setting, the bitrate is computed as the total corpus size / total pixels, and the metric score is not the average but the p10 or p5 or whatever worst score in the corpus. That plot then basically corresponds to "if I would encode the whole corpus with that setting, how good would the overall compression be and what is the worst-case quality I will get" — which I think is the question that really matters in most use cases. If you're aiming at a certain quality target, it's not because some images will have a much better quality than your target that it becomes OK if some other images look like crap.

That’s super interesting, and makes a lot of sense … in particular, the method of picking a couple of quality points and computing avg +stddev bitrate gain is very interesting

what is everyone's favorite image dataset? I particularly like Daala's subset1 and subset2, as well as the Kodak Lossless True Color Image Suite even though its lower resolution and smaller

I think CID22 is very good

all of these are quite small images, "web resolution" rather than "camera resolution". Which is fine, but it's a bit different from images like https://imagecompression.info/test_images/ where there is photon noise and the higher resolution makes the characteristics at the pixel level a bit different than what you get in downscaled images.

the newer, with more variety and respecting modern requirements from codecs, the better better if it's a completely unknown, recently created one the older and better known, the worse it is, because most encoders are very hard tuning and achieve the best results for the most popular datasets it's sort of the same as for metrics, if a metric is popular, then the results of a certain encoder improve the tuning for that metric and basically the results automatically become worse, more synthetically inflated than honest and this is even more important in the current AI world, where known datasets are basically useless

The best image dataset is created by taking a modern camera and shooting some new pictures in RAW, processing them in a "typical" way, and storing the result in 16-bit RGB. Completely new images will ensure they weren't used in encoder tuning.

and also as the much-quoted <https://en.wikipedia.org/wiki/Goodhart%27s_law>

do higher resolution images benefit more from noise synthesis?

What mostly matters is relative viewing distance, rather than resolution... For most purposes, small images are fine I think. But yes, downscaling can change the nature of images... for which cropping instead of scaling could also be an option.

for subjective testing, I'd even argue that small images are better than large ones, to reduce the influence of saliency. But you need both crops and downscales, not just one or the other, imo.

That's a good one. I didn't know this idea had a name.

Does Daala’s subset1 fall into a similar category here?

Yes, they are downscales from large jpegs

What the fuck is BD-rate

Bjøntegard Delta computed along (bit)rate on a Bitrate/Distortion plot, i.e. the so-called "average bitrate savings". You can also look at BD-[metric], e.g. BD-PSNR which is the aggregated change in metric score.

~~Blu-ray Disc rate~~

Big Data rate

How do you measure consistency for an image codec's performance? I'd probably pick a quality level, measure SSIMU2 scores, and then compute std dev, but is that really the best way to do it?

video sequences :D

For video, ssimu2 does not really measure quality that well since in video there is motion masking or however they call it (in fast-moving scenes it is harder to see artifacts than in slow/static scenes) and ssimu2 does not take that into account at all

For still images, most metrics including ssimu2 are not super consistent themselves, that is the scale of the scores is a bit dependent on the image content so for one image you may have 1 JND at ssimu2=80 while for another it may be at 75 or at 85

Hi _wb\_, Lyra and myself were wondering if an SSIMULACRA2 distortion map would be possible we were theorizing this idea instead of applying weights to the aggregated 128 scores, we could apply them locally for each pixel for each scale, and then combine scales by upscaling

yes this would be possible, though the maps are aggregated with the 1-norm and 4-norm so you'd probably need to include both weights

also there are 3 different error maps that you could map to RGB channels of the distortion map instead of aggregating them into a single value

I never got around to doing this but it would be interesting to add an option to the tool to produce such a distortion heatmap

PNG reacting?? https://www.programmax.net/articles/png-is-back/

still no associated alpha smh

We've been discussing it in <#805176455658733570>

Just a spec adding features that many softwares are already using for PNG

Can djxl understand image using effort 9 (chunks?) or effort 10 in lossless? Or see metadata, without decoding?

djxl can decode any valid jxl file, or at least if it doesn't then that's a bug

for metadata without decode, you can use `jxlinfo`

I've been working on a small standalone implementation of the ssimulacra2 metric without dependencies on JXL code, or any other third party library (libhwy or liblcms2). The goal was to keep it small and easy to build on any environment. It's currently under 1000 lines of code. Performance is much lower than the official implementation, but this is acceptable for my use case. I may spend some time adding some most critical optimizations, but before doing that I'd like to understand better how the "RecursiveGaussian" is implemented, in particular the derivation of the mul_in, mul_prev, and mul_prev2 factors. The code seems to reference some external formulas, is there a paper or documentation explaining these terms and their motivation?

I didn't implement that function, I just used it and assumed it does an approximate gaussian blurring.

If you don't rely on a CMS library, are you then assuming input is in a fixed colorspace?

Weirdly enough, on my hardware it seems like the libjxl ssimu2 is slower than vszip (vapoursynth zig plugin having ssimu2 with a real gaussian blur) by quite a lot And yet, it seems like using a true gaussian blur leads to better mos correlation. So I was wondering where the problem would be, especially since my cpu does support AVX instructions. How would the less accurate approx version be slower. (Ryzen 7900x, non overclocked DDR5 3600Mhz, about 13 fps on jxl and 23 fps vszip) It doesnt really bother me much since I use the gpu version to get around 413 fps now

VSZIP (CPU) and VSHIP (GPU) are optimized for videos as you know. `libjxl ssimulacra2` doesn't even have the concept of "FPS". You call it externally over different images (including converting the frames to images before). So, huge bottlenecks apply. And for images; no external implementations are faster than libjxl ssimu2/butter as far as I can tell.

well, ssimu2rs can be faster on some images due to the image crate being good, :D

That reminds me, libjxl isn't using zlib-ng for PNG decoding. When me and <@207980494892040194> tested it, encode wall time was 30% faster with less CPU time for a 200 MP PNG

also helps PNG encoding as well when using djxl and such

Oh ssimu2rs is less accurate. VSHIP on the other hand can even have better MOS correlation. And the native binary can work on different image types and extensions as a bonus 🙂

is it? I found ssimu2rs to more or less be within margin of error. but yeah, more images more better :D

Accuracy of different implem

Especially you get a different result when you need to convert the images. jxl ssimu2 can directly work on jxl images for example. So if you want to stay in line; it's better to use the native one unless you test videos. And for that; the beloved FFVship from Lumen is unbeatable in the near future (I get around 500 FPS speed). And it's also accurate with true gaus blur.

Yes, input is expected to be in sRGB or linear RGB color space. Users are free to do color transform on their end. So, this keeps things simpler and is enough for my needs.

Makes sense. Probably need to have a way to deal with HDR though, but that probably needs some calibration anyway. Ssimu2 works well for HDR but the scale is not quite the same as for SDR, the scores are lower for the same JND value in similarish viewing conditions.

Ah, thans, I'll dig into the libjxl git history to find where that came from and see if I can find some reference to the source material.

I haven't looked into using it for HDR data yet, but I think the same strategy of assuming a specific color space and offloading the color transform responsibility to the user should work also.

Ah, looks like the code refers to: "Recursive Implementation of the Gaussian Filter Using Truncated Cosine Functions" I had stripped that comment while pulling the code out from libjxl. However, git history does not reveal the original author (it was commited by jxl-bot). Do you recall who did that work?

iirc most old commits from "jxl-bot" are ones that where transferred from this repo: https://gitlab.com/wg1/jpeg-xl

The commit on that repo is the same: https://gitlab.com/wg1/jpeg-xl/-/commit/50bbf27d90ca938a5ab8818b870c7f238380708e?page=2

The paper is actually quite readable. The idea appears to be very similar to the "sliding window" or "moving averages" approach to implement a box filter, but using 3 or 5 terms instead of one. Very neat. I'd love to know who contributed that code.

Uh, that commit would be in the private repo where we initially did development because for some reason JPEG wanted it to stay private initially (I think to allow in theory that people could contribute stuff they didn't want to open source or something)

Perhaps someone who is good at git magic should try to get that commit history imported into the main libjxl repo so it has a full git history. That would be useful to figure out who wrote what, because at this point even the person who did might no longer remember that they did 🙂

When I find some time I'll compare the recursive sliding filter against the regular convolution. I'm curious to see how much faster it is and whether it's worth the additional complexity. It looks like the kernel footprint is just 5, so it may not be that much faster. I'll report what I find!

jpeg xl does not support PSRN or SSIM encoding, replacing Butteraugli?

libjxl has a mode to disable perceptual optimization but it disables everything, also XYB.

Is psnr in xyb implemented?

JPEGLI has it, at least in the code

I'm interested if anyone could encode jpeg xl using something other than Butteraugli

Well libjxl only really uses butteraugli at effort 8+

cjxl --ugly-mode --tune=psnr in.png ugly.jxl

this slightly contradicts all my knowledge about jpeg xl

https://github.com/libjxl/libjxl/blob/main/doc/encode_effort.md

I think <#822120855449894942> needs to be cleaned of everything that doesn't relate to faq

libjxl uses its own psychovisual heuristics that are tuned by hand with some help from butter and ssimu2

At effort 8+ it actually uses butteraugli but otherwise it's just making quantization decisions by its own fast heuristics

Afaik

https://github.com/libjxl/libjxl/issues/4097 layers are now not coalesced upon reencoding JXL but the metadata for the layers is lost. The layers have no names in the reencoded JXL Original JXL: ``` layer: full image size, name: "Auswahlmaske" layer: full image size, name: "Background" layer: 405x196 at position (48,149), name: "Text" ``` reencoded JXL: ``` layer: full image size layer: full image size layer: 405x196 at position (48,149) ```

With this? https://github.com/libjxl/libjxl/pull/4327

My libjxl is built from current master, if this PR fixed it, then it would keep the layer names

Playing around with distortion heatmaps in ssimulacra2:

Oh, you managed to get it outputting them?

I'm still experimenting with different ways to combine the weights and map the colors, but it's starting to look useful. As <@794205442175402004> pointed out we could output multiple error maps. Here I'm combining them all in a single one. I'll publish my implementation once I tune things a bit more, probably after siggraph.

And now integrated in my regression tests.

It's not clear to me what to do with the L4 weights when accumulating the per-pixel errors. For now I'm simply scaling the per-pixel error by both weights, but I'm not sure that's the right thing to do.

I guess you could scale the error linearly for the L1 norm and proportional to x^4 for the L4 norm

That’s the first thing I tried, but the output didn’t look as good, it attenuates many of the errors that I think needed to be highlighted . The score uses the pow1/4 of the sum of the L4 errors, so simply ^4 the error value is not accurate either. If you think about it as a single pixel score the two cancel each other.

Yeah it cancels out per-pixel but still the impact of larger errors is much larger in the L4 norm than in the L1 norm, while the impact of smaller errors is much weaker in the L4 norm than in the L1 norm. I am not sure how to reflect that in a heat map. Maybe do ^4 to the error value, then slightly blur the heatmap, and only then do pow1/4?

What algorithms is using in 1-10 efforts, with jpeg-transcoding option?

When transcoding jpeg, there's not that much the encoder can choose since all lossy choices are already made — only the entropy coding makes a difference. Basically the DC coefficients are just a small lossless image to be encoded however you want; for the AC the entropy coding has less freedom but you can still spend some more or less effort on things like coefficient reordering, context clustering, lz77, etc. But generally there is not a huge difference between low effort jpeg recompression and higher effort.

So what exactly is used for compression?

https://gist.github.com/LukeNewNew/b55a3e87037b0e951095e3fed9ec4aec

The entropy coding itself is ANS or Prefix coding, with a configurable HybridUint tokenization and optional lz77. In case of AC coefficients, they are first ordered in a configurable order (not necessarily the zigzag order of jpeg), then the number of nonzeroes per block is signaled (which is similar to the "end of block" symbol in jpeg which makes tail zeroes cheap, but even better in terms of compression), and then the coefficients themselves are coded with a configurable but relatively fixed context model.

I haven’t looked at the source code, but I am wondering if the squeeze transform needs the tendency term to be computed both during encoding and decoding or only encoding?

both

thank you

A question about `jxl-rs` - is it planned to backport it to rustc v1.87 - the version which Firefox build system is targeted to update to (but is not yet updated to; currently is on v1.86). Currently jxl-rs doesn't build on stable rustc 1.87.0 (17067e9ac 2025-05-09), because of some language constructs from beyond 1.87 and instances of `error[E0658]: use of unstable library feature 'stdarch_x86_avx512'` and `error[E0658]: the target feature 'avx512f' is currently unstable`. Or the general plan is to wait for Firefox to go past v1.87 - but IMO that would require a MSRV freeze anyway, since Firefox build system seems to be at times up to a year behind rustc releases.

Firefox is built allowing unstable features anyhow. So as long as the feature works the same in 1.87, it should be fine.

Ah, cool, so only a few language constructs then. Also seems like I overshot it with "up to a year" - more like "up to 6 months", with typical like 2-3 months behind. Tho v1.87 may be a distant target too, due to <https://bugzilla.mozilla.org/show_bug.cgi?id=1923255> But I see Martin is doing some titanic work over there.

rustc will likely get updated all the way to 1.89 after this

the main blocker are llvm changes

as long as MSRV for jxl-rs does not go past a rustc version that uses llvm 21 we ought to be fine

`Build/Test MSYS2 / Windows MSYS2 / mingw64 (pull_request)` on the libjxl repo keeps failing, does anyone feel like taking a look at that?

<@794205442175402004> I'm wondering whether `JXL_HIGH_PRECISION=0` is considered safe to use, since it's neither documented nor mentioned in the CMake configuration. Could I rebuild and publish [jxl-coder](https://github.com/awxkee/jxl-coder) with this flag?

I think it's what we used in the Chromium build back when we were still in Chromium, right <@179701849576833024> ? To make decoding a bit faster especially on older phones. So yes I would consider this safe to use. It should still conform to Level 5 conformance which is more than enough precision for viewing (even for HDR).

I honestly don't remember but yeah it's probably more than fine

When I install libjxl-0.11.1 on Gentoo, following message is displayed: * QA Notice: Compatibility w/ CMake < 3.16 will be removed in future ECM release. * If not fixed in upstream's code repository, we should make sure they are aware. * See also tracker bug #964407; check existing or file a new bug for this package. * * The following CMakeLists.txt files are causing warnings: * examples/CMakeLists.txt:3.10 * * An upstreamable patch should take any resulting CMake policy changes * into account. See also: * https://cmake.org/cmake/help/latest/manual/cmake-policies.7.html

It should just be changing this to 3.16, right? <https://github.com/libjxl/libjxl/blob/main/examples/CMakeLists.txt#L8>

Question regarding the jxl-rs Firefox inclusion: Firefox may finally be done with clang-20 migration, and even managed to Bump rustc builders to 1.89 <https://bugzilla.mozilla.org/show_bug.cgi?id=1958726>. Also as I checked the current jxl-rs compiles on rustc 1.89. Are there any plans to speed-up the first upstream inclusion tests, by reducing currently set "land initial jpegxl rust code pref disabled" rustc 1.90 target to 1.89? Also would it be possible to fix the MSRV for jxl-rs to 1.90 for ongoing developement, at least till Firefox will go to rustc 1.91 (which requires llvm 21), in case migration from clang 20 to 21 will be again complicated for Firefox project.

1.87 is the minimum for SIMD which jxl-rs uses <https://bugzilla.mozilla.org/show_bug.cgi?id=1986626>, then it can be vendored and vetted That's Mozilla's decision, everyone here only works on the JXL side of things (AFAIK)

Yes, but some time after posting <https://bugzilla.mozilla.org/show_bug.cgi?id=1986393> the 1.87 requirement was bumped to 1.90 (by Martin from team-veluca 😉 - due to some minor post-1.87 features used in jxl-rs code). But this can be possibly reduced to 1.89 (to which Firefox builder were updated recently. Also I'm asking about freeze on MSRV 1.90, due to previous difficulties on LLVM 19 to 20 upgrade in FIrefox - 1.91 will require similar upgrade, hard to say how difficult it will be.