JPEG XL

Ahh OK, added a printf to cjxl. Mystery solved, the num_channels should be 3. Now my encoded result from calling libjxl matches cjxl output.

num_channels should always be 1 or 3 iirc, for grayscale or color. It's not the total number of channels, extra channels are on top of that

Yep. Thanks, finally I can go straight from multiple .nc to a single .jxl without an intermediate .pam. Works awesome!

cool ! could you quickly recall your case ? it is 21 frames of floats32 encoded losslessly ?

Currently these 21 frequencies encoded as 16-bit uint: 400 412.5 442.5 490 510 560 620 665 673.75 681.25 708.75 753.75 761.25 764.38 767.5 778.75 865 885 900 940 1020 Also just now added altitude, also as 16-bit uint.

thoses are the wavelength in nanometer ? what are the typical size in pixels ? and more important, what are the gains you obtained ?

Those are wavelengths in nanometers yes, from Sentinel 3A/B satellite OLCI instrument. Original HDF5-compressed NetCDF files were total 493 megabytes, lossless jxl is 321 megabytes.

Insanely good space savings in my opinion

I'll soon proceed to figure out how to include 32-bit integer lon/lat and then compress a full year of data, I think over 100 terabytes.

for a lossless compression it sounds good indeed 🙂

your initial data are not really images ? each pixel have its own lat/lon coordinates ?

The satellite is like the moving part of a flatbed scanner, it produces a long narrow rectangular image from pole to pole. ESA is kind enough to provide lon/lat/alt for every pixel, because calculating where exactly the pixels are on the WGS84 ellipsoid would be painful.

but once you know the longitude of a slice, aren't the positions of each pixels perfectly determined ?

I'll have to feed the coordinates to a vertex shader and render a mesh with the color data from the color channels, to reproject it to something I can work with.

(and you could only store the information in a tag)

it looks like an hybrid of an image and a point cloud....

Yes they are perfectly determined, but only a few pixels are very close to nadir, and the others have parallax depending on surface altitude. I don't want to deal with all that right now, maybe I'll implement my own reprojection later but now I want to see the final result of cloud removal, so I'll use coordinates provided with the data.

Kind of yes, it's an actual image scanned along a surface that isn't that smooth, it's got Himalayas and such things embossed on it.

interesting 🙂 thank you for the insight.

Here's an example of a swath pole to pole, atmospheric effects corrected and RGB color space but no reprojection: https://reakt.io/swath.jpg

As you see it's tilted in an interesting way because the orbit follows the sun, always same solar time on every image row. There's Norway, Spain, Morocco and Liberia.

I'll have a look at home this evening, my proxy at work block it 😄

Plan is to mash together 3-5 weeks for global cloud-free coverage, and then animate day per frame with a sliding window. Just looking at that one .jpg, it should be epic. I've been stuck trying to get it right on the first try, but now with JPEG XL I can just store the raw data and iterate the whole pipeline locally.

one orbit is made in 90 min ? 16 strips per day or twice that since you go north to south then south to north in a single orbit ?

Orbit is 101 minutes

you cover the whole earth surface in how long ?

sounds nice but you will have to dive into the libjxl API... which you seems to have already done 😄

Only day side produces imagery, the other half is darkness. I wish they'd also have a sensor for night lights, but they don't.

3 days with the two satellites covers the globe, which is unfortunately pretty cloudy always.

how do you do cloud removal? is there a way to detect that a pixel is cloud or not cloud? Or can you make some kind of simplifying assumption like clouds reflect light so they're brighter than no-cloud so for every position if you take the minimum (darkest) value from each time you saw that position, that's the cloud-free version?

Insane statistics with Theil-Sen regressions and a transform from RGB to another orthonormal vector space for more regressions

Relies on clouds being white and shadows black across the spectrum.

ah right, you need to get rid of both the cloud itself and its shadow

Thanks for doing this! I added a bunch of suggestions to the Glossary. There are probably a lot more terms that could be added, but I have the feeling this is a pretty useful way to explain various things, in particular by not just defining the term itself but also how it applies to jxl.

On the actual website we should probably make each of the terms have an anchor and add cross-references as links. Also for some of them there are useful wikipedia pages with more information, which could be linked too.

Alphabetical ordering works, but it might be useful to also have an index to the glossary that groups relevant terms by category.

<@594623456415449088> now you have work to do ! proof read and validate the modifications 😄

Also thanks wb for the PR, I see it got merged. Already over 5000 images compressed, performance matches the test case.

amazing ! custom compression backed by a standard... the best of both worlds 😄

Under Technical, do you think info about how the codec works under the hood would fit, or do you think technical deep dives should go somewhere else

This is awesome! Thanks for all the feedback. I'll dive in and start accepting the changes in the glossary. <@794205442175402004> We'll definitely need to add all the relevant links when this gets published. I've created a second document and did a quick outline in it. Was suggested (was that you <@1051137277813870592> ?) we have a command line best practises sort of thing where we could keep track of optimal settings for different types of images. Link to that is here: https://docs.google.com/document/d/12g89AAi4PnDrPnh3xJQU5wBlh8UT5ccd6pSh7RnxBd8/edit?usp=sharing

Yeah, it's probably a bit technical for here, but SURPRISE, I have another doc I've been putting together with the technical details laypeople should be able to understand. It's still in pretty rough shape (and has lots of random notes all over it), but you're all welcome to dive into that as well: https://docs.google.com/document/d/13R2p4yZfLAYR32AJceR6Z8Retp6qH1nFbK4ayq8mVhs/edit?usp=sharing It's generally based around <@794205442175402004>’s presentation. I started it a while ago when I was pretty new to the forums, so might be a little wonky. I've learned lots since then.

What I was looking for as an FAQ when I first came here, could be classified as "newbie questions" as it was made of questions about how the format works that every newbie asked again and again to wb (who was always patient enough to explain again and again) about modular, gaborish, patches and splines, etc.

