JPEG XL

Everybody loves you! (except AOM)

> (except AOM) (but they should ;_;)

hello all, oss-fuzz has found a possible buffer overflow in libjxl master

it's only a read out of bounds, so probably not too serious ok to open an issue?

sure, please do

I wonder why our ossfuzz didn't find it...

ok done https://github.com/libjxl/libjxl/issues/347

we have a different set of seed files I guess or perhaps I've cocked up my libjxl interface code heh

likely the seed

or this is another manifestation of some bug our oss-fuzz also found 😛

When can we use JXL with Chrome by default? Everything is fuzzed out, right?

It's a political question more than a technical one at this point, I think. But yes, no more fuzzing bugs for a while would be good.

Has the political question already been turned down or is there anything we can do?

(oops wrong channel most likely)

I don't know if there's anything that can be done — maybe Chrome decision makers will more likely approve enabled-by-default if Firefox does so too, and I think Firefox has a more open discussion about it so possibly more community input can help there (both to improve the jxl integration in firefox and to argue in favor of enabling it by default).

oo i found an error, i think i'll put it on github

https://github.com/libjxl/libjxl/issues/407

Thanks, could be a bug in the dct block type selection heuristics. Pinging <@532010383041363969>

There are several approaches that are possible for browser integration. One is to start by slicing out the non-AVIF-competing part, i.e., the lossless coding, and ship that first. Likely it would need another Media type (or just use the existing, and then have another Media type for the full JPEG XL). It seems to me that lossless jpeg recompression doesn't compete with AVIF, and possibly the same for lossless pixel compression (similar to PNG and WebP lossless), possibly also delta palettization. Another approach is to wait for some adoption and enthusiasm and show that JPEG XL is a significantly more attractive offering than AVIF for some of the needs (such as photography). "The water will always find a way." Another approach is to get several AOM members (such as Facebook, Netflix, Adobe, etc.) enthusiastic and deploy JPEG XL in their systems, and them bringing their enthusiasm to the AOM. Another approach is to work with AOM's video/image quality group to introduce new image quality metrics that better indicate the strengths of JPEG XL approach. Building on WASM, showing it works and is desireable, could help to convince Chrome/AOM. Working with camera manufacturers and/or review entities like dpreview.com could make the photography value more clear to AOM/field.

One practical piece of evidence that could help to convince AVIF is to show that JPEG XL is one generation ahead. We could do a human study that shows the difference between Mozjpeg->WebP, WebP->AVIF and AVIF->JPEG XL differences. If we can show that AVIF to JPEG XL is a larger jump than Mozjpeg to WebP and/or from WebP to AVIF, then it might be launchable by AOM's own criteria, and possibly could be placed on AOM's roadmap of open Web platform codecs. My own experience and evidence that I have is that JPEG XL is the only modern codec that significantly improves the median and average image byte use case, at around 1-2 bpp, and if a study is able to focus on the average image byte (instead of 0.2 BPP images), it is not difficult to show a 30+ % improvement from AVIF to JPEG XL.

In my opinion, slicing up the format and splitting it into different parts is not the best solution and can cause more problems than benefits in the future, it's better to choose other ways by all means. And as I said before, even if support in browsers is not enabled by default, if there is a possibility it is worth to improve its functionality, for example progressive decoding, faster lossless decoding, possibly consider multithreading for large images (in Firefox it already works) and other useful features for Web usage and there is time for that, I don't think it's better to do it in haste, only after enabling by default. And to demonstrate lossless benefits, it is also worth having a more optimized option that would be most useful in practice and I think that is something closer to WebP lossless, i.e. fast enough in speed, but also more efficient than other formats (currently JXL is denser in compression, but not always better in speed/efficiency, also sometimes decoding speed may not be fast enough on large lossless images) Also do not forget about the importance of Windows users as the most popular non-mobile OS and the need to at least support and update the official builds and something like WIC decoder (until there will be similar from Microsoft, but for example their AVIF decoder is not the best and can not properly decode most of the images)

windows 11 is enough; i 100% agree with scope; with apple you can talk seriously later when there is an event or something

<@!532010383041363969> Can JPEG support be added to the JXL decoder to promote it as next-gen "Jpeg to piXeLs" converter? This wouldn't collide with AVIF and the use of decoding actual JXLs would be just a little bonus.

guetzli 2.0 won't happen

What does Guetzli have to do with image decoding?

jpg image encoder with some jxl optimizations was called a guetzli 2.0 by jyrki and he told that it can happen in this year or next year https://discord.com/channels/794206087879852103/872039185220001892/872197235595673611

This doesn't answer my question: What does your comment have to do with my initial post?

ok, i understood

Yes, we could do this and likely add 10 bit framebuffer dynamics to it, too, so that 'good old' jpeg could be used for HDR10. Would you consider adding an issue for this?

<@!532010383041363969> Is that issue visible enough or should I create a new one on GitHub?

I don't think that we should duplicate GitLab issues on GitHub.

I don't think there's anything wrong in doing so - I don't know how much we'll look at gitlab issues...

Feel free to duplicate any gitlab issue on github, and then link to it on the gitlab issue so it can be closed there.

I see. I thought you meant that we could build a new universal jpeg decoder -- for example for Chrome integration.

While we're at it... JPEG XT and Knusperli integration, please? 🥺

...and epf 🙂 ?

Hey there! After writing Jon on Twitter, he forwarded me to this Discord. Happy to get to know you, guys. My name is Justin and I am one of the creators of avif.io. In disregard of our AVIF solution, we are also currently building a JXL converter with C++, emscripten, WASM & libjxl. Now, for our avif solution, we show users the conversion progress of a single file. I can't seem to find an option for this in libjxl, but I'm also known for being a little blind. Do you offer this type of granular progress tracking?

A note about the migration to GitHub should probably be added to the readme on Gitlab. The only place it is currently mentioned is in the one issue saying not to make more issues.

<@768090355546587137> do we have callbacks for progress tracking in the encode api? I assume gimp/photoshop would also want that...

GitLab mirrors GitHub, so I don't think that it'd be possible to add info to just GitLab and not GitHub.

Fair. It could be added to the Gitlab description text, but if the Gitlab is going to remain up to date, then it's not too critical.

I'm revisiting old GitLab issues, are those issues actually fixed (they have `fixed` label)? https://gitlab.com/wg1/jpeg-xl/-/issues/85 https://gitlab.com/wg1/jpeg-xl/-/issues/182 https://gitlab.com/wg1/jpeg-xl/-/issues/199

first one yes

other two should be going by the comments

<@!794205442175402004><@!179701849576833024><@!532010383041363969> Also, `--resampling` still does not work with speeds higher than `-s 7`

Can I poke someone here to get a new release of brotli? We are having some problems with a static jpeg-xl build in ImageMagick. Someone told me that this fixes it: https://github.com/google/brotli/commit/09b0992.

I'll ask

We will make a new release -- but it will take some time for us. Would two weeks work for you?

<@!693227044061839360> would you file a public issue on this on github.com/google/brotli? Please indicate the time frame you need the release. The main person resposible is out-of-office right now, but we can rotate the duties if this is urgent.

<@!693227044061839360>

This is not an urgent matter, only an issue for people who want to use jpeg-xl statically together with ImageMagick

So two weeks would be okay

Do you still want me to open an issue?

the likelyhood of us forgetting about it if it's not urgent and there is no issue is somewhere around 110%

*shameless ping* <@768090355546587137>

Hello. This is my first time on discord. I have a question about how to process a JXL file that has different original and data profiles. The original is an ICC profile, and the data profile looks like something JXL uses internally. Which profile should be used when decoding the file?

The profile you get from the decoder :)

Both profiles can be obtained from the decoder by passing JXL_COLOR_PROFILE_TARGET_DATA or JXL_COLOR_PROFILE_TARGET_ORIGINAL to JxlDecoderGetColorAsICCProfile(). Some images seem to need DATA, others work better with ORIGINAL. If I ignore the color profile, everything seems to work fine, but I get screwy results when I try to use the profiles.

that seems odd, in theory the decoder ought to return you pixels in the JXL_COLOR_PROFILE_TARGET_DATA colorspace...

When I use JXL_COLOR_PROFILE_TARGET_DATA, 3/4 of my test images appear to decode correctly. Notably, `djxl` decodes only 2/4 of them correctly. I'll look at the code I'm using to encode to see if I made a mistake. It may have to do with setting linear/gamma correctly.

What colorspace conversions is the encoder doing behind the scenes? I know there's RGB to XYB when encoding (whatever that is), but then it converted back to RGB during decoding (?) So... say, I encode an AdobeRGB image. When it's decoded, is it still AdobeRGB, or is it something else?

<@!768090355546587137> <@!604964375924834314>