which should match your second document (I didn't start to read yet)

obviously early stages, would you want feedback on this?

Just to get clear .. for prediction in lossless mode, a context is decided and that context is selected as per some properties of neighbouring pixels (difference, upper one, left one etc...), so this context selection is based on a decision tree like structure (MA Tree) ,what is the cost that is seen while taking a decision? - how big is the residue? ....can't relate it to MANIAC, will be great to get some help 😅 and also for entropy encoding's context, is it like MANIAC?

Yes absolutely. You all have some great knowledge, so would be awesome to extract into one place for reference.

> 0.0 is mathematically lossless and the default for already-lossy input. It's the default for JPEG and GIF only, not for lossily encoded JXL or anything else. Consider: "0.0 is mathematically lossless and the default for JPEG and GIF input." > Unlike JPEG, JPEG XL empowers you to specify the amount of effort spent on compressing an image. Effort is feature of encoders rather than the format itself. Some JPEG encoders offer control over computation, some JXL encoders do not. Consider: "cjxl empowers you to specify the amount of effort spent on compressing an image." > Higher numbers allow more computation at the expense of time. For lossless, it will generally produce smaller files. For lossy, higher effort should more accurately reach the target quality. If computation is measured differently than time, then in a multicore environment it's not necessarily true that more computation means more time. If they are the same, then the statement is redundant. The computation/density trade-off also applies to lossy. Consider: "Higher numbers allow more computation, generally achieving smaller output at same quality. For lossy encoding, higher effort should achieve more accurate quality." > cjxl -d 0 e 9 logo.png logo.jxl Generally, I suggest e9 shouldn't be encouraged except to dissuade someone from using e10. But, who is the intended audience, the practical consumer, or the compression hobbyist who watches their computer think for entertainment?

In FLIF/MANIAC, the MA tree is used only to determine entropy coding context (FLIF uses a fixed predictor per channel). In JXL, the MA tree determines both context and predictor.

So, like in MANIAC, there are two virtual contexts/ property and the bit estimate is seen for the cost and decide based on which property does the tree grow, what does happen here for prediction? The cost is the residue's size? Or like on a broader scale, the same technique of virtual contexts is used here for growing?

In general, when choosing the encode effort, it makes sense to think about how many people you will share the image with, and how long it will be stored. If it's just for yourself and it's only stored for a short time (e.g. it's an image you are still editing), very low effort makes sense. If you intend to share it with thousands or millions of people and/or will keep it stored for years if not decades, then high effort makes sense.

There are various approaches for the encoder side of how to make an MA tree. The one in FLIF was to grow it dynamically while doing mock encodes by keeping around statistics on virtual contexts (i.e. potential new tree nodes). In JXL, we sample the set of tokens per predictor and per quantized property (where the set of predictors and properties to consider depends on the encode effort setting) and construct a tree by iteratively selecting the property that best separates the tokens into two subsets with lower entropy.

Both approaches are constructing the tree in a greedy, one node at a time way, so it is not going to find optimal trees.

There are also some heuristic considerations like avoiding to use the Weighted predictor if it doesn't bring enough benefit, since it is a rather costly predictor decode-side so if it is possible to make a tree that doesn't use it at all, it's better to do that (allows the decoder to use a specialized decode path that doesn't do all the stuff needed to maintain WP state)

There is definitely room for improvement in the encoder side of MA trees. Currently we have three strategies: skipping context completely (this is done at e1), using a simple fixed tree (this is done at e2 and e3), and then the greedy splitting method, with less or more of the possible properties and predictors considered (this is done at e4+).

There's room for doing something simpler than full tree construction but less simple than just a fixed tree. Something like a parametrized tree with a constrained shape (that will also allow decoder specialization). This could be good for e4/e5.

Sounds like a decision tree that could be optimized like the moves in a game of Go? Just need to convince DeepMind to look into this 😛

And there is also room for something more complex and exhaustive (not greedy search) than what we do even at e11, but doing that will require some new clever ideas (or maybe AI) if we want to make it feasible in terms of CPU and memory. The search space of possible MA trees is extremely huge.

This would be an interesting application imo for AI, since it is "safe": an encoder can use any MA tree and the result will still be lossless, the only difference is how well-compressed it is. So it does not matter if the AI is not perfect and has some edge cases where it hallucinates crazy results. Lossless is lossless anyway, the worst that can happen is that the file is bigger than needed.

Thanks <@794205442175402004> as always, can you just clear here.. about the 'token' ? Is it the 'context'? and ya <@446428281630097408> , was just going to say about the Deep Learning part... probably the recent meeting of JPEG on JPEG AI might see this... (am I allowed to say that...?) 😬 😅

Probably, it would be the first really useful usage of AI

I've been meaning to try that for a while but I never managed to think of something that is actually trainable and runs in a decent time (and is actually an improvement xD)

wonder how good an AI would be at patches detection and at detecting that a sub-region of an image would compress better with VarDCT.

The token is the residual symbol to be encoded (partly as raw bits, partly as entropy-coded bits where the cost will depend on the distribution of values in the context). Each predictor leads to different tokens.

Using the actual compressed size as cost function in training is not feasible, or is it?

nah, that's fine

training a small NN to replace the MA tree is a somewhat reasonable thing to do, and reasonable to train, but I have not managed to get significant improvements over MA trees -- maybe I should try again, but it will probably not be fast 😛

<@179701849576833024> have you got any git repo for the NN implementation you did? Would be interesting to know...

nah

it was a while ago and what I did try did not go anywhere so I don't think I kept it around

https://arxiv.org/abs/2312.02753 this is promising though

Anyway thanks for this, will look into it... 🙂

I'd expect to train a NN to take an image as input and produce an MA tree as output 🤔

Then the decoder doesn't need that processing

I didn't mean that, I meant using a NN in the encoder to construct a MA tree, staying entirely within the existing jxl bitstream.

ah, that I thought of too, but it's very very annoying to train

Using a NN in the decoder to replace tree traversal by something that involves more multiplies but less branches is another thing that could be interesting.

and it's not like I wouldn't know (theoretically) better (and probably slower) ways to construct a tree, but haven't had time to try it

For MANIAC, do we grow the tree as we encounter values to encode at each step? Initially, we get a value to encode and, based on certain properties, we grow the tree... We use the leaf node (the current context) to encode the value. When the next value comes in, do we start from the root again, check the properties, and potentially grow the tree with a new node based on a different property, traversing to the leaf node to encode the value? And do we continue this process for the rest of the values? Wouldn't we end up using the same traversal paths through the tree for some values? Did I understand this correctly? (asking this here bcz for JPEG XL's tree's understanding..)

Ending up in the same leaf many times is the point, the goal is that the distribution of symbols for which this happens helps to save bits though. E.g. in one leaf the values are close to zero and in another leaf the values are far from zero.

Ending up in the same leaf will be applicable for pixel residues/ values of similar local local structure right? the values pertaining to some other local variations spatially, will be populated in some other leaf... as each leaf node is actually a context corresponding to some values of the properties...

I created stubs in both files for animated JXLs.

Yes, that's the idea. So both the predictor and the distribution of residuals can be adapted to the local structure, and the way this adaptation is done can itself be tuned per image since the tree is signalled, hence _meta_ adaptive (MA).

btw the image comparator linked on jpeg.info no longer shows any images. maybe swap with this newer one https://afontenot.github.io/image-formats-comparison/ feeling its not appropriately representative about jxl and jpegli in particular but unsure if theres any oddity in their use (forcing 444 chroma subsampling for all target filesizes instead of default behaviour preserving quality better at smaller target filesize) or notable regressions found or fixed since the jxl/jpegli snapshot they used

why did you censor https

linking without a big distracting embed

you can use <>

there's a button to remove embeds from a message you have posted, there is no need to do what any of y'all are doing/suggesting

<@259747149292634112> : I saw your email about ssimulacra2, we can discuss things here too since perhaps someone here might also have ideas. You described three directions for experimentation: - Use Oklab instead of XYB, - Quantify effect of gaussian approximation for different test images, try higher-precision gaussian: f64, Charalampidis 4-terms - Penalize blocking artifacts: Replace edge diff maps with laplacian, sobel etc. And yes, all three of them seem interesting things to try. Another thing that could help improve it is to find cases like the example you had where blocking artifacts were not sufficiently penalized, or in general cases where ssimulacra2 is wrong (I suppose more cases can be found by searching for pairs where it disagrees strongly with other metrics and manually examining them to find cases where ssimu2 is clearly wrong), and just add them to the training sets for tuning (give the problem images a more reasonable score manually and re-tune the weights, making it more likely that artifacts are weighed correctly).

It could be interesting (though too late for jxl) to try something like a small NN that takes some local neighborhood as input (say, a 5x5 region where the currently decoded value is in the middle of the bottom row and the two values to its right are missing) and produces a context as output. With a few intermediate neural layers, that could probably approximate most jxl MA trees, but possibly it would be easier to reuse existing methods to learn the NN at encode time and to evaluate it efficiently at decode time. Skipping the current-row pixels (only looking at rows above) would probably be useful to improve the decode speed (since it allows way more parallelism), at the cost of some compression potential.

And yes, the tree does not have to be balanced, you can e.g. have a tree that basically tests if W == N == NE and if true then it immediately goes to a leaf with predictor W (which will probably have mostly zero residuals), and in the other case there are bigger subtrees

Thanks..Got it.. although I need to get more thorough in understanding the trees....

sounds good. I'll follow up when I have more to show. In the meantime, if anyone has additional ideas to improve SSIMULACRA2, please let me know.

<@794205442175402004> the actual context (array of chances) stored in a leaf node in MANIAC—what does this distribution represent..please let me know?

In MANIAC/FLIF, it's basically CABAC, i.e. every symbol is written one bit at a time in a is_zero-sign-exponent-mantissa representation (where the exponent uses unary notation), and each of these bit positions have a chance (which is somewhat signaled but mostly adjusted during encoding/decoding based on the bits processed, i.e. after writing a 1 bit, the chance goes up a little, and after writing a 0 bit, it goes down a little).

In JXL, it's either ANS or Huffman, and the distribution is a fixed set of chances for each token value. Symbols get encoded using a hybrid approach (we call it HybridUint) where each symbol is represented as a token plus a number of raw bits (where the number of raw bits depends on the token). The exact way of splitting symbols into token and raw bits is also adjustable, but for example it could be as follows: for symbols between 0 and 15, use dedicated tokens that represent the full symbol (no raw bits). Then, starting at 16, the token represents the exponent (i.e. number of bits) and two of the most significant bits, but the remaining least significant bits are encoded as raw bits (just written directly into the bitstream without any entropy coding). So if the values are in, say, a range like -255 .. 255, or after PackSigned something like 0..510, then you would still only have maybe 50 tokens or so, since high-amplitude symbols share the same token. The distribution of token values is signaled per context and fixed during decoding (which helps a lot to make decoding fast, compared to approaches where the distribution is updated during decoding). The idea of HybridUint encoding is that entropy coding will generally only be useful for the most significant bits, while the least significant bits are inherently more noisy. If those bits noisy and they have a roughly uniform distribution, then writing them as raw bits instead of trying to entropy code them with ANS or Huffman will be just as good in terms of compression, but it's faster to just read raw bits than to read entropy coded bits. The original JPEG actually does something a little similar in how it effectively Huffman codes only the exponent and does the rest as raw bits. In jxl, the HybridUint representation is more flexible though (also sign and lsb can be put into the token, for example).

typically I will extract the prores sequence to something like EXR, then encode the exr files using cjxl then mux the ending sequence

Thanks <@794205442175402004> ..

Are there any concrete references to where the separation between medium color distances and large color distances begins? I know a dE of <1 is visually imperceptible, but are there charts for what percentage of people should be able to accurately tell apart a dE of 2? 3? 4? etc

Check this paper <https://cloudinary.com/labs/cid22> in reference to these settings https://discord.com/channels/794206087879852103/803645746661425173/978954251680251934

well, first of all, it depends of whether you mean ΔE 76, ΔE 94 or ΔE 2000

admittedly, 94 is unlikely

but 76 is still relatively widespread, afaik

and there, it’s 2.3 that roughly corresponds to a just-noticeable difference

<@794205442175402004> , u mentioned about the intermediate layers.. was it for capturing a bigger context? or using many feature maps, we can keep an account of different properties for a context? Or is it both? Like as we go deeper, it takes account of larger context in stages and get the depth of each layer (number of feature maps) equal to the number of properties...

But I guess that is when comparing largish patches of colors. If you get that kind of difference in a single contrast-masked pixel, it will probably not be noticeable except maybe in a flicker test.

I am not familiar enough with NNs to have good intuition in what kind of trade-offs would be acceptable for something that needs to be evaluated for every single pixel, but I would imagine it is best to have a not too large local region, and to reduce dimensions quickly, but then you can have some intermediate layers to translate a small set of features to a context, or maybe directly to a predictor and a distribution. I have the feeling that you want to allow some expressivity to capture nontrivial combinations of features, i.e. going straight from local sample values to context in just one or two layers is probably not expressive enough to be useful enough. Anyway, it's all speculation until someone tries to actually build such a MA ctx NN.

Ya, that's true...and reducing dimensionality quickly through convolutional layers or pooling helps to manage computational complexity and speed up the process and excessive reduction might lead to loss of critical spatial information needed for accurate context generation. More intermediate layers allow the network to learn more complex patterns and combinations of features, leading to potentially better context prediction but more layers increase computational load and inference time. There’s a trade-off between model complexity (expressiveness) and speed. A network with sufficient expressive-ness can capture non-trivial combinations of features, improving prediction accuracy and compression efficiency while balancing expressivity and efficiency is crucial. A too simple network might not capture enough detail, while a too complex one might be too much..and slow and impractical for real-time decoding...... btw there can be a problem in training the tree too.. what shall be taken as data set ? How can a tree learned now be extracted / or used as a data point...

idk if it already does this, but... high-frequency, uniform distortion should be penalized much less than low-frequency, non-uniform distortion. A lot of metrics can be fooled pretty easily by, for example, taking a picture of a cat as the original image, and comparing a picture of a dog, or the same exact picture of a cat with some uniform noise added on top. Most metrics think the picture of a dog is more similar to the original picture.

in XYB and Lab (likely oklab and other derivatives, too), there is a different amount of blue influence -- in the scale of pixels blue is rotated differently for iso-perception contours vs. the scale of thousands of pixels (2 degree colors used to define Lab)

Oklab doesn't take into account spontaneous isomerization, i.e., no linear slope near blacks

not sure if Oklab has logaritmic behaviour in the end

... also not sure of the XYB implementation in ssimulacra2 -- I think it is only the quick part of JPEG XL decoding, i.e., also no log and linear part

a biased log -- or a hybrid of three curves (linear, gamma/power, log) works better than a simple model

does JXL support Oklab?

all image codecs can support Oklab if expressed in an ICC profile

But would it be good for compression?

internally lossy VarDCT would convert it to XYB for storage

no

My work is not related to JXL encoding and my proposed ideas and experiments are directed towards perceptual evaluation only. I understand there are subtleties regarding the choice of XYB. However, in my experiments, with unmodified SSIMULACRA2, I observe that Oklab guided encoding yields better bitrates per SSIMULACRA2 scores, compared to XYB guided encoding (X, Y, Y-B formulated and weighted exactly as in SSIMULACRA2). Potential reasons might be: - I employ equivalent quantization for the three components. - Oklab predicts luminance and chrominance so good that predictions hold strong after gaussian of SSIMULACRA2. This would make sense because Oklab is derived from CAM16 lightness/chroma and IPT hue. - Oklab has better euclidean/cartesian properties. Another interesting observation is that Oklab guided encoding slightly outperforms CAM16-Jab guided encoding. CAM16-Jab is specifically designed for eucliden deltaE and is considerably more expensive to calculate.

X and Y should not be quantized in the same way, they are on wildly different scales. X has a way smaller range.

XYB is certainly not perceptually uniform in the sense that euclidean deltaE in that space makes any sense. It doesn't. In jxl, the quantization used per XYB component is very different.

<@594623456415449088> about the 1.0 version you asked "Does that work?". I would tend to think that as any symbol it have a meaning only if you give it one 😅 And I already saw a project doing so. For me it doesn't matter, the encoder is functional and I don't use the api.

Hey... if I try to compare the two improvements... 1.) the improved predictor using context ... 2.) the improved entropy coding using context.... in JXL than WebP (both lossless modes), can we point out one which is a better one? In WebP, context modelling takes although as we have seen it is a weaker one, but predictors .... they seem to get fixed for a particular set of pixels in WebP..is it a valid way to think?

Does XYB? I always notice libjxl sloppily splotches and destroys fine textures and details in darker shaded image regions.

But this was with an older version of the libjxl encoder

Haven't tested the latest in that regard

WebP uses auxiliary images (with a granularity that can be chosen, from 1:4 up to 1:512) to represent the predictors to use (14 options), the RCT to apply, and the context (Huffman code to be used in each region). So these can be chosen at some granularity, but of course the finer the granularity of these auxiliary images, the higher the signaling cost. In any case local choices can only be made in square blocks. The actual entropy coding is similar to DEFLATE (Huffman prefix coding + LZ77 with sliding window matching), with some image-specific tweaks (there are short codes for LZ77 distances corresponding to nearby pixel positions above); also there's a color cache that basically is a kind of dynamic local palette of recently-seen colors with short codes. Samples are encoded pixel by pixel (RGBA interleaved, like in PNG). Overall, lossless WebP is in my opinion an evolution of PNG, which is doing a lot of things similar to how PNG does it, i.e. it is still basically DEFLATE applied to an RGBA buffer filter by a predictor, but everything is done better: more and better predictors, predictors can be chosen per block instead of per row, lz77 matching is "2D aware", huffman codes can be chosen per component and per 2D region of the image (as opposed to PNG which uses regular DEFLATE), etc. FLIF uses a fixed predictor (Gradient in non-interlaced mode, one of three funky predictors in interlaced mode) and a fixed RCT (YCoCg), but has an MA tree to describe context, which allows the context to follow the actual local image features (at pixel granularity) without having to explicitly signal it. It uses CABAC for the actual entropy coding, just like FFV1 (and also some of the MA tree properties are basically just the unquantized values used in the "large" context model of FFV1). Samples are encoded plane by plane (first all samples of channel 0, then all samples of channel 1, etc).