djxl converts back to the original space (which is why it needs lcms/skcms), the libjxl_dec api cannot always do that though because it doesn't depend on lcms/skcms - so if the original color space is exotic (some weird arbitrary ICC profile that does not correspond to one of the 'known' (enum) color spaces like sRGB/P3/etc), it might e.g. convert XYB to linear RGB and return a color profile that corresponds to linear RGB (instead of the original one)

> 'known' (enum) color spaces Is there a list somewhere?

in the spec and in the code, but basically it's anything that can be expressed as whatever RGB primaries + whitepoint + a transfer curve that is either a pure gamma curve (including linear), the sRGB transfer function, the PQ one or the HLG one (if I didn't forget any)

so I think that should cover most of the common RGB spaces, like sRGB, Display P3, DCI-P3, AdobeRGB 1998, ProPhoto, Rec.2100 (PQ or HLG), etc

[list is at `include/jxl/color_encoding.h`] ... So if I start from an AdobeRGB original... compress to jxl... jxlinfo reports the "original" profile is an ICC profile and the "data" profile is a "JPEG XL encoded color profile". Then I decode to back to a viewable image... is it [supposed to be] in sRGB (or similar)? As far as I can tell, that's what's happening. If I apply an AdobeRGB profile, the colors are wrong.

Are sRGB-compatible profiles (TinysRGB, sRGBz etc) treated as if they are sRGB (regarding transfer function, I suppose)?

if they're close enough, then in lossy mode, yes, there are tolerances and "close enough to sRGB" will be treated as if it is sRGB. In lossless mode, it always stores the exact ICC profile just to be sure.

it is supposed to be in the profile the decoder returns - this can be anything really: if lossless encoding was done, it will be AdobeRGB, if lossy was done, it might be linear sRGB it gives you, or it could be something else (iirc you can ask the decoder to 'try' to give you a certain enum colorspace, which it will do if the image is XYB and it has to do some conversion anyway, and it will not do it if the image is in (a different) RGB)

at least that's how I understand things

<@!768090355546587137> / <@!604964375924834314> please correct me if I'm wrong

mhhh, that seems to imply that the "original" profile is not actually representable by the enum. Did you encode it with lossy or with lossless?

I'm encoding lossy. Whatever profile I send to the encoder seems to just get attached as the original profile. If I don't attach anything, the "original" and "data" profiles are the same. I don't know how to read an ICC profile to get the parameters to let the encoder use an internal profile. / For decoding, I don't know how to send an ICC profile to the decoder. I know how to get it to give me the ICC profiles it finds in the file, but otherwise, it just seems to do its own thing. / Are the specs available anywhere, or will the standards be locked behind a paywall? / As far as the color profiles are concerned, it's fine with me as long as I know what to expect.

lossy will encode in XYB always and I think it will decode to linear sRGB in most cases (but probably sRGB if you decode to integers), unless the original profile is represented with enums (which AdobeRGB might be but we might not detect correctly)

"lossy will encode in XYB always" – So if I set `info.uses_original_profile` to true, it produces a jxl file where there is only one profile (AdobeRGB in this example), and the image displays correctly after decoding when that profile is applied. Is this against the specs? (Lossy compression, with `distance = 1` by default.) // Sorry, I'm not thinking clearly... XYB is when it's encoded/compressed... but then it gets decompressed/decoded to another profile... so if there's only one profile attached, it's reasonable for it to apply that one. The problem is when there are two different profiles attached or specified. Mainly wondering if what it seems to be doing (decoding to the "data" profile/sRGB) is what it's supposed to be doing.

<@!768090355546587137> likely know the answer best

"decode to linear sRGB in most cases" – When playing with linear vs perceptual images... It seems like linear integer and perceptual floating formats don't display correctly. Looks like the gamma curves get applied twice. Maybe once by the decoder and again by the viewer.

The way to see it is not that the image displays correctly. The decoder gives you numerical pixel values, and it also gives you the color profile these pixels have. If this color profile happens to match your screen, then it displays correctly. If the color profile is different, you should convert from the profile JXL gave you to the profile you wish to display the pixels as

I didn't notice before, but the `jpg` files generated by `djxl` when decoding to pixels have an ICC profile attached. However, Exiftool reports "Invalid ICC Metadata data".

what happens if you decode this same image to PNG?

`djxl -h` says "--color_space=RGB_D65_SRG_Rel_Lin defaults to original (input) color space". / I tried a few different `jxl` files... with different results... think the invalid profile one had an AdobeRGB profile attached. / The generated `png` files have no profiles attached. They all look like they're targeting sRGB (even the AdobeRGB image) because they display as intended when I turn off color management on my viewer.

when using the API: for display, use JXL_COLOR_PROFILE_TARGET_DATA: this is the profile that the API gives you the pixels in. The other one, JXL_COLOR_PROFILE_TARGET_ORIGINAL, is only metadata and tells what the original image was in, but is not (at least not necessarily) what the pixels are in. In case of uses_original_profile=true then data and original will match. Also, the decoder can only return you the pixels with this profile, the decoder library at least has no CMS like skiacms or lcms built in to be able to convert it to anything else In case of uses_original_profile=false, then the decoder will convert it to a data profile for you (but also because it must e.g. for blending which must happen in the original profile as long as possible without needing a CMS, and because RGB rather than XYB output is requested) to one that the decoder knows (it can convert from xyb to a certain set of RGB profiles, including sRGB, PQ, HLG, ..., but not AdobeRGB). The JXL_COLOR_PROFILE_TARGET_DATA will tell which it is.

AdobeRGB should be representable by an enum, it is just some specific primaries and a gamma 2.2, so in principle we can do that in the enum, no?

Thanks... that's helpful for deciding which settings to use. / The `djxl` help output states it uses the original colorspace though. Does that need to be corrected or am I misunderstanding what that option is?

djxl does actual conversion to the original space and bitdepth, because most of the output formats are integer-based so you cannot have negative or higher than maxval values (which you could get for out-of-sRGB-gamut colors)

So the API and `djxl` have different behavior... That makes it troublesome for using colorspaces other than sRGB.

The api is made to avoid doing an unnecessary convert from XYB to original space if all you want to do is display the image in display space. E.g. if original space is 8-bit AdobeRGB, display space is DisplayP3, then it would be silly to convert the internal XYB to 8-bit AdobeRGB and then (at some point) convert that to DisplayP3. It is more accurate and faster to skip the AdobeRGB intermediate.

Having the decoder do color management seems to add a layer of complexity. Most other image formats don't do anything with color management so the viewers, editors, and operating systems have to take care of it. Throw in an image format that does its own color management, and color profiles may end up being applied multiple times.

from the point of view of the viewers, it’s not that different, is it? the viewer gets pixel data and in which colorspace it is, as it always would

Using the API, the problem I was having earlier was knowing which flag to send to the decoder: JXL_COLOR_PROFILE_TARGET_ORIGINAL/DATA and knowing what color profile to apply for display. There are 4 combinations, and no one setting consistently gave results I was expecting (which is for the image to appear the way it did when it was saved). It looked like gamma curves were being applied twice in some cases.

all DATA 🙂

You don't need to 'apply' a color profile after decode (in the sense of doing a color conversion), you just need to 'attach' the profile to the pixels you get (i.e. interpret the pixels as being in the color space defined by the profile)

Not sure what you mean by send to the decoder by the way: you can request the original or the data one (or both) from the decoder, it's a getter, it doesn't set anything

Unless you mean the flag of djxl. And now that I think of it, you can indeed also set an optional profile to the jxl decoder in the API, only used in rare circumstances. Ask if you want the full details 😄

<@794205442175402004> "interpret the pixels as being in the color space defined by the profile" ­– doesn't that result in color conversion when displayed? / <@!768090355546587137> I don't really know what I'm doing... I'm probably getting the encoder and decoder mixed up, which further contributes to the problem. What I normally think of with camera jpgs, is the bits are what they are and the profile is just in the metadata for interpretation. but with jxl, it looks like the ¿decoder/encoder? may actually be doing something with the profiles besides just attaching it to the metadata.

It depends again on uses_original_profile if true, then the encoder and decoder both do the same as most other image codecs like png, jpeg, etc...: they just encode/decode numeric values without any conversions to other profiles, and the attached profile is the profile those pixels have if false, then the encoder will eventually get the pixels in xyb, which is its own absolute color space. But just like any other color space, you can convert it to/from anything. The fact that the API doesn't include a color management system, means the encoder/decoder can't do any arbitrary conversion

but you still can do it, the decoder gives all info (pixels + color profile) neede to use a CMS to do any conversion similarly, encoder requires pixel format to be in something it knows (can convert to xyb itself) when using uses_original_profile = false

cjxl/djxl *do* include CMS, so they can convert more, and do so when encoding to/from png or jpg, using the color profile of png and jpg as intended (when reading, and when writing)