JPEG XL took the best elements from both WebP and FLIF. The set of predictors it has are Gradient from FLIF, most of the predictors like e.g. Select from WebP (we dropped a few that turned out not to be very useful), plus the Self-correcting (Weighted) predictor that was developed for lossless PIK and the AvgAll predictor that was added late and mostly to be used for lossy (using delta palette). The set of RCTs includes YCoCg from FLIF and a generalization of the SubtractGreen transform from WebP. They're signaled globally or at the group level; switching them up at a finer granularity is not really useful since it introduces poorly predicted edges on the border between different RCTs. Context modeling is done with an MA tree like in FLIF. There are more MA tree properties in JXL than in FLIF: in particular the actual x,y coordinates were added as properties (allowing a tree to represent a purely geometric segmentation like in WebP), as well as properties related to local prediction error. Entropy coding is done with fixed-distribution ANS or Huffman, with optional LZ77 with short codes for nearby samples (so that's more similar to WebP than to FLIF). Samples are encoded plane by plane (like in FLIF).

Thanks...asking kinda the same things again and again, sry for that ..... but gets refined every time...

I'm curious if any researchers have ever taken a shot at making a four dimensional equivalent to LAB

Adding dimensionality would probably be really beneficial for some of the trickier edge cases for a euclidean DeltaE

Even if XYB takes it into account in the formula, it's likely that the encoder damages that effort during the RDO process. Regions with low local variance need additional protection, because any color distance metric will produce a small distance between a smooth gradient block and its flattening. This results in disturbing and easily noticeable artifacts. I don't know if libjxl has mitigations for this, but I have concrete examples showing SSIMULACRA2 does not penalize these cases, which is one of the reasons I arrived here.

libjxl has an "intensity target" option to tell the encoder how brightly the image will be displayed. When this number is higher, the encoder preserves more shadow detail.

In general, SDR images are not really fully defined since both the display brightness and the ambient light can be anything. There is a huge difference between viewing an image at 80 nits in a typical office environment, and viewing that same image at 500 nits in a dark room. What can be visually lossless in the first case, can look like obvious banding and blocking artifacts in the second case.

that's a good way to put it. They usually call this "noise masking"

The same amount of distortion is easier to notice in a "quieter" area of the image compared to a noisy one.

And high-frequency noise is less disturbing than low-frequency distortion. They call that "noise shaping"

I think image encoders could benefit a lot from those techniques...

Like you said, currently it doesn't seem like local variance or "masking" is taken into account. And the encoder seems to prefer to create splotchy smudgy low-frequency artifacts rather than high-frequency "shaped" noise

Actually, the encoder DOES seem to take masking into account sometimes. libjxl seems to be very good at preserving texture, as long as color isn't involved...

It's probably the best out of all codecs at preserving texture... not accounting for color loss at least.

I know there was a blog about using JXL noise to dither HDR images back to SDR to avoid banding, I wonder if it could be useful for normal SDR too

It used to be, but now 8-bit JXL has dithering

That's encoding from a HDR file into an 8bit JXL though, right? Here I mean displaying a HDR JXL on an SDR screen, then encoding an SDR image to JXL with noise to hide artefacts... Maybe

Better ask here. I'm decoding JXL files in Wasm and then further processing them in WebGL or WebGPU. I'd like to understand if there's any steps that could be moved from Wasm to GPU. I asked ChatGPT about how the decoding works on a high level and it said: 1. Bitstream parsing 2. Entropy decoding 3. Prediction and reconstruction (based on previously decoded neighboring pixels or blocks) 4. Transforms like DCT or wavelet 5. Color conversion and upsampling 6. Post-processing It sounds to me like steps 1-3 are CPU-only territory but there's potential in 4-6. Is that overview and initial guess correct though? Any idea if almost all the decoding time is spent in the first 3 steps anyway?

<@179701849576833024> probably has the best idea of the current distribution of decode time spent on each of the components, but I would estimate that the stuff after entropy decode is still quite substantial, and could indeed benefit from GPU.

Yeah, I think there's some potential for speedup there

Interesting, from the point of view that pretty much all current browsers offer a standard and easy way to offload processing to the GPU. Guess I'd need to run a profiler next, to see how much time is spent in the kind of activity that could be potentially sped up. It will have to wait several months though, but will keep this in mind.

Spent a few hours rooting around a hex editor for this issue, turns out it's not JXL at all and people are taking guesses at how the format works in the Adobe fourm. Getting lossy mixed up with lossless and thinking VarDCT is only used for the jpeg transcoding https://github.com/libjxl/libjxl/issues/3640 https://community.adobe.com/t5/camera-raw-discussions/samsung-s24-ultra-phones-don-t-do-raw-anymore-it-s-not-adobes-fault/m-p/14443437

Seems more like the programs are opening the Jpeg preview rather than the lossless jpeg

Suppose for a prediction, in lossless, if we keep the idea of trees aside, does necessarily a larger neighbourhood give an idea of a better prediction? For example, suppose I have a linear weighted predictor and I take a larger neighbourhood for a complex region of an image and eventually learn the weights , will it guarantee a better prediction than working the same thing in smaller neighbourhood ?

Something like a small MLP could help with finding optimal trees and stuff I’m not sure

you mean the optimal size of neighbourhood?

In general, anything that involves guessing and checking (generating trees, types of residual) could be possible improved

Maybe with AI-based predictors it could make sense to use a large neighborhood, but for simple classical predictors, I think you'll very quickly get diminishing returns. One of the best predictors is still just W+N-NW or its variant ClampedGradient. I think that if you use a larger neighborhood (say, some weighted sum of a 7x3 region above the current pixel plus the three pixels on the left), you might be able to get smaller residuals but that won't necessarily result in better compression: residuals can have lower amplitudes but more entropy, which I think is likely to happen here: anything complicated involving lots of sample values will give more opportunities for 'noisy samples' to do more 'damage' (since it will influence a larger region of residuals). E.g. when doing lossless multi-frame compression, you can subtract the previous frame from the current as a predictor, and that will surely turn your image into residuals with a lower amplitude, but that doesn't mean it will compress better.

What would be the best (well, fastest) way to check that a jxl file is valid or at least was transferred completely? Is there a way to compare some checksums / sizes without decompressing the whole image?

I _think_ `jxlinfo` should do at least the latter

(based on hacking it today to add support for printing basic information about the `jhgm` box if present)

You can't check that the image data is valid without doing an actual decode, but at least `jxlinfo` will tell you if the image/frame headers are OK. It will not detect that a truncated file is incomplete though (it will stop parsing after the last frame header). Trying `djxl` on a truncated file will fail quickly though. It should in principle be possible to check for truncated files without doing actual decode (the TOC will tell us if there are enough bytes or not).

Checking for corruption is not possible without doing an actual decode though, and it is also not guaranteed that corruption gets detected at all (though it is rather implausible that it goes undetected).

Sometimes simplicity is best, could you just precompute a hash at the origin and then compare on the client?

Suppose, I have a causal template of 4 pixels, that is N, NW, NE and W. Now, I want to change this to a broader one, suppose I add these pixels NN, WW, N-NE to the template. Now the template is bigger...and my motivation of using a bigger template is : complex areas in terms of texture might have a broader correlation to capture and so a larger neighbourhood includes more surrounding pixels, which helps in capturing a broader context. This means the predictor can better understand the structure of the image around the pixel, leading to more accurate predictions..... but again as you said the trade off with the noise remains: 1.) Firstly is this a valid reason to use a bigger template 2.) Secondly, if I can bias the shape of the causal template (maybe using gradients or correlations of the pixel surrounding and use more pixels in the direction orthogonal to the gradient(mode of the gradients of the surrounding pixels) ), can I get rid off the noisy samples?

Probably the best way to get answers is to get some corpus of images and just try stuff — e.g. you can hack a libjxl where you replace some predictor with whatever you want to try, and compare compression with `cjxl -d 0 -P 5` (fixed gradient predictor) with the compression using `cjxl -d 0 -P [your predictor]` to see if it is any good.

Are there any front end/full stack web devs that have some time on their hands that wouldn't mind giving some help on a JPEG XL project we're working on? I need someone who it better at Javascript than I am.

Can you tell us what the project is?

Why yes I can! A few months ago we (my little agency) came to <@794205442175402004> with an idea to redo jpegxl.info to better promote the format now that it's getting some traction. Here's a screen cap of the home page design we presented.

In our spare time we've been working on it ever since and it's starting to get pretty close.

We could just use some help getting it over the finish line.

We've also been working on the down-low on some other fun tools that show off the format: https://sneyers.info/test/ImageList_Index.html

Maybe let's make a dedicated channel for the community website development

I made <#1256302117379903498>

putting it between <#822105409312653333> and <#803574970180829194>

I'll take a few more screen shots and add them there for context.

Kinda silly that most computer screens are still using only 6 bit depth, the standard VGA was using already in 1987.

aren’t they using 6-bit panels but with dithering?

it’s also less and less the case, isn’t it? I’m not sure about “most” among those being newly made

I once in a while see some lower end laptops with 6-bit panels but that's about it, pretty much every thing else is 8-bit

Or 10-bit, at the higher end.

https://twitter.com/discord/status/1807826664925069822

seems like Discord's generated thumbnails now support ICC color profiles?

I see green and green

if only Discord didn't prevent me from opening the Chromium dev tools

ctrl shift i?

Need to enable it in a config file, but yeah, it's still available

last times I tried that it would restart Discord and close them

Huh

works for me 🤷

it's been a few months though, guess Ill try again

and i never changed any config

I just remembered that it would also log me out

huh seems to work now

getting logged out every time I attemped to open the dev tools was annoying

Yep, the WebP previews now have ICC profiles attached

chrome still doesnt support windows advanced color...

huh seems like Discord generates lossless WebP thumbnails for PNGs and lossy WebP thumbnails for JPEGs and WebPs

before it used to generate thumbnails in the same formats as the original image and then at some point changed it to be all lossy WebPs but now it's a mix of lossy and lossless WebPs

although if the original image is a lossless WebP it still seems to make the thumbnail a lossy WebP

<https://github.com/discord/lilliput/commits/master/>

dang https://github.com/discord/lilliput/pull/103

that's been a thing for at least a month, not sure how far back

you can post hdr png images on discord (using e.g. the icc profile created by libjxl), and both the embed and the actual image will be in hdr