The lossy encoder needs to know the color profile of the input pixel values, otherwise it cannot convert to XYB and "know what it is doing", perceptually speaking (it's not a black box encoder that encodes arbitrary numbers with some loss, it does something perceptual). The lossless/modular encoder doesn't need to know the color profile, it just encodes the numbers you give it and doesn't (have to) care about what they mean.

In any case when encoding you need to make sure that the color space you claim the pixels are in, is correct (don't just claim everything is sRGB even if it isn't or something like that).

If I set uses_original_profile=true, does that switch to the modular encoder? I noticed file sizes look like they double. It's still encoding lossy though... the lossless encode is 10-20x the size. // I don't understand at all the pros/cons of having both the vardct and modular encoders.

For practical purposes, lossly needs xyb and uses_original_profile=false indeed So even with the behavior it has when false, with the data profile, it should be possible to eventually use and display images with any profile, including AdobeRGB

As long as you have a CMS (skiaCMS, lcms, or part of the OS, display method or other libraries you use) it's possible

If djxl produces a PNG without profile that the original PNG had, or JPEG with invalid profile, that may be a bug by the way

The reasoning is as follows: for lossy, it is fine to do color conversions because rounding errors don't matter, and better compression results can be obtained by using a perceptually relevant colorspace. Unlike YCbCr, which is not an absolute space (it can be applied to different RGB spaces and have different meanings) and also not very perceptual, jxl uses an absolute color space for that, which works for both SDR and HDR and any color gamut or bit depth. In the XYB case, the color space/profile and bit depth given in the jxl header is mostly just informative - you don't need it to interpret/display the pixel data, which is in XYB anyway, but it's useful in case you want to choose a representation to convert to if you want to save it to png, for example.

For lossless, XYB cannot be used since it is not reversible exactly. The only kinds of color conversions you can do with lossless are simple RCTs (reversible color transforms) like YCoCg. In this no-XYB case, the colorspace/profile and bit depth in the jxl header are crucial information to interpret/display the pixel data.

To make things easier in the decode api, the decoder just always returns pixel data in the format you request (uint8, float32, ...) along with a color profile that says how to interpret the pixel data.

There may be problems with some of the ICC profiles I was using. GIMP works with them okay, but it looks like my other image viewer doesn't understand all of them. Maybe they don't all work with skcms. / There's always learning with new stuff. I'm probably overlooking something simple.

Thanks for your help everyone.

There are currently no callbacks for progress tracking in the encoder, but sounds useful. Do you happen to have experience with how other image codecs do it in good ways?

Sorry for all the color questions... when I use JxlDecoderSetPreferredColorProfile, it doesn't seem to have any effect on the decoded output. Is there something I'm probably missing to use it correctly? Also, I can't find in the libjxl source where the transfer functions are applied. I just see lots of flags being passed around, like kSRGB and similar.

libjxl progress callback

It sets a preference, but it doesn't guarantee that you will get what you prefer. You always have to use the data profile.

Is there planned to be a function to force the color profile? Or a function to find out if the profile will be ignored? The problem I'm looking at right now is when using `decoder_oneshot` on a non-linear `jxl`, the output is nonlinear, but it seems that `pfm` files are expected to be linear. At least, that's how GIMP interprets them.

transfer functions are implemented here: https://github.com/libjxl/libjxl/blob/main/lib/jxl/transfer_functions-inl.h

the preferred color profile cannot be forced because the image can be in an arbitrary icc profile space and libjxl_dec cannot convert from that

the pfm has to be interpreted according to the icc profile, not in a default (linear) way

when I use 'assign color profile' in GIMP, it makes no difference.

maybe try `convert decoded.pfm -profile decoded.icc decoded.png`

or something like that

That's interesting... ImageMagick also seems to ignore the profile, but interprets `pfm` files as non-linear (vs GIMP interpreting them as linear). ImageMagick reads the profile, but it makes no difference in the `png` output. I suppose I can just consider this an idiosyncrasy of the PFM format. // Thanks for the help.

pfm and ppm are formats that just store numbers, and how to interpret them is not really specified

one convention is that ppm is sRGB by default and pfm is linear (with sRGB primaries) but that is just a random choice and not everything makes the same choice

Mhhh, at least some of the things in the issue have been solved - but you're right that we should probably at least reply :)

Sorry if this is the wrong channel to ask in... does the API support making jxl files with multiple frames? I'm calling JxlEncoderAddJPEGFrame() multiple times, but djxl isn't able to process the result.

... please file a bug? 😄

If it's not supposed to be used that way, it isn't a bug...

I don't know for sure, but I feel like it should work

hence opening an issue is likely a good idea, so people that actually know can either answer or fix it 😄

I'll look through the code and play around with it a bit more. I'll file a bug if I don't find anything.

I'm thinking about trying to get the API to support 16-bit float and 32-bit int. It looks like the problem is ConvertFromExternal() infers float vs int based on bit depth. It looks like it's called from only a few files. Maybe a function could be written to wrap a modified ConvertFromExternal. Then the wrapper function could be removed when the existing calls are updated to use the new function. Is this something I should bother trying, or is it something that devs more familiar with the codec should be doing?

mhh... I'll ask

I don't personally see an issue

Thanks. It looks like the encoder API should already support float16 and uint32 if that function didn't assume that 32 = float and 16 = int. There are some TODO comments to expand support, but I don't see how without making some changes to the function. Think it would be good to do before it's used in too many files. The decoder already works with float16. Don't know about uint32.

uint32 is a bit tricky because you cannot do many things if you want lossless

and you risk overflows and all

also I'm not sure there is a lot of use for 32-bit per channel 😄

I think we have a TODO re: inferring float based on bit depth

oh, you already said that, my bad

uint32 we cannot do in modular with the current code, it uses int32 buffers

For lossy it should work though? I think just adding `bool float_in` as a parameter would work (for lossy).

is there anything that works with 32-bit ints?

16-bit ints is common, and so is 16-bit float. Anything I know with more bits uses float (and I have only seen FP24 or binary32 so far).

(also note that there are two kinds of 16-bit float, there's binary16 with 5 exp bits and there's bfloat16 with 8 exp bits)

The type is named `JXL_TYPE_FLOAT16` and `jxlinfo` with `jxl` encoded from `exr` with `cjxl` reports 5 exp bits. I'd think bfloat16 would need a new type, like `JXL_TYPE_BFLOAT16`. Re uint32; if there weren't a type for it, I wouldn't have thought to bother. GIMP has a setting for uint32, but I don't think it's actually used by anyone for anything. It was probably added as future proofing.

I think for jxl we shouldn't add too many io formats - I would try to have only those that are actually used (somewhat commonly) by applications. I think that's uint8, uint16, binary16, binary32.

Possibly bfloat16, I dunno

go ahead and do it 🙂 at least for FLOAT16... BFLOAT and U32 can wait until somebody actually needs those 🙂

what about rgb565? does this have a place in libjxl? I was thinking just as an output format

how common is that? I'd think it's simple enough to convert to RGB888, but...

also the decoder cannot output it IIRC

<@179701849576833024> Thanks... I'll go ahead and work on getting float16 working with the public API. I'm pretty sure the rest of the encoder is already set up for it because `cjxl` converts `exr` using float16.

or maybe you'll find new and interesting bugs, you never know 😛

If the bugs are too interesting, I'll need help. I don't know anything about how the compression algorithm works.

we'll help if needed, no worries 🙂

So I found the answer to my question about calling JxlEncoderAddJPEGFrame multiple times... apparently it's not fully implemented yet. So it's producing bad output when used that way. Maybe I can look at it and see how feasible it would be for me to change.

Suppose a `jxl` file has an ICC profile that skcms is unable to interpret. Currently, `djxl` quits with an error. Would it be better for it to issue a warning and just attempt to decode the file using some standard default?

Also, what is the rationale for allowing only one of JxlEncoderSetColorEncoding or JxlEncoderSetICCProfile to be used? In its current implementation, JxlEncoderSetICCProfile doesn't parse the ICC profile. So the internal color encoding won't necessarily match the image. Perhaps it should be renamed JxlEncoderAttachICCProfile (or a new function created)? Then JxlEncoderSetColorEncoding can be used to set the encoding settings and the ICC profile attached separately?

I believe the "doesn't parse the ICC" part is not intended behaviour... File a bug?

is it not? don’t we currently rely on a CMS for ICC parsing?

do we want to have a CMS-free encoder too? I thought that was only a concern for the decoder

what would make sense to me is an api where if you don't provide CMS callbacks, you can only encode Enum colorspaces and decode without CMS (so either to a given Enum space if the image is in XYB, or to original space if the image is not)

and if you do provide CMS callbacks, it can encode anything and decode to any target space

False. BSD 3-Clause is not incompatible with the GPL.

i think they're talking about libjxl's specific patent grant, not BSD 3-clause in general

Apache 2 is IIRC not incompatible with gpl-2 either... But IANAL

Nothing stops you from taking libjxl _without_ the patent grant, if you think that somehow gives you more rights

By not tying the copyright grant to the patent grant, as we did before with the Apache 2 license, it can only give you more rights, not less, afaiu

https://dwheeler.com/essays/floss-license-slide.html says it’s only GPL 3

the 3-clause BSD is “BSD-new”

in all of this the question is exactly what does "compatible with" mean in the context...

Compatibility sounds like an undirected/symmetric thing, but it's actually a directed thing if you look at that diagram

Also it might be useful to make a version of that diagram that includes "generic proprietary software license"

well as far as I'm familiar with it, the patent grant says "you can use it for any of these things royalty free *except"* and if the patent grant had simply been omitted, there would be no promises the patent grant just is a guarantee of certain rights under certain conditions

yes, it seems the exception is only for itself

not for the “regular” license

that's the main difference between BSD3+PATENTS and Apache 2.0: in the Apache license, the copyright license is conditioned on not doing patent litigation. Such a condition is not compatible with GPLv2 (which has other conditions but not that one), but it is compatible with GPLv3.

as far as I'm aware though, GPLv3 has a bunch of restrictions in it that many people find unsatisfactory. restrictions not in GPLv2

<@&803357352664891472> What are your current priorities regarding JXL?

For me, current priorities are: - jxl adhoc group meeting tomorrow (mostly about fixed point / hw implementation) - preparing everything for the October JPEG meeting (conformance, first draft of 2nd edition of 18181-1, etc) - quality assessment (new JPEG AIC activity, getting subjective results to get more insight in jxl and avif encoder performance) - libjxl API maturation - adoption encouragement - tooling improvements - knowledge dissemination (blogposts etc) - encoder improvements

Is the 2nd edition of the spec just to clarify points and best practices that were vague in the first one?

Yes, to integrate the profiles&levels amendment and to fix spec typos and clarify stuff. No new features or extensions or anything exciting.

(I don't really believe in extensions/new features in a widely used interchange format. It is what it is and that's it. Only if it is only used in use cases that are relatively niche/professional and where you can update everyone involved, I think it is really possible to add new features/extensions.)

Faster decoding with high quality options (such as Gaborish and possibly even EPF) seem to be enablers -- currently the fastest decoding to enable JPEG XL on old android turns many improvements off (like EPF and Gaborish) Reacting to users' feedback, possible security findings, image quality findings (like those from Lee) as well as finalizing the API are pretty high in the priority list.

Also about decoding speed in browsers, Chrome still does not support multi-threaded decoding per image and the difference with Firefox implementation is very noticeable, up to 5-10 times and higher (depending on number of cores/threads in CPU) and number of images per page I think it's also worth investigating and comparing and it's better to be able to decode each image with multithreading and manage total number of threads in general, than to have no such option and expect that number of images will always be higher than number of free threads

it is a balance between binary size and coding speed -- currently when it is behind a flag, binary size has a larger user count than the coding speed

IIRC it is problematic in some ways, I don't remember exactly which ways

What is the channel <#824000991891554375> for? Like what's there? There's no readme. Just a bunch of data.

in what sense?

ah, it is to post interesting *small* JPEG XL files - i.e. generated to be small, say with https://jxl-art.surma.technology/ - where you can input a text description of a decision tree / spline definition / other fun things (full doc https://jxl-art.surma.technology/wtf.html) and obtain the JXL from it

See the very beginning of that channel: https://discord.com/channels/794206087879852103/824000991891554375/824001294116454420

I see. That message should be pinned to that channel

Done

That kind of info would be more visible in the channel topic.

I would put portability among priorities too.

Yes - anything in particular that needs to be done in that regard?

I hope that MSYS2 platform receives more attention. At least to ensure every release builds easily there and decoding/encoding work without crashes. MSYS2 is inevitable for Windows GIMP, some other image software build Windows versions there too. Windows is not only MSVC.

for what it’s worth, I build very often with MSYS2

although I don’t really use the GIMP plugin

<@!604964375924834314> My 2c — You should use the GIMP plugin. 😝

well, I don't use GIMP 😛

I don't do simple image editing very often :P

for the plugin to be applicable, the editing has to be both in GIMP and involving jxl files

the latter is not yet very frequent as far as I can tell

I also had no problems with MSYS2, but I do not use plugins and only use Clang as compiler, except that problems were and probably still are with GCC and AVX2

oh, right, I use clang too

Hey, I was interesting in writing my own parser/decoder for parts of the JXL spec, however I cannot find any guidance on feasibility (legal wise) of alternative implementations of `libjxl`. The standards themselves seems to be only available behind the ISO paywall, the `libjxl` implementation licenced under BSD-3, but with additional patent grants only granted to `libjxl` project. Would any of the devs be able shed any light as to whether alternative open source implementations actually possible for people to implement or is this a "Use `libjxl` or nothing" situation?

Alternative open source (or proprietary, even) implementations are very possible and encouraged!

The patents are also granted for other implementations, both Google and Cloudinary filed a Type 1 declaration to ISO to make it clear that they intend to make patents universally granted, with the only reservation being defensive: if someone litigates claiming they own patents on things essential to implement jxl, Google and Cloudinary will retaliate by not granting their patents to that patent troll

There are also <https://github.com/libjxl/jxl-rs>

<@!794205442175402004> Thanks for your helpful reply! that does clear it up. P.S. I enjoyed your recent update talk on JXL. 🙂 <@!111445179587624960> Oh nice, didn't see that, I only saw another `libjxl-rs` which calls into `libjxl`. I might end up just contributing to that when I find the time.

contributions are welcome! I started it mostly as a personal fun project, so no promises, but I can certainly at least review 🙂

Cheers, yeah I'm not trying to build something for production (yet). Mostly just trying to satisfy my own personal curiosity of how image formats work, and how I do that is writing it in Rust. 😄

FWIW, reading the C++ code may be a better way to figure out what should be done than reading the spec 😛

Would be good to see if an implementation from spec doesn't reveal any spec bugs though :)

Your direct messages are closed

Updated 🙂

That would require me to understand C++ 😄

Still cannot send you a message or send a friend request so I can send a message

easier than to understand the spec 😛

||*someone trying to leak the spec again*||

Hmm, odd I set it both on a server and global level to allow messages. I've sent a friend request, feel free to unfriend after.

Not sure if the libjxl code is the most readable description of the codec - a naive and slow implementation with a simple and dumb encoder would likely be a lot smaller and easier to understand

I never said it's the *easiest* way - just that it's *easier*

Not sure, the spec is also not a fun or easy read, but at least in the second edition it will be somewhat structured and hopefully somewhat clear

yeah second ed might tip the scales

I am trying to contribute my Qt plug-in to KDE. The KDE developer did tests with valgrind and saw a "possibly lost" memory record. Can you take a look if it is something to worry about? https://invent.kde.org/frameworks/kimageformats/-/merge_requests/41#note_338195

Interesting, that does look like the memory for (default) quant tables doesn't get freed. I wonder why it gets allocated in the first place in a jxlinfo scenario (where no actual decoding happens). Maybe an opportunity to save some memory in the no-decode/modular-only cases? <@179701849576833024>

Mhhh interesting, tbh it doesn't really matter much but there is indeed no reason

Which reminds me that I don't think we ever wrote the code to allow to keep those tables out-of-process

Anyway, they don't get freed because they are stored in static memory

Is the idea that they get initialized only once per process? Are the default quant tables computed?

(as opposed to just a bunch of values that are hardcoded directly? To save binary size?)

And is it possible to share them between different processes?

It's "only" 3 MB but then again when the old jpeg was made, some people couldn't imagine computers with more than 640 KB of RAM...

In order: yes, yes, indeed to save size, you can share them in theory but not in the current code

We now compute all of them all of the time? Might be better not to compute them until needed (the biggest ones will never be needed with the current encoder)

<@!604964375924834314> Would you explain to me very briefly, how JXL is using the 8-entry LUT to achieve noise on images? I'm wondering why the same ISO setting causes different "80 Bit stuff" (those 10 Byte in the header that make noisy images bigger than their counterparts) across different images. Is a given ISO value image-dependent or is JXLs noise in general image-dependent?

the LUT generated by `--photon_noise`, besides the ISO value, depends only on the image resolution: https://github.com/libjxl/libjxl/blob/d182ba3ebeff9868657ff0a103f8fa0002b38f2b/lib/jxl/enc_photon_noise.h#L18

it varies the per-pixel noise in such a way that the noise over a given fraction of the image would stay consistent

in a sense, it assumes a fixed physical viewing size (for example “fullscreen”), rather than 1:1 pixel mapping

Ohhh, I see, interesting! So always doing a 1:1 pixel mapping would result in a constant LUT?

yes, if we were to assume that images with lower resolution have a lower resolution because they are taken from a subset of the “virtual sensor” that we simulate, then they would still receive the same amount of light per pixel, and so they would have the same noise per pixel as well

and so it would look similarly noisy if shown at a correspondingly smaller physical scale than for the higher-resolution image

(but noisier if shown at the same size)

but so this is all encoder-side

this is how the encoder currently chooses to use the ISO parameter to generate an appropriate LUT

on the bitstream / decoder side, the noise is pregenerated as a separate texture, and the LUT simply indicates how much of that texture to add to the image as a function of the XYB values

Or I guess RGB values if you would apply this on e.g. a lossless modular image

unfortunately, there is a bit of dependency on XYB in the way that it works

technically, the bitstream allows having noise in a non-XYB image, but I am not sure that the results would be considered useful in most cases

https://github.com/libjxl/libjxl/blob/d182ba3ebeff9868657ff0a103f8fa0002b38f2b/lib/jxl/dec_noise.cc#L233-L246

(I tried it when I hacked noise into `jxl_from_tree` to test photon noise while it was still a perl script outputing a textual LUT)

Okay, so a function that generates a LUT for `sqrt(Y) * noiseStrength` would be what I'm looking for, right?

that sounds plausible, I am not 100% sure about the sqrt but probably something that looks like that equation, yes

(and the sqrt is definitely worth a try)

when the noise is applied in sRGB, it becomes a bit more colorful as you can see here

Y from XYB is linear light from 0 to 1? So sqrt would be a simple gamma conversion. (btw, I hate slow mode ^^)

sadly it’s a bit more complicated, it’s neither linear nor restricted to 1 😄

the exact relationship is https://github.com/libjxl/libjxl/blob/d182ba3ebeff9868657ff0a103f8fa0002b38f2b/lib/jxl/enc_photon_noise.cc#L60-L61 but it’s roughly cubic

But at least this conversion already exists. So, all in all, how much work would it be to add an option `perceptual_noise=X` that creates a noise LUT with (roughly) even amplitude across the brightness (with 1:1 pixel mapping)? 😇

mostly plumbing (in the manner of https://github.com/libjxl/libjxl/pull/307) + determining the correct equation

it would even be possible to do the latter before the former, by just hacking `enc_photon_noise` such that it doesn’t do what it currently does anymore 😄

and then once it works, actually do it in a separate module

What is the exact function? Could somebody (secretly) screenshot the mathematical formula from the spec?

thx, got it. You can delete it now, before someone sees that. ^^

I think it is fair use to quote snippets from the spec like that

if it isn't, then it's up to ISO to send me a cease and desist letter, I guess

ok, so the 8 LUT entries just map to linearly interpolated parts of Y from 0 to 1 (anything above 1 just uses LUT[7]). If we would live in a world where Y ~ brightness then I guess a noise parameter from issue #900 could simply be duplicated to each LUT entry, right?

might work indeed

this doesn't sound very confident :D

that's just how I am in general, don't read too much into it 😁

Asan and windows builds are currently failing on main, is someone taking a look at that?

it seems that the ASAN failure started with https://github.com/libjxl/libjxl/commit/ee924953eb2d2ecbd2a32f7efde898eeff26ec70, not sure if Eugene is aware

the windows builds is a simple fix too simple but also opinionated that i don't feel comfortable making a pr for

what’s the problem with the Windows one? I don’t see the actual error

ah, never mind, found it

hadn’t realized ^F was not functional on that page…

im unsure what the style for libjxl or in general is for the c++20 initializer. for firefox, it's `/*.thing =*/thing,`

for us, it’s close, I think `/*foo=*/bar` would be most common

it’s what my fix does

are there plans to/ is someone adding devtools to the builds?

afaik asan is not working on windows, gcc or clang, at least last time i tried

We are struggling a bit with libpng

Can you check if https://github.com/libjxl/libjxl/pull/976 helps?

setjmp, horror !

Libpng's way of error handling

Libjpeg's way too btw

That's how it was done in the 1990s

Would it be useful/beneficial if fjxl could be used for alpha of VarDCT images?

currently we do slightly lossy modular for alpha of vardct

using fjxl would make it encode faster but density would probably suffer, and also there wouldn't be progressive previews of alpha

(the advantage of doing slightly lossy is that it also gives lower res previews)

we don't need to be *that* fast for alpha anyway 😄 there's many intermediate steps that are more reasonable tradeoffs

👌

Would it be useful/beneficial if fjxl could be used to realtime-compress a video capture (like desktop, presentation slides, ...) with new frames only storing the difference to the previous one?

Yes, but because of screen content modes in other modern video encoders, it would be more efficient and faster for the job to just use them instead.

Also for true lossless 8 Bit?

Not sure if it would be *faster*... But for sure more efficient

In principle a video-fjxl could be done but I don't really see why you should

Yeah, not at all for lossless then 😛 Screen content tools in video encoders do utilize lossless transforms, but the resulting video is still in 8-bit YUV.

For screen sharing it wouldn't be the worst idea to use jxl, I suppose. Could do streaming encode and decode, and encode cropped frames with only the part that changes.

But seems easier to just use a video codec

If the use case is specifically a slideshow or something, then doing that as jxl (or even apng) is probably possible, but tools and viewers are probably not going to deal well with long animated jxl/apng (e.g. they'll show no playback controls)

Use-case would be something like recording a tutorial. You can store the (small) lossless fjxl for later editing or archival reasons locally while a version converted to VP9 or AV1 can be shared online.

Well, there are other lossless video codecs much more suited to the task then

So should it be possible to create fast lossless image version from these codecs as well or borrow ideas? Would be interesting how they compare.

Just did a quick test with Logarith Lossless Codec (which is the only "good" realtime lossless video compressor I know of). A 21 sec desktop recoding flipping through a few windows and moving some around results in over 600 MB file. Converting that to a lossless animated WebP resulted in less than 19 MB. So FJXL could be around 30-40 MB which would be 20 times better if it could be used realtime.

x264 lossless

Just use ffvhuff or ffv1. Lagarith practically does nothing.

Conversion to ffvhuff resulted in over 1 GB, ffv1 was still over 500 MB.

strictly speaking, isn’t this lossless only with RGB matrix instead of Y′CbCr? is compression still decent then?

hm, I have a 1h24m 320×200 recording (prince of persia 2 playthrough), I guess I could give it a try and compare x264 lossless RGB and x264 lossless Y′CbCr

results are in PCM audio (49716 Hz, 16 bits, stereo): 1002 MB zmbv as recorded by DOSBox: 77.7 MB x264 ll, Y′CbCr: 302 MB x264 ll, RGB: 353 MB

(flac compresses the audio to 262 MB)

ffv1 is slower and compresses ~100× worse than x264

stopped it as the file was already 2.1 GB after 5:40 of footage

So why even bother with FFV1 if x264 is better?

caveat: this is just one file, with a specific type of content

but it does raise the question, yes

I think ffv1 is just too stupid to do duplicate/cropped frames, so it explodes

For movies where that doesn't help much, I think it is better

I also tried yuv444 x264 and was surprised how good it worked and sad about neither ffmpeg nor OBS Studio supporting rgb24. <@!604964375924834314> How did you get RGB to work with x264?

ffmpeg -c:v libx264rgb

with `-qp 0` to make it lossless

Compared to fjxl, x264rgb is still very CPU-heavy when moving windows (not realtime on my machine) while ultrafast is twice as large regarding file size. So a video codec based on fjxl would still be a good idea. ;)

i tested with a very naive approach and it was 4x larger than lossless x264 on my test video speed wise it was also much slower (though this shouldnt be taken account for because like i said, it was a very naive approach) its also worth mentioning that the decode speed is also a big part of video, not just encoding speed

Merry Christmas to all in JpegXL House, and to all a good night.

H.264 is really designed for YUV so 4:4:4 is going to outperform RGB even in lossless mode. That said, ffv1, utvideo, and magicyuv are all solid choices for screenrecording with ffmpeg

Whats the best way to get into jxl development? any loose ends or projects in need programmers?

I suppose you can check the libjxl github issues and make a pull request to resolve one of them?

definitely many, although I am not sure what would be a simple way to start...

regarding this issue: https://github.com/libjxl/libjxl/issues/1038 is there a reason libjxl uses C++11? I was able to change CXX_STANDARD to 17 without issue, and it would allow this issue to easily be solved, as well as make things easier by being able to access C++14 and C++17 features

id guess compatibility with distros using older compilers

I'd understand that to a degree, but compilers have had almost full support for C++17 since before even 2017, and I would tend to feel that supporting 5-years outdated software is a bit on the silly side

I'm probably in the minority, I do all of my work in the latest C++ and I always find it difficult to go back to significantly older versions, C++14, C++17, and C++20 introduced so much amazing QoL

Wow that's really surprising, I pity the devs stuck using that 😄

It's fairly standard practice in C and C++ to code to older versions of the language. I have yet to see a major C project that codes to a standard later than C99.

on the other hand, the fact that they chose C in the first place for their project means that they did not choose C++

which suggests specific reasons for choosing C which might be lost by using a “too modern” version

arguably for old centos and debian versions its irrelevant as libjxl aint going to really land there anyway, no?

I assume it is mostly cases where they are mandated from up high or have critical software that only runs on old versions, but still want some new features.

Also, judging from posts on encode.su and some of my tests, it seems that official and nightly builds from Github are significantly slower (like 2-3 times slower on `-e 9`), I think if it is possible, it is worth changing the compiler to Clang, if MSVC is still used there <https://encode.su/threads/3520-WebP-2-experimental-successor-of-the-WebP-image-format?p=72710&viewfull=1#post72710>

Nightly `768 x 1024, geomean: 0.03 MP/s [0.03, 0.04], 10 reps, 8 threads` `885 x 435, geomean: 0.10 MP/s [0.08, 0.12], 10 reps, 8 threads` Clang `768 x 1024, geomean: 0.05 MP/s [0.05, 0.05], 10 reps, 8 threads` `885 x 435, geomean: 0.16 MP/s [0.16, 0.17], 10 reps, 8 threads`

Wow that's a big difference between compilers...

Also <https://encode.su/threads/3564-JXL-version-0-3-released?p=72763&viewfull=1#post72763>

``` C:\Users\XXXX>powershell -Command "(Measure-Command {C:\Users\XXXX\Documents\zComp\cjxl070p.exe -d 0 -s 9 -g 3 -E 3 -I 1 C:\Users\XXXX\Desktop\sheep\sheep_247_22608_177.png C:\Users\XXXX\Desktop\sheep\sheep_247_22608_177_jamaika.jxl | Out-Default}).ToString()" JPEG XL encoder v0.7.0 0.7.0-33e0c34 [Scalar] color_hints.cc:56: No color_space/icc_pathname given, assuming sRGB Read 800x592 image, 13.8 MP/s Encoding [Modular, lossless, tortoise], 8 threads. Compressed to 537811 bytes (9.085 bpp). 800 x 592, 0.01 MP/s [0.01, 0.01], 1 reps, 8 threads. 00:00:52.7404860 C:\Users\XXXX>powershell -Command "(Measure-Command {C:\Users\XXXX\Documents\zComp\cjxl.exe -d 0 -s 9 -g 3 -E 3 -I 1 C:\Users\XXXX\Desktop\sheep\sheep_247_22608_177.png C:\Users\XXXX\Desktop\sheep\sheep_247_22608_177_scope.jxl | Out-Default}).ToString()" JPEG XL encoder v0.7.0 36ece47 [AVX2,SSE4,SSSE3] Read 800x592 image, 25.5 MP/s Encoding [Modular, lossless, tortoise], 8 threads. Compressed to 537811 bytes (9.085 bpp). 800 x 592, 0.01 MP/s [0.01, 0.01], 1 reps, 8 threads. 00:00:37.9698896 C:\Users\XXXX>powershell -Command "(Measure-Command {C:\Users\XXXX\Desktop\cjxl_official.exe -d 0 -s 9 -g 3 -E 3 -I 1 C:\Users\XXXX\Desktop\sheep\sheep_247_22608_177.png C:\Users\XXXX\Desktop\sheep\sheep_247_22608_177_official.jxl | Out-Default}).ToString()" JPEG XL encoder v0.7.0 36ece47 [AVX2,SSE4,SSSE3,Scalar] Read 800x592 image, 28.0 MP/s Encoding [Modular, lossless, tortoise], 8 threads. Compressed to 537811 bytes (9.085 bpp). 800 x 592, 0.01 MP/s [0.01, 0.01], 1 reps, 8 threads. 00:01:26.0886139 ```

that first one is compiled for Scalar only, no SIMD at all

second assumes at least SSSE3 is available

no clue why the third one is slow though

Yes, the first one as I understand it is a Jamaika build and it has an old CPU and a strange manual compilation The last two are mine and the official build

is the speed difference only for modular encoding or also vardct?

if the issue is SIMD, I would expect an even bigger speed difference for vardct

if the issue is crappy compiler optimization, I would expect mostly modular to be affected

could also be that the official build is somehow a debug build instead of a release build or something

Mostly for the slowest modular modes, but I have not done a lot of comparisons, but it is most noticeable, I think it is something with the MSVC compiler and maybe not correctly working SIMD (some time ago AVX2+ did not work with MSVC compiler and maybe this difference is most noticeable on AVX2+ CPU)

<https://encode.su/threads/3564-JXL-version-0-3-released?p=72776&viewfull=1#post72776>

So what's the build difference? Can we change our official build?

Hmm, I found two building systems for Windows on the official Github, but not sure which one is used for nightly, I use Msys2 and Clang (and this will probably be better) <https://github.com/libjxl/libjxl/actions/workflows/build_test.yml> <https://github.com/libjxl/libjxl/actions/workflows/release.yaml>

So it could be the difference between GCC/MSVC and Clang or something wrong with SIMD, I make a build for AVX2 as a low system (Haswell) and if this gives the biggest advantage then maybe would make two builds, one optimized for AVX2 and higher systems (like Clang `-O3 -march=haswell`) and one generic for compatibility

I have no clue but it does look like there's a pitfall that we should avoid, once discovered what it is we probably better update windows building instructions too

Yes, after some tests with different compilers, Clang as a compiler has the biggest impact, even without additional options for AVX2 GCC and MSVC binaries are noticeably slower

The Windows MSYS2 job is build with AVX2 disabled (in highway), which could also be the reason for that. See: <https://github.com/libjxl/libjxl/blob/aa16521154328c94bfc2b73a0e28bd5bd22330c1/.github/workflows/build_test.yml#L429>

FWIW, one might also consider using an LLVM/Clang based cross-compile environment with <https://github.com/mstorsjo/llvm-mingw>. See for example this Dockerfile: <https://gist.github.com/kleisauke/ff56d99094eadb8d315c3715f460c5e9>.

Yes, because old GCC versions don't work properly with AVX2, with the new ones it's working fine, but GCC is slower even if AVX2 is enabled (as can be noticed by my compiled versions and test scripts) https://discord.com/channels/794206087879852103/794206170445119489/934705313431580702

Yooo thank you so much.

Say you have a 16 Bit image with a gradient, converting it down to (lossless) 8 Bit with ordered dithering doesn't decrease the file size that much (especially on faster efforts) while 8 Bit without dither is far far smaller. I would be interested to know now if an encoder for JXL (or PNG) could be created that transforms 16 to some kind of dithered 8 Bit while knowing exactly how this dithering was applied to create a denser output.

I would convert it to 12 bit without dithering, and encode that losslessly

that should be higher quality than 8-bit with dithering, and probably also denser

Nice compromise for gradients but it probably won't be denser for mixed content.

Possibly some kind of near-lossless 12 bit could be interesting, where an error of +- 8 is allowed (so at 8-bit there is no difference), but in smooth regions with slow gradients, more precision is kept. I.e. predictor residuals around zero are stored as is, residuals that are larger get up to 3 lsb chopped off

We do something like that for DC encoding to avoid banding

Sorry to bother you, A little curious, libjxl 1.0 will be ready end of February, It's mean non-photo content quality and feature improvement will happen on March? I really look forward those improvement.<:BlobYay:806132268186861619> > https://discord.com/channels/794206087879852103/803574970180829194/928281741116981260

Likely I will _try_ to make improvements then, I am not going to promise that I will succeed though 😅

Thank you very much 🙂 I believe jxl team can make a great lossy encoder.

Doesn't sound ideal, whether it's a conversion error or playback error. I've never noticed that effect with cjxl conversions and viewing through Chrome (although I recall cjxl not properly handling some GIFs in other ways).

Sorry to disturb, was Irfanview`s bug

Still good to know there is/was a bug in Irfanview. Is there anything we can do to make it less likely that others have this bug?

<@!794205442175402004>Maybe Like bug report https://irfanview-forum.de/forum/program/bugreports/93817-animated-jxl-wrong-playback-speed-irfanview-4-59-x64

Sorry to bother you, A little curious, About quality and feature improvement for non-photo content, jxl team will implement which method? 1. Improve PR466 separate option, this method probably can improve quality and avoid DCT worst case?. 2. Improve vardct mode for non-photo content and implement auto palette to avoid DCT worst case. 3. Implement higher epf on vardct mode and implement auto palette to avoid DCT worst case. (I guess higher epf maybe can reduce tiny artifacts?) 4. new method is on pipeline.

Nothing on the pipeline yet, but I am planning to do something like separate but without going fully two-layers, and somehow avoiding border issues

On avoiding border issues, isn't it possible to just apply a gaussian across them?

I understand, Thank you for your reply 🙂

kimageformats are fuzed using oss-fuzz. libjxl 0.6.1 is used. I observed an old issue from the fuzzer: Issue 41159: kimageformats:kimgio_jxl_fuzzer: Integer-overflow in jxl::DecodeTree Crash Type: Integer-overflow Crash Address: Crash State: jxl::DecodeTree jxl::DecodeTree jxl::ModularDecode Do you need the testfile from this case? Or do you think the overflow is probably fixed already in master via some other case?

doesn't hurt to check

libvips' CIFuzz integration is failing with: ``` In file included from /src/libjxl/lib/jxl/enc_color_management.cc:27: In file included from /src/libjxl/third_party/highway/hwy/foreach_target.h:91: /src/libjxl/lib/jxl/enc_color_management.cc:237:66: error: expected ';' after expression mutable_xform_src[x] = 100.f - 100.f * mutable_xform_src[x] ^ ; In file included from /src/libjxl/lib/jxl/enc_color_management.cc:27: In file included from /src/libjxl/third_party/highway/hwy/foreach_target.h:102: /src/libjxl/lib/jxl/enc_color_management.cc:237:66: error: expected ';' after expression mutable_xform_src[x] = 100.f - 100.f * mutable_xform_src[x] ^ ; In file included from /src/libjxl/lib/jxl/enc_color_management.cc:27: In file included from /src/libjxl/third_party/highway/hwy/foreach_target.h:113: /src/libjxl/lib/jxl/enc_color_management.cc:237:66: error: expected ';' after expression mutable_xform_src[x] = 100.f - 100.f * mutable_xform_src[x] ^ ; /src/libjxl/lib/jxl/enc_color_management.cc:237:66: error: expected ';' after expression mutable_xform_src[x] = 100.f - 100.f * mutable_xform_src[x] ^ ; 4 errors generated. ``` https://github.com/libjxl/libjxl/blob/4bba562a52e8f830dc0c62d2403fc135813cc72d/lib/jxl/enc_color_management.cc#L237

https://github.com/libjxl/libjxl/pull/1171 quick fix posted

Huh, looks like we need an lcms build in CI...

lcms?

cjxl/djxl can be built with lcms2 or with skcms to do the arbitrary ICC profile color conversions.

Looks like the code path for building with lcms2 is not well covered, if a typo that prevents it from compiling gets through CI

Hi - I am looking to connect with a dev that is working on lossless performance optimization. I met him a few weeks back at the DICOM WG-04 meeting but forgot his name. Thanks

probably me? 🙂

but <@!794205442175402004> too

I'm Jon, veluca is Luca

yes Luca i think - will dm you

What would be goto resources/books/courses to learn more on image/video and compression in general?

Are we gonna see 1.0 this month?

https://tenor.com/view/fortune-teller-crystall-ball-psychic-clairvoyant-gif-5100696

Sadly, no response

I think somewhere in April is a safer bet

Hi! I am currently trying to construct a jxl encoder for java over the existing wrapper (on my own fork on github for now at least). I have a question on the already existing infrastructure, who can I talk to?

best is to ask in <#804324493420920833>, many libjxl devs are on this discord and also many application devs who integrated libjxl are here so plenty of people can respond

there will be an intermediate version before 1.0 -- to package all the improvements in the head and proper progression support into a lib that is available soon

<@532010383041363969> you (the devs) should also clean issues and PR list before

https://github.com/libjxl/libjxl/blob/79293824dcdb91f1f934244b6f48e83bfed97588/tools/cjxl_main.cc#L353 < Spelling mistake in a flag here, does that require a bug report?

yes please

Done 👍

0.7 RC doesn't come with the needed dlls just like the nightly builds

I have them jendalinda send them tomorrow ill rruplod

I have the dlls myself but I shoulden't have to need them

I think the issue is that Brotli always (except on Emscripten) builds shared and static libraries (suffixed as `-static`) and ignores CMake's `BUILD_SHARED_LIBS` option. PR <https://github.com/google/brotli/pull/655> would fix that (AFAIK, that patch is used by most distros that distribute static libraries and/or want to reduce the build time).

This has to be resolved in the release. The Brotli dlls should be either included or not needed.

on a tangential note, is that windows vista :S

oh, yeah, hadn’t seen that the version number was there, thanks

Is the new version of libjxl going to be called 0.8? I noticed that the SONAME is libjxl.so.0.8

Hopefully the version after 0.7 will be 1.0

The new release will be 0.7

The git main branch is now calling itself 0.8 because it will become whatever the next release will be, which could be 1.0

Speaking of 0.7, we've been in RC for that for a while. What's the current update for 0.7 release?

I'd really like to have version numbers in headers in released 0.7.0 . If it is not possible, I can live without it (but other downstream developers may keep requesting that). If 0.7.x branch is not ready for the release, maybe RC2 would be fine so it gets even more testing.

I have a report from oss-fuzz: Issue 51177: kimageformats:kimgio_jxl_fuzzer: Heap-buffer-overflow in jxl::PerformBlending We use 0.7.x branch there.

yes. However, if you have a special interest in a specific issue feel free to bring it up here and/or on github as well...

I received following report regarding One Definition Rule: https://bugs.gentoo.org/875617 It is something that could be solved easily?

uh, yeah, that's an issue

it should also be easy to fix

can you file a bug?

I will post the issue tomorrow regarding the ODR.

<@179701849576833024> : i was looking a bit into your fast_lossless code, and wondered how much effort would be required to go full 16bit depth, i mean i can help a bit as i'm quite fluent in c++, and algorithms, but i didn't spent a lot of time checking where i can adjust, would you mind spotting the area where adjustement may be required ?

the current code already does 10/12 bit; to go full 16-bit will be harder because then the values don't fit in int16_t anymore...

<@794205442175402004> : the question is "16bit"

I guess the main thing to do is to replace the int16_t stuff with int32_t and to modify the huffman coder to deal with that. It will come at a price in terms of speed.

mhhh I suspect you need to basically change everything 🤣

both the huffman coding and the memory buffers assume you never need more than 16 bits per symbol -- and you do for 16bd content

hum 🙂 thanks for the feedback on this topic 😄

technically speaking i do not mandatoringly really hit the 16 bit ... but 15 bit is often the case, i have large microscopy images, with (true) 16bit sensor dynamic, but my background noise is often a little offested like 100+ and but max signal is often burning the sensor, so basically we technically can think of shifting the signal to an offseted 0 level, (but this is felt as a sensitive topic, i'm selling the losless part 🙂 )

I suppose a 32-bit version of fast_lossless could be made with just no simd in the huffman coding, and it should still be quite a bit faster than libjxl e1

sounds interesting, i'll try to have to time to give a try at a non simd 32bit version as a first intention for testing purposes

Well libjxl is kind of already part of OIN via Google

A couple of OOM issues related to libjxl reported on libvips' OSS-Fuzz project seem to be duplicates. I was able to reproduce this with `python infra/helper.py reproduce`, but not locally without sanitizers, which might indicate libc++/libstdc++ compatibility thing. The issues in question are 49809, 49812, 49814, 49816, 49823 and 52867 (as an example, the first one causes a `malloc(2684354560)` call). Any ideas?

FWIW, you'll need to append 4 bytes to the file to reproduce it within the libjxl fuzzer. For example, with https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=49809 (disclosed tomorrow), I see: ```bash # Last 4 bytes in djxl_fuzzer are flags $ truncate -s +4 ~/Downloads/clusterfuzz-testcase-minimized-sharpen_fuzzer-6596094166958080 $ python infra/helper.py build_fuzzers libjxl $ python infra/helper.py reproduce libjxl djxl_fuzzer ~/Downloads/clusterfuzz-testcase-minimized-sharpen_fuzzer-6596094166958080 ... ==8== ERROR: libFuzzer: out-of-memory (malloc(2684354560)) ... ```

I have little problem with encoding my little picture 32768x32768 png ```JPEG XL encoder v0.8.0 72af6c7 [Unknown] Reading image data failed. ```

Probably out of memory, I would guess

the error message is issued instantly, besides, I allocated 20 GB of SWAP, but the most important thing is that mozjpeg works without problems

Oh, in that case no idea. Try a debug build to see if it gives more info, or else share the png so we can try it...

What kind of debug builds are talking about? where to get them? are there builds for Windows? I had a problem with compressing this 3 GB file, OptiPNG and XnConvert had a memory problem. In the end, I was Create to Uncompressed empty white sheet use Python Pillow, gave an error in the same way in cjxl. But after Pillow compressing I getting 3 megabytes, everything suddenly worked, Which means that somewhere in the code the maximum size of the Input file is written! (which print "Reading image data failed.") and later gave error ```JPEG XL encoder v0.8.0 72af6c7 [Unknown] Read 32768x32768 image, 3181331 bytes, 75.6 MP/s Encoding [VarDCT, d1.000, effort: 1], D:\a\libjxl\libjxl\lib/jxl/image.cc:94: JXL_CHECK: bytes_.get()``` and same ```JPEG XL encoder v0.8.0 72af6c7 [Unknown] Read 32768x32768 image, 3181331 bytes, 105.9 MP/s Encoding [Modular, lossless, effort: 1], D:\a\libjxl\libjxl\lib/jxl/image.cc:94: JXL_CHECK: bytes_.get()```

Encode memory is not very optimized at all yet, and we lack options to skip global optimization and encode groups independently...

Just now wanted to ask what's the problem with compressing it like 4 (or more) separate (block) images and then combining it into one...... That is, the answer to my task is that at the moment -- the cjxl encoder cannot compress images of this scale. In this case the question is, there is already some kind of software that can use the "limitless possibilities" of the image scale of the JPEG XL standard?

We should probably add a low memory encode option to libjxl that does one 2048x2048 tile at a time

Yes, this is what need.

For lossless, you can meanwhile use fjxl. It should use less memory than libjxl

But the question is, how much memory will it take to Decode the 32k x 32k? In the case of such files, symmetric tile decoding is needed, with sequential write separately in png, like blocks

https://github.com/jcupitt/vipsdisp

no builds no windows<:Thonk:805904896879493180> software whose author does not want others to use it

Decoding should be less of an issue. We don't have a cropped decode option yet, but at least it shouldn't use much more memory than the size of the decompressed image itself (and with the pixel callback not even that).

Well, it is flatpak, and gtk is mostly designed for *nix platforms

I'll have a look into integrating this in <https://github.com/libvips/build-win64-mxe> in the next release cycle of libvips (probably only for `x86_64` then, unless there is a demand to extend this to other architectures).

Hi JXL developers, First, thanks for the active development of this new promising compression format and file. I have questions regarding your file format so, sorry by advance for the length of my message... Let me quickly explain how we intend to use your file format. We want to propose a compression scheme for spectral images following up the recently published lossless spectral image storing scheme using OpenEXR (https://jcgt.org/published/0010/03/01/). Your format is the perfect fit for our needs since we want to mix floating point and integers framebuffers of an arbitrary quantisation size. Like the spectral EXR format, we would like to pack all spectral data within the same JXL file. So, we plan to extensively use sub images. However, from our experiments, we came across limitations, which can be due to a misuse of the library on our end. **Regarding compression** It seems if we save a single framebuffer per file, we get better compression ratios than storing everything within the same JXL file using sub images. Also, increasing frame distance does not change a lot the file size while the quality is heavily impacted (as expected). This is related to a previous question I have asked, namely using a specific compression ratio and down sampling for each sub image. - Does the library propagate the compression ratio down to sub images? **Regarding number of sub images** Looking at the code, the format supports at max 256 framebuffers within the same file. In our case, we can exceed such a limit, with stereo images or polarised images for instance. So, we currently split the data across multiple files. - Will JXL supports more than 256 framebuffers per file in the future? (1/2)

**RGB preview** As for the spectral EXR format, we would like to optionally offer a preview of the main image in RGB at full resolution in the main framebuffer while storing spectral information in sub images. That would allow a non-spectral aware JXL compliant software to display an RGB preview. But, doing so seems to propagate the overhead of storing an RGB image down to the sub images which are gray images in our case. - Are we doing something wrong or does the format expects all sub images be in the same format as the main image? **Frame distance parameter** While browsing the documentation, it is mentioned that a frame distance of 1 with `JxlEncoderSetFrameDistance` provides visually lossless images but when I use this parameter, I get strong artifacts. Am I doing something wrong there? Since we are currently working on the article and planning to submit it soon, we plan to use for now an evaluation of the compression achievable by storing a single framebuffer per JXL file. If JXL will support those features, we would like to mention it in the article. Thanks for your help! (2/2)

Some notes: - DCT can only be used for the first 3 channels. Extra channels have to use modular mode, which can do both lossless and lossy. - we need to add something to the encode api to set the quality of extra channels

FWIW, this was landed as commit <https://github.com/google/brotli/commit/641bec0e30bea648b3da1cd90fc6b44deb429f71>.

One a bit silly possibility for multispectral is to store one channel per y-component and create a new format that contains a lot of jxl images another possibility is to use layers with special names -- for example the wave-length range -- and then just layer vardct layers of y-channels yet another possibility is to use all the XYB layers and define three different spectral ranges for them in general, VarDCT has been optimized for XYB where the consumer of the image is a human -- this leads quite usual compression characteristics for the Y channel, but somewhat unusual for X and B -- so likely it would be a good idea for science use to use the Y channel only frame distance 1 relates to how many 'lumens' you have, the brighter your image the better the quality if you look at a normalized image in the end contact me at jyrki@google.com and we may be able to solve problems for your article in a VC

VarDCT could be used without XYB and with the three components treated as 'just numbers' without visual assumptions — this is not what libjxl currently does, but it's certainly possible to do that. One way to do it atm is by making an RGB jpeg and recompressing it.

Multiple grayscale layers would also be an option if you want to use vardct for all the data — otherwise a single layer with as many extra channels as there are bands would be the 'conceptually correct' way to do it, imo.

Does JXL support "block loading" of a local image? For example, I have an image with a resolution of 800x13044 (manhwa), can I upload a couple of blocks of 800x800? or part of the image from the center... is it possible to create such a reader with JXL? (not the progressive loading of the image, but the ability to make a request for a separate part of it)

JXL can theoretically do that, libjxl cannot atm.

How many layers of progressive loading can be do in theory?

Just to double check, are the ICC profiles synthesized by libjxl CC0 and/or public domain? identify -verbose says this but I want explicit confirmation

There are at most 11 passes per frame, plus the DC so at most 12 refinement passes per frame.

The number of frames/layers is unlimited

Is a few numbers describing a mathematical transform for color quantization really something that is copyrightable?

Those big cmyk profiles are. Something generated from a jxl enum, no idea if that's copyrightable

"That would be like if I tried to enforce copyright for this sentence that I'm typing here." - Pashifox 2022 ALL RIGHTS RESERVED DO NOT STEAL THIS SENTENCE

Why does Jpeg XL use brotli and not zstd (used only for Metadata compress||?||)

Probably mostly because there's overlap between brotli devs and jxl devs. We could define brob boxes with other compression methods, say zstd or gzip, but more methods means metadata software has to support more stuff too... I think brotli should be fine — the main thing is to have a compressed option besides plaintext/uncompressed...

one practical consequence from using Brotli however is, that the minimal JPEG XL decoder should be at least ~100 KB large, because of Brotli's built-in dictionary.

How much is that compared to the compiled size of the rest of the code? What is a j40 binary these days?

122 KB uncompressed, 50 KB compressed with Brotli without a dictionary (cf. https://github.com/google/brotli/blob/master/c/common/dictionary.bin.br)

browsers already have brotli because it's a web standard, so it's less binary code, brotli also has better compression, zstd is faster, but metadata is usually not some gigantic data when this difference matters, so it would be very strange to choose zstd

only if you want exif and similar things, if you just want to decode to pixels, no brotli is required

Brotli is not needed to display images, that was a design constraint (originally we used brotli for icc compression too and we changed that explicitly to avoid needing brotli to display images).

jxl 0.8.0 effort 1-9 distance 0.0 brotli_effort 11 using adfc39b windows x64 static e1 4,58 MB e2 4,71 e3 5,52 e4 4,09 e5 5,03 e6 5,04 e7 5,02 e8 5,02 e9 5,01 https://easyupload.io/507reg

Huh? e1 is second best and e4 is best?

compared to the previous jxl 0.7 build e1 5.04 e2 4.71 e3 5.52 e4 4.09 e5 5.03 e6 5.04 e7 5.02 e8 5.02 e9 5.01

It's true! That's surprising. I knew the lower effort settings are good for photo content but I didn't think the higher effort settings would be worse...

without black bars ```Encoding kPixels Bytes BPP ------------------------------------------- jxl:d0:1 1533 1518306 7.9202191 jxl:d0:2 1533 1295790 6.7594679 jxl:d0:3 1533 1282971 6.6925978 jxl:d0:4 1533 1138388 5.9383829 jxl:d0:5 1533 1133039 5.9104799 jxl:d0:6 1533 1131081 5.9002660 jxl:d0:7 1533 1110128 5.7909650 jxl:d0:8 1533 1093744 5.7054982 jxl:d0:9 1533 1087268 5.6717162```

I think I know why the higher effort settings can make files larger as I have experienced it happening in the past and it's because the lower effort settings can discard more image quality leading to the lower efforts taking up less space but looking way worse

but not for lossless

Yeah, in this case we're just looking at lossless mode. Something about the black bars is making libjxl confused.

oh this is happening with in lossless mode?

can you post the image without black bars you're using to test?

not accurate cropping, just for the test looks like the black bars are breaking some heuristics

Why is the cropped version several times smaller than the version with black bars?? Why does it cost several megabytes just to store a zero-entropy field of black?

because the original is 16-bit and the cropped one is 8-bit

e4 being better than e5+ is surprising, it likely means we have room for improvement in some heuristics or even an encoder bug somewhere

e1/e2 being better than e3 on this image is also somewhat surprising