(shameless plug: <https://github.com/ledoge/jxr_to_png>)

what exactly are you referring to?

the new color management

do you mean the windows 11 feature "Auto color management"?

yes

ah

don't know anything about that, sorry, but Windows HDR (which is also part of Advanced Color) is supported properly at least

also: i've seen some people with discord profile pictures that have a p3 icc profile attached, but when i try to upload a file like that it gets stripped

so maybe that only worked at some point in the past

That example is only 30% smaller not 60% smaller

350 is 30% smaller than 500

Those are random numbers from when I first did the design a couple months ago – it's a mockup in Figma. The actual numbers are automatically pulled from the actual images used.

hm

about Jpegli, theres a separate github page under google. is that official ?

I do recall mention of seperating the projects, so I'd assume it is https://github.com/google/jpegli

https://github.com/libjxl/libjxl/commit/5ddb303a1457899d845dc7d385b562e340d2e473

Yes Jpegli got its own repo

This still works after replacing libjxl with jpegli https://github.com/google/jpegli/blob/main/BUILDING.md

Along with https://github.com/google/jpegli.git

How can we conpare two models for predictors , if we just have their histograms of residue with us.. (selecting a model before entropy coding). One model may have less zeros as residues than other..but if the total number of non-zero residues are less too, will that model be considered better? What metric can be used to compare the histos of residues??

if you assume a static codes (like how it is in jxl), then you can estimate the (fractional, in case of ANS) cost per symbol quite accurately, and compute the estimated bitstream size for a histogram more or less exactly. The hybriduint coding jxl uses complicates it a bit since you also have to count the raw bits, not just the bits needed for the entropy-coded tokens.

Just looking at sum of abs residues or something like that is not really good enough. If one predictor has residues -3, -2, -1, 0, +1, +2, +3, +4 with uniform probabilities between them, it has low sum-of-abs-residues but it will be a lot worse than a predictor that e.g. has only residues -10 and +10, each 50% of the time. The first one will require 3 bits per symbol while the second can be done with 1 bit per symbol.

(generally predictor residues will be more like a double-sided geometric distribution around zero, and sum-of-abs is not the worst heuristic you could use, but especially if you have something like MA tree context, you can end up with weirder histograms in some of the branches)

Okay.. thanks.. have to think of a combination of metrics for an absolute decision...

Hi, do you know if there's a way to batch compress with ECT?

You can give it the path to a directory to compress all files within it, `-r` to recursively compress subfolders, `--mt-files=8` to compress 8 files at a time

I wish `--mt-files` did parallelize compression of files from zip archive [⠀](https://cdn.discordapp.com/emojis/654081051768913941.webp?size=48&quality=lossless&name=av1_PepeHands)

`--mt-deflate` works for that

That's what I had tried, but without success. I will look for what went wrong, thanks for the response!

```No compatible files found```

Make sure to use `-zip` too, but don't run that on a folder with PNGs or Jpegs....

Aah, okay!

It works now.

that'll only process each file sequentially, but use several threads for each file iirc

A zip is counted as a single file

I was speaking of the "embedded" files in the zip archive

Yeah, each 'file' is just seen as a separate deflate block internally

I made a test page to see how various browsers are doing w.r.t. HDR

https://sneyers.info/hdrtest/

Chrome, Safari, Firefox

I had to make a screenshot by making an actual picture of my screen, since the MacOS built-in screenshot thingie doesn't make HDR screenshots, it produces something like this instead:

Curiously, in Thorium M122 almost all image formats worked perfectly, rendering all images as they're supposed to be rendered, only exception being AVIF with a PQ ICC profile which got rendered with some small but noticeable tone shift (the CICP-only version looked fine though). But in current Thorium M124, the jpeg and AVIF with ICC profile look way too dark, not as bad as those images in Safari that are almost black, but still way too dark, similar to how the AVIF with CICP-only looks in Firefox (the bottom right image in the screenshot above).

Annoyingly, my phone doesn't even register as HDR capable due to being a different standard to Android's normal, so all rec.2100 images have horrible banding and the color tests somehow end up with stray bands of red, green and blue

what android version are you running? also what brand?

Could be. My Chrome is at M126, I can't easily downgrade it to M124 to see how it looks there. A bit strange though that it worked OK in Thorium M122 but not anymore in Thorium M124...

Firefox 129 (Linux amd64)

Android 10, I think. It's an old Huawei mate 10 pro

The only apps supporting HDR is the built in video player and the YouTube app, nothing else is set for the right API

yeah you kinda boned, some apps do support it, but not many bothered

Chromite on Pixel 8 seems to be working perfectly

I don't understand how Android versions work. There are still new phones being sold with Android 11. That's like if they were selling new computers with Windows 7.

Yeah, in phones it's not that straightforward like booting from an USB drive, erasing the system drive and installing a new OS.

people buy what they buy, that's about all that can be said, any "new" phones being sold with an outdated android are probably just rebadges

Google is also quite lax, which does not help the situation

People buy what's available and affordable.

well, it's not like google can really do anything, they just make the barrier as low as possible, and from there it's up to vendors

Vendor control is something Google can do, they are rather hands off though

I still remember Project Treble, but nothing really changed since then

how would google do vendor control? there really isn't much they can do, AOSP is open source.

the only thing google could feasibly do, is prevent gapps from working on old android devices, and good luck with that

Fair point

And then people buy phones with OS that's already EOL without knowing and put their bank apps there.

To be fair, there are very few real reasons to drop support of old Android versions, like some app vendors like to do. We support starting from Android 8.0, and probably could support even older versions with little effort, we just saw no users of our app with Android <8.0

webview is updated by google play store, android 6 does sound about right as chrome probably no longer supports A6

2021 is quite old, quite possibly what is causing the breakage

I think this should be explained as well. I can imagine there may be confusion between lossless jpeg transcode and lossless image encode.

Payment apps are a bit special case, because it can be regulated to use some standard available in Android 12+ only, but as far as I know (I'm an Android developer) - there is no issues with Android at least from 8.0. We are developing fueling app for big U.S. company, that includes payments, but no one asked us to force some Android version

I would be concerned there could be exploitable vulnerabilities in old OS versions.

chromium with the new jxl-crx using jxl-oxide

and this is firefox using the same extension, something about it is angry

How about these questions/answer combos? ### Is Lossless JPEG Transcoding really bit-for-bit accurate? Converting a JPEG to JPEG XL using `cjxl` and then back to JPEG with `djxl` results in a bit-identical copy of the original JPEG image. However, it’s important to note JPEG standard leaves room for some interpretation, leading to potential minor variations between different decoders. ### Do other JPEG XL tools support Lossless JPEG Transcoding? Other encoders may not support lossless transcoding, so it’s best to check any support documention to verify. Note that lossless encoding of a JPEG file to JPEG XL is **not** the same as lossless transcoding. Transcoding uses a specific mode to achieve its 20% size gain while maintaining pixel-level accuracy.

Maybe it's useful to distinguish "lossless pixels" from "lossless bitstream" or something along those lines.

Doing "lossless pixels" encoding on any already-lossy image (like converting JPEG to PNG) is never going to be effective.

any good ICC inspection tooling? I used to use color.org's icc profile inspector but it's been buggying out for me lately, want to try and look into this https://github.com/tirr-c/jxl-oxide/issues/318 seems like it's producing an ICC that firefox is angry with, but works fine in chrome, or vice versa

displaycal profile info?

Speaking of ICC, I just had my Discord client completely fall apart after uploading an 8K XYB jpeg Started with the message just disappearing when pressing send, had to reload to see it. Then the CDN didn't scale the transfer properly, so everything had a cyan outline around objects, and then the client crashed a minute or so after clicking on the image for the 'large preview' My best guess is it completely broke down and tried to load the full 8K instead of the thumbnail WebP, which then hit a resource limit and crashed it

compute headroom button doesn't do anything on firefox

dunno if that's intentional

looks like it's not

``` TypeError: window.getScreenDetails is not a function ```

`getScreenDetails` is an experimental function that only works on chrome-based browsers

https://developer.mozilla.org/en-US/docs/Web/API/Window/getScreenDetails

according to MDN at least

window management API is only available on Chromium

yea, it's nonstandard

doesn't work on safari or ff

an older API that does a more limited job https://developer.mozilla.org/en-US/docs/Web/API/Screen

Yeah it's chrome/ium only

Also doesn't seem to work on the Android build of Chrome

does anyone know how developers design HW acceleration chips? i'd love to mess around and try designing one for JPEGXL, even if i can't physically print one to use on a graphics card or whatever

google points me to a lot of ai accelerators and there's no real information about the av1 chips from what i've seen

buy a fpga

there are some relatively cheap FPGAs now, but a lot of folk just use verilator to get started

it simulates verilog, there are other ways to program FPGAs that you would use to develop your hardware, but afaik verilog is still the go to

huh, thinking on it, I wonder if it would be possible to port jxl-oxide to rustHDL and go from there lmao

surely writing in a programming language and then going to a HDL would mean there's a lot of stuff you can't do?

looking at vhdl and verilog it seems heavily focused on the actual hardware based idea that lines typically get executed at the same time

idk how rusthdl and others work but how would they sidestep that?

rustHDL is just an HDL using rust afaik, it would be more or less the same?

dunno rustHDL came out way after I stopped doing anything remotely related

There was a somewhat related discussion that led to this thread https://discord.com/channels/794206087879852103/1214331530508374067/1214333150885453955

oh that looks wonderful, thanks

is there a Go implementation of lossless JXL-JPEG re-encoder? or is there some documentation about the lossless re-encoding process? would be useful to use with Go-based web servers

I’ve never used Go, does it support calling C functions?

yes, but that requires CGO and will burden the final binary if libjxl or jxl-oxide could be compiled into WASM, I think I can try getting stuff done through running WASM on Go

https://github.com/tirr-c/jxl-oxide-wasm-demo

Not sure how Wasm is a better choice than C

Also don’t know if jxl oxide supports lossless transcode

<@206628065147748352> can you confirm or deny?

jxl-oxide doesn't support jpeg reconstruction

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

WASM doesn't require CGO, everything can just utilize the Go toolchain without the additional CGO burden

Sure, but what about performance?

will take a little hit, but not by much

WASM also has the benefit of memory safety if libjxl is to be used, WASM makes sure it doesn't cause exploits due to potential memory bugs in libjxl

a reason I shy away from NGINX and have been waiting for a web server solution implemented entirely in Rust

for now Caddy is the best call

uhh

does actix not work for your usecase?

... that's a web framework for building server-side web programs, I don't think it could be used as a general-purpose web server like NGINX and Caddy

ohh right

thought you were doing like an individual application, apologies

from the frontpage of the guardian. the avif is smaller but has more details (zoom on the towel)

from my own test with illustrations, avif give better or as good result with smaller size transcoding png. although the encoding time takes forever.

do you have an explanation for the guardian photo? i though jxl was suppose to be more accurate and avif wash away details

it's hard to say without knowing the encode settings

for my personal encodes of lossless to lossy images, i do ``` avifenc -j 4 --min 0 --max 63 -a end-usage=q -a cq-level=18 -s 0 ``` ``` cjxl -d 1.4 -e 9 ``` and avif looks better, is smaller. Is there something i can improve on jxl?

Good question. I would wait for someone else to answer, but it could be that the encoder is simply at an immature state right now. half of the features are not even implemented in the encoder yet, such as noise detection or spline decomposition.

JXL has undeniable advantages in terms of how it's designed, with a table of contents for region of interest decoding, progressive decoding, image decomposition, etc... But ultimately someone needs to actually write software that takes advantage of the new features and techniques the format makes possible.

Can you share a few typical images where you are trying to compare avif to jxl? (some standard cases, not only the pathological ones 😅)

is the JXL one progressive?

For lossy, it should always be the case... I didn't checked though

Guardian JXLs were all progressive last I checked

You're right. Not only is the jxl file significantly larger, but it looks horribly smeared compared to the avif.

would be interested by the original though 😄

<@810102077895344159> ?

This example uses a very high compression ratio. In such cases, avif always compresses images better than jxl. But if you could compare the avif with the original, you would see how much detail was lost. When you look at images on sites like guardian, this loss does not matter. But when you want high quality copies of your photos, jxl wins, of course when you use a 90+% compression rate.

Avif loads in 297 ms, jxl - 31 🤷‍♂️ Also it would be interesting to see the original photo, because these two differs a lot by color

Also avif has clearly visible blockiness in the sky, and huge ringing around objects in background also in the sky

That jxl looks pretty blocky which is uncharacteristic for a higher effort

Just curious, is it possible to see whether jxl is compressed in vardct or in modular mode, **using existing tools**? Jxlinfo says nothing in this regard

Clicking on main image here on a DRP<1.3 screen (or its simulation; important!) will yield something closest to original (DPR>1.3 is much more compressed, 4×area, though): https://www.theguardian.com/world/live/2024/aug/11/israel-gaza-war-live-mahmoud-abbas-missile-strikes-school Accept Headers will (largely) decide which format you will get: JXL>AVIF>WebP>mozJPEG. There should be no colour difference between formats, colour-management-wise. Guardian is working on increasing current JXL effort (also following some comments here, thanks!). That should reduce the blockiness. > In such cases, avif always compresses images better than jxl. Yeah, not sure if always, but I would be extremely excited to see improvements at qualities closer to what Guardian uses for DPR>1.3… Extremely.

do you have a compression objective in term of bpp ? or more on quality ?

I tried and site sent me 1900x1140 jxl, that is a bit (165 KB vs 135) larger than the one posted earlier here. And it has much more details despite smaller pixel dimensions. Much less blockiness too

looking at the varDCT blocks used, it looks like it was encoded at effort 4 or lower

this is what effort 5 looks like btw

how do you do this ?

if the original images are jpgs, is reconstructible jpg->jxl conversion performed instead of a full transcode like avif would need? its literally instant at effort 7 and still guarantees lower filesize than jpg with no further quality loss (avif would still degrade image)

https://discord.com/channels/794206087879852103/794206087879852107/1242396329406238780

I find adding `-d # -e $ -I 100 -E 3 -g 3 --brotli_effort=11` crunches the number quite a lot, adding `--progressive_dc=1` can sometimes hurt a tad, but the progressive gains are quite worth it IMO

Someone on Twitter says this image compresses to 136 bytes in webp and 142 bytes in jxl: data:image/webp;base64,UklGRoAAAABXRUJQVlA4THQAAAAvGIAGEFVAaCNJkrT8Se/d1dN1DDJCEf2fgE+fw2/Fi4RgbsUcIw11hbFRcUOfitnaJ6FuttabmTPkiQbfkCT4hlILC0AVsUgH2kgjUlDxkX/CG4IX4CTCAD4ooKKFQaxYERdSFEGQMMiooCS0toNCesaEPg==

Can someone try to make a jxl version of it that is smaller than the webp? 😉

(I am on holidays, a bit tricky to do it myself on my phone)

I got it down to 126 bytes. Converted with libjxl 0.8 from a png with no palette sorting gave the best results.

~~95 bytes~~ disregard this

~~And webp can go to 106 bytes~~ and this

What encode settings were used for these?

No alpha channel? The original image had alpha

I simply used `-d 0 -e 10 --allow_expert_options`

Oh, I missed that it has alpha, my bad

interesting, the master branch of libjxl does notably worse for compressing that paletted image

in which version did `-I`, `-E` and `-g` land? cjxl 0.10.2 doesn't seem to have those

These options have been a thing since at least 0.6

you need to add `-v -v -v -v`

they're advanced options that are usually hidden

welp I only tried three times... ouch

🤡

thanks, these advanced settings would improve both lossless and lossy transcoding or only lossy?

It depends 😅 every body knows it looks a bit like black magic at this stage, with more maturity, the amount of tweaks will decrease. Meanwhile <@594623456415449088> started a FAQ which may (or should) answer this kind of questions

thank you, could you please link to the FAQ? I am not sure where to look

Me neither 😅 I'll try to find the link for you, but after my lunch

I think you meant to use -e 11, 10 was the expert option back in 0.9

They actually only work on lossless, apart from the brotli_effort or if you also use -m 1 to change into lossy modular mode

https://discord.com/channels/794206087879852103/794206087879852106/1248710437353033889 also https://discord.com/channels/794206087879852103/794206087879852106/1247977436478574715 and perhaps more interesting for you once finished, but more work in progress https://discord.com/channels/794206087879852103/794206087879852106/1248709078172176436

if you have a question, and you don't find an answer here, it means the FAQ must be completed 😄

thank you so much

jxlatte has this feature

`--draw-varblocks` will render the varblock boundaries on the image

benchmark-xl *used* to have it, I think... but most of the debug options are broken on windows <https://github.com/libjxl/libjxl/issues/2287> Trying to run `benchmark_xl --input=Test.jpg --debug_image_dir="C:\Users\jonat\Downloads" --codec=jxl:hare:d1 --save_compressed --save_heatmap` no longer errors, but doesn't output anything either

benchmark-xl had it broken for a long time

never got it to work

firefox with jpeg xl extension and librewolf cannot open this jxl but epiphany/webkit can just fine. Is it just me being unlucky or does it happen to you too?

i used this command fyi `cjxl "$i" -d 1.4 -e 10 --progressive_dc=1 "$i.jxl"`

may be using an older version of libjxl

librewolf's jxl support is as bad as firefox nightly's. only the other firefox derivatives include the updated/extra jxl patches

^ there's a lot of bugfixes Mozilla never approved, so forks have to patch it themselves

Librewolf does not contain proper JPEG XL support and the browser extension is buggy, however Firefox forks such as Floorp, Waterfox, and r3dfox display the image just fine along with Chromium forks such as Thorium and Cromite.

dont call everything a fork unless it has a divergence strategy. fedora copr has a firefox with full jxl support you can swap mozilla's firefox with

Firefox spoons tend to have decent JXL support

librewolf would be good to update with that since its getting recommended a lot

the repo for Librewolf has JXL patches but they don't use them

like they are not in the compile list

floorp is releasing v12 in like 2 weeks btw. it'll no longer be based of firefox ESR but regular firefox releases

iirc Floorp v12 got pushed back and instead Floorp v11 is going to switch to ESR128

the patches have rotted a bit over time however I know what needs to be fixed and even before then they didn't use them

can librewolf be compiled with complete jxl support?

so at least anyone interested can build it for themselves or distribute unofficial compiles

yes but the current patch they have in the repo is broken, what's strange is they test if the patches *apply* but not if they compile

I have librewolf with JXL

I'm on Gentoo

if everything on this page doesn't work then the JXL support is wrong https://jpegxl.info/test-page/

also for Firefox 129 an extra change is needed to get animation support working again and the dev of r3dfox got it working again but I am unhappy with the way they fixed it

I used libjxl 0.8

I haven't worked out the *exact* changes need for a proper fix however this works as a quick-and-dirty fix https://discord.com/channels/794206087879852103/803574970180829194/1270246841950142517

I would need to work with someone who's actually able to compile Firefox (and is willing to do it more then once lol) to make it proper for FF129 and later

I might contact the r3dfox dev and see if maybe I can get the fix to be more proper

thank you that is reassuring, i was worried there was something wrong on my end

oh hey, that's my twitter profile image! hi!

didn't see the reply thread until now cause i muted the post. got inundated with noticications 😵‍💫

A link to the thread, for anyone else like me who wanted to see it https://x.com/jonsneyers/status/1823242012818092478

If we have a linear predictor ... is it possible to calculate the weights while encoding / decoding... like a dynamic way... instead of calculating the weights before hand and sending them with the meta-data?

That's basically what the self-correcting predictor in modular mode does...

Ah.. but suppose if we only just have the option of linear predictor (and the weights are solved by least squares), then the number of pixels available for the pixels of the edge will be less than the ones which are in the center of the image ... OR Is there any other way to get the weights?

Are you talking about jxl or a hypothetical new image codec?

how do I convert a HEIF image to JPEG XL while including the HDR metadata? HEIF uses gain-maps so I would have to convert that somehow

Gain maps are currently still in a rather preliminary shape as far as standardization goes. There's what Apple does in HEIF, and what Google does in UltraHDR JPEG, and other proprietary things, but a standardized method to do gain maps is still WIP (within ISO TC 42).

im just wondering about converting gain-map to HLG HDR

you would need something that renders it out

hypothetical new image codec ..... I mean suppose I have a block of N*N and then apply least square for that block to get the weight for a linear predictor, then I have to send the weights along with the residuals... And if I make it this way that the code calculates the weights dynamically while both encoding as well as decoding then the number of pixels available for training the linear predictor (to obtain the weights) is not same, as border or the pixel near to border will have lesser number of pixels available for training right?

I randomly noticed interesting discussion

XD ~~me failing to put more `-v` behind `-h`~~

Anyway, I came here to post link https://youtu.be/RFWJM8JMXBs​ and say "we stand on shoulders of giants" to <@1013847909139226685>

~~wait, the mastermind behind ANS really is here?~~

Here and at encoding.su

I probably somehow summoned him https://discord.com/channels/794206087879852103/794206170445119489/1047574276263395358 Seems to be his first message here

Is <@592287050934386708> new account?

Hi, I use both

https://x.com/MicrobiomDigest/status/1825396092764319861 a use case for patches? 😜

Huh, they didn't even rotate it

And now I'm trying to remember if you can rotate Patches

nope, just translate

We considered it (also flips, etc) but decided to keep it simple since it adds a bit of implementation complications to do patch blitting in arbitrary orientations and it is already hard enough to detect patches without considering orientations...

I guess for the primary use case of patches (text on screen?) rotation would not be too important

Although there goes my idea of using patches for animation to emulate interframe prediction

For something like 2D game sprites, you also don't really need rotation.

Huh, well that's one hell of an exploit https://en.wikipedia.org/wiki/FORCEDENTRY

How relevant to JPEG XL?

It's an image format, so it's on-topic

JXL goes in <#794206170445119489>

Squoosh needs to display actual versions. I'm unable to report versions easily just from the Squoosh GUI.

Squoosh should also display git and other checksums for latest versions.

Squoosh hasn't been updated for over a half of year

At least it's the most convenient website to open QOI

Have you been using it to get the results in <#1271855494352343124>?

Yes.

That explains a lot

Ah yes, them kids love those colour spaces

Just got an ad for Cloudinary's AI repair feature https://youtu.be/6MrzwcSJOjk

Banding strikes when you least expect it https://store.steampowered.com/news/app/573090/view/4588693113443586130?l=english

https://clan.akamai.steamstatic.com/images//28842908/ae170b0022af95510e57edaaa4e6c4c37f339260.gif

At least it put the colors on the focus of the scene...

mfw when someone proclaims jxl bad based on squoosh its still shipping libjxl 0.5 or 0.6 nightly ffs. whole site deserves to be taken offline if they wont use decently current versions of all codecs instead of their policy of dutifully updating avif all the time so it can look better against the most outdated versions of other formats

They had a PR for 0.7, I made an issue for 0.10, but since it's in maintinance now no one is around to fix/accept the requests

https://github.com/GoogleChromeLabs/squoosh/pull/1378 https://github.com/GoogleChromeLabs/squoosh/pull/1379 https://github.com/GoogleChromeLabs/squoosh/issues/1402

maintainance sounds like a convenient excuse. theyve always dutifully updated avif. they couldve added a message reminding that the compares are not representative and no conclusion should be formed from trying or comparing severely outdated libraries whose current snapshots run miles ahead of what use of squoosh currently implies

its just that a lot of the negative perception is *caused* by such situations (ie best and latest avif vs libjxl 0.6)

there seems to be something weird going on with HDR APNG in Chrome that makes it introduce some banding that isn't there when you look at PNGs of the individual frames — <@179701849576833024> do you have an idea what might be causing that?

here is an example apng file

first frame

second frame

is it only colour managing the first image?

I made the apng by doing `ffmpeg -framerate 2 -i tmp-fr%d.png -q 0 -plays 0 test2.apng`, but it doesn't look like ffmpeg is doing anything wrong — if I extract the frames again, they are identical to what I started from.

nah color management is fine, it shows things in the right colors and in HDR just fine

uh, what

open tmp-fr1.png in chrome — it looks fine, right? it's the result of decoding a d1 jxl

now open test2.apng in chrome — now I see banding in the sky. The discord preview of the first frame also has this kind of banding by the way.

the second frame looks fine both as a still image and when shown in the apng, so it's not that it's doing something bad like displaying it in 8-bit or something

i think discord previews are always webp? so 8 bpc

but there's still something different between how it renders that first frame as a still png versus how it renders it in an apng

oh wait a minute

actually I think it is just rendering the apng in 8-bit

somehow an 8-bit version of tmp-fr2.png still looks OK while an 8-bit version of tmp-fr1.png has banding

I think I've had something like this before, but I think it changed if I also clicked to 1:1 the image too (assuming it's larger than the display. Could be unrelated though or misremembering

side note: this is why hdr png images only get an hdr preview if they have an icc profile with a `CICP` tag, as the png `cICP` chunk just gets thrown away when generating the preview

anyway, I was planning to use apng to do a flip/flicker comparison but now I know that's not a good way to do it. Javascript swapping still images will be the way to go.

Not lossless webP?

png goes up to 16 bpc, webp only does 8 bpc, so it's not suited for hdr images

12 bit looping video?

Does anyone happen to have HDR screenshots from a game, or a HDR render? Preferably not particularly photorealistic stuff, and having some nonphoto elements in it would be good too. Looking for some test material to propose for a potential subjective experiment, and it would be nice to not only have photographic images but also something synthetic...

lots of hdr game screenshots here https://discord.gg/E89ZKtve

Maybe some of the Blender release images look good in HDR, and many of them are non-photorealistic

I just noticed that the Linux distro I use (Alpine) disables JXL support on s390x, so you don't get JXL if you're running on an IBM mainframe :/

but only there?

yeah

I was just looking at the build dependencies for kimageformats5 and saw this: ``` case "$CARCH" in s390x) ;; *) makedepends="$makedepends libjxl-dev" ;; esac ```

Does libjxl support that architecture ?

I think I have a vague recollection of a discussion about this with <@179701849576833024> where he pointed out that Highway doesn’t support it

That's entirely possible