JPEG XL

But I don't want to rush things. If there really are good reasons to take more time in order to increase adoption in the long run then take all the time you need... but ya know, the format is already frozen, ibjxl is just a library...

It doesn't even have to be the best or the only jxl compatible codec library

I think it is mostly that there are major API changes until version 1.0, so programs would have to redo a lot of the work of implementing to update.

But yeah, it would be nice to have a new release soon.

We are planning on making a 0.7 release very soon, before making verison 1.0!

It's a chonky c++ library with a huge number of dependencies too...

Maybe yurume's jxsml will save us all.

i hope you wait for october

https://discord.com/channels/794206087879852103/794206170445119489/994276090061275186

just see this stuff

about jxl vardct quality

is it too variable and bad

especially moe than 0.710 d

spoiler is it epf 3

wikipedia is already good updated

I am currently working on a c++ project where I want to convert images to jxl using libjxl However it is not possible in the system to read from file, the image is present as an unsigned int* to raw image data, similarly as in stb_image Can I use this raw image data in libjxl to encode a BLOB or something like that that I can send over TCP to a a JXL decoder where it decoded back into an unsigned int* to raw image data? I can only find the one code example on github where it reads image data from and to file, this is not useful for me. Or more code example in general? Thank you very much

Also this is not strictly JXL related but if someone here knows how to set ImageMagick in c++ to JXL mode that would probably also solve my problem

we are making good progress and currently are doing some fuzzing to make sure to have a less buggy 0.7 release.

69% complete - nice

<@794205442175402004> So, what's the licensing situation on XYB-MSSSIM?

well there's a PR to add it to the libjxl repo so that implies it has the same license (BSD-3)

i'm still working on it btw, adding back some of the asymmetry that is in SSIMULACRA

(normal SSIM is symmetric, it doesn't matter which is the original and which is the distorted)

Oh very nice. I've been planning to use it in an another encoder tool, so the fact that the licensing is the same is good for me 😄

I have following report regarding Integer-overflow in jxl::QuantizedSpline::Dequantize (libjxl 0.6.1 is used). Is it something to worry about?

ehhhh, not really

you'll get weird looking splines at worst, I believe

technically speaking it does an addition first and an int-to-float conversion later, which should be swapped I guess

I think it got fixed in the meantime but I'm not entirely sure

either way, IIRC it's not a security problem

i mean it could be if the compiler were less helpful

trying to build main branch on OSX, getting "error: use of undeclared identifier 'JxlDecoderSetBoxBuffer'; did you mean 'JxlDecoderSetJPEGBuffer'?" should main be building cleanly right now?

main should be building cleanly right now. Consider filing an issue with some more details

I observed that libjxl from git no longer works with system installed highway 0.17.0 . Does it mean that there should be new release of highway before next libjxl is released?

https://github.com/google/highway/commit/e41973e26b3a870fcfb63fa2d4f2bcd57fe94de5 suggests that highway 1.0 is near.

yes

highway 1.0 is released

noice

https://github.com/google/highway/releases/tag/1.0.0

yup

they broke the ABI but not the API, so try recompiling

i've heard that some libjxl devs are prepariing the libjxl 1.0 release, right ?

https://discord.com/channels/794206087879852103/848189884614705192/991258530067791962

<@853026420792360980> Do you have an idea of why Lynne views storing DCT values as floats instead of ints as a problem? ```but I do think it should be 16-bit int, not float I'm pretty sure the spec's mention of float is just a suggestion, any half-serious implementation must be fixed-point otherwise jxl is a trashfire of a research codec that will never get adoption```

Maybe it's because of HW decode or in-order CPU cores absolutely detesting having to use their FPU?

I mean, for lossless coding, you obviously want to use int DCTs over float DCTs, but for lossy, there is a definite benefit to using float DCTs, unless your system has a bad FPU backend.

fixed point is massively faster than floating point and much easier to implement in hardware

but she is correct that it is just a suggestion. "float" in the spec in most places just refers to real numbers, not implementation

she is saying that *if* the spec *requires* floats, then it is a problem

but it doesn't, it just uses real numbers

Oh <:kekw:808717074305122316>

Now that makes a lot more sense.

Actually, I'm wondering if we'll see optimizations in this regard for libjxl to speedup encoding and decoding.

https://github.com/libjxl/libjxl/pull/836 < There's some fixed-point code already in libjxl

oh, I didn't realize that those specialized codes for ARM actually uses fixed point instead of floating point!

But yeah, my main worry with moving from float DCTs would be a slight loss of compression performance in lossy mode, so I wonder if what bombzen is true: real numbers, not an implementation.

Video codecs tend to have fixed point specs because 1) they are designed for hw implementation, 2) they need to be fully specified, because any small error could accumulate to larger errors after many frames.

Jxl has a 'real numbers' spec plus conformance thresholds that define how much precision implementations need to have to conform to a profile/level

At some point we'll probably have a hardware profile/level that can be implemented in fixedpoint. It will probably be limited to 10-14 bits worth of precision - maybe there will be more than one of these, the simplest for SDR only.

Jxl is not a 'hw-only' codec though, and e.g. on modern x86, float arithmetic is actually quite cheap, and so is int32 arithmetic. So we saw no reason to limit the precision to something rather low (say 12-bit) so the whole thing can be implemented in hw.

Build `libjxl` with `ucrt64/msys2` and get this: ```bash $ libjxl/build/tools/cjxl -V WARNING: CPU supports 1a00 but software requires 2000000000000000 cjxl v0.7.0 980c90f [AVX2] Copyright (c) the JPEG XL Project ``` CPU - ryzen 7 5700x

It's a known issue but it doesn't affect functionality. You don't need to worry about it.

According to <https://github.com/google/highway/issues/882> that "CPU supports ..." warning should be fixed with commit <https://github.com/google/highway/commit/51d5f80987e4dc4771a9f12ccbb548e9416503e6> (v1.0.0), but with that version I still see this warning.

Ah, I should probably test with commit <https://github.com/google/highway/commit/9b6b473890bb6a43f5cd4786f9c214f0aa4e6420>, which didn't make it into v1.0.0.

it's indeed a bug in highway, not in libjxl

What is the preferred replacement to `JxlDecoderDefaultPixelFormat`?

it appears I'm not using it, I'm just wondering

just set it manually?

I think nobody is using it, because if you think about it: why would an application use it?

good point, you'd rather just get whatever pixel format you need

and if you want to preserve the original, you inspect JxlBasicInfo

which is currently what ffmpeg does

Hi, First of all, thanks for this amazing new image format! I have a question regarding the fine tuning of extra extra channel compression and downsampling. I hope this is the right channel for that. Ideally, I'd like to specify a downsampling ratio and quality ratio independent for each extra channel. More or less the same way as I can currently specify a different quantisation on a per channel basis. It would look like that: ``` downsampling quality quality main_framebuffer 1 0.5 extra[0] 1 1.0 extra[1] 2 1.2 extra[2] 4 1.2 ``` So far, I managed to specify: - a quality ratio for the whole image - two downsampling ratios, one for the main framebuffer and one common to all subframes. But I cannot specify a downsampling and quality on a per framebuffer basis. Is such fine tuning possible and did not make the right API calls? Thanks!

This is certainly possible in the codec, but I think the current encode API doesn't expose that fine tuning yet

Please open an issue to request it, it shouldn't be hard to implement and I agree that this would be a useful thing to have in the API

there's no reason why e.g. alpha and depth should have the same downsampling and quality

Thanks for you rapid answer! Added a little bit more context in the issue.

hey! Does chrome not support progressive decoding of JPEG-XL yet? I encoded a jpeg using `cjxl` with the `--progressive` option but chrome seems to be rendering it sequentially rather than progressively

i am on chrome 104.0.5112.101

nope, not yet. it shows groups incrementally but that's it, iirc

it should be coming though afaiu

I'm working on it

nice, thank you! looking forward to it 😄

Do we have a timeline on when that will be shipped and also when JXL will be enabled by default in Chrome?

That will be a big boast for adaption for sure!

The first round of encoder simplification, a.k.a. `libjxl-tiny` is ready: https://github.com/libjxl/libjxl-tiny Implements encoding photographic images to JXL using a subset of encoder tools.

nice!

do you have a description somewhere of what coding tools were removed or used in a simpler way than in libjxl?

also we should probably do some benchmarking to see how libjxl-tiny performs compared to the various speed settings of libjxl encoding

(objective metric benchmarking using butteraugli 2-norm and ssimulacra 2)

Anyone has the compile?

Does it work?

I added a page to the readme about the coding tools: https://github.com/libjxl/libjxl-tiny/blob/main/doc/coding_tools.md

As for benchmarking, the speed is between -e 4 and -e 5 (closer to -e 4) and the butteraugli-3-norm*bpp metric is about 5% worse than libjxl -e 7. However, this repository is only meant as a big experiment to see what complexity is necessary for the camera use-case to produce decent quality images. If we find that this particular speed-vs-quality setting makes sense, it should probably be added to the main libjxl encoder.

Are you going to attempt to do a fixedpoint version of things, or will it stay float?

if things can somehow be done in int16_t (with maybe some int32_t for intermediate results if int16_t precision is not sufficient), it will likely be faster, especially on older arm.

There are no plans to implement a fixedpoint version at this time.

I know Lynne wants to do her implementation of JPEG XL as fixed point

but I'm not sure what her progress is on it

https://chromium-review.googlesource.com/c/chromium/src/+/3865432 adds progressive decoding in chrome

is it possible that current djxl does something quite horribly wrong when saving 10-bit images as png?

looks like it is getting the endianness wrong or something like that

https://embed.moe/https://cdn.discordapp.com/attachments/804324493420920833/1015543040003276871/example.jxl

this is what current djxl produces for this image:

when you add a `--bits_per_sample 16` it does the right thing, but if you don't, it does something quite horribly wrong

PNG doesn't support 10-bit so how would you save a 10-bit image as PNG

PNG only supports 8 and 16-bit per channel

as well as paletted

I know, but djxl needs to do something sensible when converting a 10-bit jxl to png

Either quantize to 8-bit or pad to 16-bit, but not whatever it is doing now

I suppose it's just a matter of having more sensible defaults in the output codec configuration

That's what it used to do, but I guess something regressed in the process of moving to djxl_ng

how is the current state of the stable decode API? Everyone always talks about the encoder but the decoder is what matters right now.

Bit depth that can't be directly represented in PNG must be upscaled to the nearest valid bit depth. The original bit depth is indicated by sBIT chunk. Instead of simple padding with zeros, the values should be upscaled by repeating the highest bits in the empty bits. More info here: https://www.w3.org/TR/PNG-Encoders.html#E.Sample-depth-scaling

Decode API is quite stable, just in 0.7.0 it was extended so you can use it to access metadata boxes (EXIF, XMP)

PNG really does seem needlessly complex, even for image coding experts.

PNG compression works exclusively with bytes, so the supported bit depths are only divisors and multiples of 8.

This technique of upscaling is used pretty often, also for scaling lower bit depths to 8 bpc. Some hardware was using 5 bpc or 6 bps for example.

Is it equivalent to doing the actual calculation? E.g. padding 10 to 16 bits can be done also by multiplying every sample value by 65535/1023 and rounding to nearest integer.

Just adding zeroes is obviously wrong because then white maps to 65472 instead of 65535, so it's a bit too dark.

As long as you get the original values after reducing to original bit depth, it's fine.

This formula is mentioned in the documentation too. The bit shifting method was probably suggested for speed.

Yeah, though I am not sure if it still makes any measurable difference nowadays

That's fair. CPUs went a long way since then.

Yes, but faster is indeed faster 🙂

In case of JXL, it's using floats anyway, so if the range is 0.0 to 1.0, multiplying by 65535 and setting correct sBIT should do the trick.

well JXL is using real numbers between 0.0 and 1.0 in the spec, whether it's fixed or floating point is an implementation detail

also they don't have to be between 0 and 1 🙂

true

This is cool. If decode API is stable why's it taking so long for people to link it and use libjxl to add decode support to more software?

Technically, it is not difficult. It depends on each person's priorities and motivation. If they want, they seek solution. If they don't want, they seek excuses.

why is sjpeg support available ? libjpeg-turbo is not sufficient ?

it is, but we wanted to experiment a bit

couldn't deps.sh be reduced ?

zlib and libpng are commonly installed these days, and anyway, it's the purpose of cmake to ask for them

i just don't understand why there is deps.sh

there are two kinds of poeple : those who develop, and those who use

devs : they know how to install package

to compile, even

the users: they will use their package manager, which will deal with deps anyway

so, for me, simplify all that stuff, always ask for system libs

there are package for all of them

System libs are fine for zlib and libpng (though only on linux), but for highway and other deps, usually the system libs will be too old

then remove zlib and libpng

they have not been updated for years

Libjxl doesn't depend on those anyway, it's only used in cjxl/djxl

it would also be nice if you print a summary at the en of CMakeLists.txt

Congrats on the 0.7 release! <:JXL:805850130203934781> https://github.com/libjxl/libjxl/releases/tag/v0.7.0

Ok on Wikipedia is already updated

For es it and en

It's nice having a new version after all this time

Very nice

Makes it much easier because compiling it is a bitch on most systems

If it didn't have so many dependencies, and most systems were not so horribly out of date, it wouldn't be so bad to just compile it

<@853026420792360980> <@179701849576833024> Is there like a test suite of XYB images somewhere in libjxl or in other places?

Something rather nice just popped up, and we'd like to have a test suite of suitable images to be able to test stuff correctly: https://github.com/rust-av/yuvxyb

not that I'm aware of

iirc clang > gcc

but I dunno if it makes a big difference, a lot of stuff is basically manually vectorized using highway so compiler might not matter that much

Ideally we would losslessly (though not reversibly) transcode CMY, and decode K to pixels

I thought JPEG XL was a superset of JPEG

VarDCT is able to do anything a particular subset of the JFIF standard supports, namely the widely supported subset

the original JPEG standard is huge, and even supports things like HDR and the like, it's way before its time

there's a particularly commonly supported subset of that standard that is often called "JPEG" by itself, and that common subset is what can be transcoded losslessly with VarDCT

And CMYK is not part of that I take it. Also what's "lossless but irreversible" mean?

Means you can't recreate the original JPG image (meaning the original bitstream of course you could reencode) from the new JXL

In what sense is it lossless?

it doesn't incur any further loss in quality

So it would not be reversible because K would be decoded from DCT coefficients instead of losslessly recompressing them?

Yes

XL doesn't support more than 3 DCT channels?

No

VarDCT is hardcoded for 3 channels

It is designed for visual data with 1 luma channel and 2 chroma channels

The format as currently specified will never support multiple DCT channels it sounds like

If I understand corrently

additional, not multiple

Extra channels are modular and modular doesn't have dct

You could of course do something weird like use a second layer for the K

Oh, that's right... But can alpha channel be DCT?

No

So there's no possible way to preserve the coefficients without an extension of the spec

Well you could put cmy in one layer and k in another layer

Layers are zero-duration frames

But the decoder would have to know about this weird use otherwise one layer would be obscuring the other

Uhm

you will need the third layer to actually merge K, doesn't it

There might be a way to make it work while respecting the spec too

Now you're using your noodle

The second layer could use kMul blending

Then I _think_ that does the right thing as an approximation

For actual color management it wouldn't work

But approximately, i.e. the way cmyk jpegs without icc profile work, I think this would be ok

Interpret cmy as rgb and then multiply everything by k

Jxl cannot represent cmyk without icc profile, if you have a kBlack channel then you also need an explicit cmyk icc profile

But this could be a workaround

is it true that most cmyk jpeg out in the wild does not have a profile?

Also isn't K redundant because cmy is subtractive?

Well no that's not the reason why it's redundant, but you know what I mean

But yeah that's definitely designed for printing and ink

K is redundant in theory but not in practice: printing something with black ink will always look nicer than mixing black from CMY

In particular text as pure K looks a lot better than text made from CMY

yes the print heads are never perfectly aligned either

it makes a lot of sense for printing

But also sometimes "deep black" is used, which is "darker than black"

But stupid for storage

E.g. full K ink but still some color over it too

This is why converting CMYK to RGB is not reversible, there are many ways to do the separation between K and CMY

But also: using jpeg for cmyk is not such a great idea, since the main use of K is to keep text nice and crisp and that's not exactly where jpeg/dct shines...

This is why we thought it was ok not to support 4-channel dct but to require all extra channels to be modular and only have dct for the 3 'photographic' channels. DCT is great for photographic data but for non-photo it is not effective (compression-wise) and the artifacts are pretty bad.

All extra channel types we could think of were things that didn't really benefit from dct: alpha, K, selection masks, spot colors, depth maps, thermal, etc: none of them would really benefit from dct and any dct artifacts would probably be quite bad for those

The philosophy in pik and fuif was similar in some respects, but also quite different in others: pik focused on psychovisual optimization of visual images, specializing on that, which lead to XYB and the VarDCT approach and an encoder that really knows what it is doing (since it works in an absolute color space and knows the semantics of the numbers it is working with), while fuif tried to be as generic and versatile as possible, which lead to modular.

As alpha channel is separate from VarDCT, is it possible to select different distance for VarDCT and alpha (or other extra channels)?

Yes

We should add that to the api

Especially when the alpha is very simple, like a cutout from a photo, where alpha has just few levels, lossless alpha would result in smaller file than lossy.

Lossless alpha has another advantage, VarDCT can safely discard contents of the fully transparent pixels, as it's guaranteed those will be fully transparent after compression.

Currently we do that already - fully transparent pixels get blurred heavily so vardct does not waste bits on them

(just zeroing fully transparent pixels leads to edge artifacts bleeding into the visible pixels, so instead I made it smear out the visible pixel colors into the invisible pixels)

WebP does it too, although it only smears pixels inside the edge DCT blocks, other blocks just fills with black. It also uses lossless transparency.

you could do a first grayscale DCT frame with the K data, then use a frame with the CMY data and use patch-blending to put the previous frame in the K channel IIRC

that way you'd have something equivalent to CMYK JPEG for display, and that can be decoded back to it (although probably doing it bit-exact would require extending/changing the brunsli box a bit)

It sounds like there's nothing stopping JXL from losslessly preserving and recompressing other DCT formats like AVIF and webp?

I think in principle is may be possible, but no code for it exists. It was mentioned in this issue: https://github.com/libjxl/libjxl/issues/315#issuecomment-880608516

I think another big consideration is that there arn't the source images in AVIF quite the same. They are almost always created from a JPEG or PNG original currently, and thus you are better off going back to that original source than recompressing a lossy copy.

WebP and avif have directional prediction and encode the residuals with DCT or DCT-like transforms. JXL does not have directional prediction, and its set of transforms overlaps with that of avif/webp but it's not a superset.

Lossless JPEG transcoding to JXL is pretty unique feature. I don't know any other format that could do something like that. The structure of JPEG images is also quite simple, that's why they're so flexible. JPEGs can be rotated, flipped, cropped, concatenated etc. You can't do such things with video codecs.

JPEGs are also way more ubiquitous than WebPs and AVIFs. For most WebP/AVIF images in existence now, the original source is typically still available, I would assume. This is not the case for JPEGs.

That's right. Most cameras produce JPEGs.

lossy modular takes up more space than lossless modular?

depends on what kind of image and how lossy

lossy modular disables quite a few transforms that are not safe w.r.t. residual quantization, like palette

You would think that lossy modular would start from lossless as a baseline and only make changes that further shave off bytes

or per-group RCTs

no it doesn't

some things are safe to do when doing lossless, but not if you're going to do things in a lossy way

e.g. changing the RCT per group is fine when doing lossless, but when doing lossy it can introduce visible group boundaries

same with palette: you can quantize away least significant bits of squeeze residuals if those come from full color channels, but if you do lossy squeeze on palette indices, a one-off can make a pixel a completely different color

I see.

Maybe someone can make a smarter lossy mode in the future that uses lossless tricks like that but makes the image more compressible similar to GIF optimization tools or pngquant

No reason why lossy mode can't use everything lossless mode does if you’re clever enough about it.

Then the artifacts might look nicer too compared to current lossy modular artifacts

Sharp lines and smooth gradients rather than fuzziness

Yes, approximating an image using the whole modular toolbox including delta palette, lz77, squeeze, MA trees and all the predictors could almost certainly be more effective than what is done now, which is just squeeze and then using the multiplier in MA leaf nodes to quantize the residuals, using just the Zero predictor.

I do get the feeling the current encoder barely scratches the surface of JXL potential

Hopefully in the future we will see lots of different 3rd party encoders tuned for different things

It's a very expressive bitstream, creative encoder writers can have fun with it for decades, I imagine

I mean if you see what was possible already in the old jpeg, the difference between libjpeg and mozjpeg is quite big...

And that's with a bitstream that is not very expressive at all — besides the progressive scan script and the choice of huffman codes and quant tables, the encoder doesn't have many degrees of freedom...

Yes :p

Hi there! I'm updating a version of cjxl on Ubuntu ( Following along here https://github.com/libjxl/libjxl ). After running `sudo cmake --install .`, cjxl can't find the libjxl_threads library: ```shell libjxl/build $ /usr/local/bin/cjxl --version /usr/local/bin/cjxl: error while loading shared libraries: libjxl_threads.so.0.8: cannot open shared object file: No such file or directory ``` The libraries look like they've been installed: ```shell libjxl/build $ ls -l /usr/local/lib/libjxl* -rw-r--r-- 1 root root 7886642 Sep 29 07:02 /usr/local/lib/libjxl.a -rw-r--r-- 1 root root 3935096 Sep 29 07:02 /usr/local/lib/libjxl_dec.a lrwxrwxrwx 1 root root 13 Sep 29 06:42 /usr/local/lib/libjxl.so -> libjxl.so.0.8 lrwxrwxrwx 1 root root 15 Sep 29 06:42 /usr/local/lib/libjxl.so.0.8 -> libjxl.so.0.8.0 -rw-r--r-- 1 root root 4859336 Sep 29 07:02 /usr/local/lib/libjxl.so.0.8.0 -rw-r--r-- 1 root root 23782 Sep 29 06:55 /usr/local/lib/libjxl_threads.a lrwxrwxrwx 1 root root 21 Sep 29 06:42 /usr/local/lib/libjxl_threads.so -> libjxl_threads.so.0.8 lrwxrwxrwx 1 root root 23 Sep 29 06:42 /usr/local/lib/libjxl_threads.so.0.8 -> libjxl_threads.so.0.8.0 -rw-r--r-- 1 root root 24624 Sep 29 06:55 /usr/local/lib/libjxl_threads.so.0.8.0 ``` What have I missed / done wrong?

looks like something wrong in our install script I guess

maybe try `sudo ldconfig`?

Ha - that fixed it. Thanks!

Jpg support HDR?

yes and no

or rather, yes and yes and no

the original jpeg spec supports up to 12-bit, so it can certainly do HDR. But nobody implements that, and the de facto jpeg is 8-bit only

but even within 8-bit jpeg, you can kind of do HDR, if you do it carefully

that is, the actual DCT coefficients are still ~12-bit, so if you implement everything with high precision (not with shortcuts for speed like in libjpeg-turbo), you can actually get a reasonable 10-bit image out of a de facto standard jpeg

add an ICC profile that corresponds to XYB, and it can kind of be used for HDR — it's not perfect, but probably not really worse than what you get in 10-bit avif

so yes, the original jpeg spec supports HDR and yes, even the de facto jpeg format supports HDR but no, the widely used decoders like libjpeg-turbo will produce an 8-bit output so it will have banding

That's pretty surprising that JPEG could actually do HDR as the hardware capable of that simple wasn't there at the time. Computer screens could do 8bit at most and digital cameras were using sensors designed for capturing analog video. I'm also wondering what materials JPEG used to create the quantization tables as digital photography was kinda in it's early stage. I guess they used photos scanned from film?

Yes, they were really ahead of their time to consider 12-bit while they designed it when most displays could display just 16 colors (4-bit palette)

So jxl can losslessly represent 12 bit jpegs, right?

It can, but the jpeg bitstream reconstruction thing is only defined for de facto standard jpegs

But the data itself could be stored without problems

So theoretically jxl can transcode 12 bit JPEG omitting the reconstruction data and the resulting jxl image can be decoded to pixels with the full precision.

The jbrd itself is curious. I've noticed that if the source jpeg file is just plain JFIF, the JFIF header is clearly visible in the jbrd box. If the source jpeg also includes EXIF, the JFIF header is not visible. Where did it go?

a few of the commonly occurring things are basically hardcoded in the jbrd spec

for example:

so strings like "Exif\0\0", "ICC_PROFILE" and that string used for XMP metadata are just hardcoded in the spec instead of getting encoded explicitly in the jbrd

Yes, EXIF, ICC and other blocks are moved to their own boxes. JFIF header goes in the jbrd box. The curious thing is that if EXIF is present at the same time, the JFIF header is encoded differently so it's not clearly visible.

well most of jbrd contains brotli-compressed data

if it's not a lot of stuff to encode, then I guess brotli will fallback to just storing the stuff uncompressed, which is probably why you can see strings like JFIF

but if there's more stuff, it will compress it and you'll not see it anymore

That makes perfect sense.

there is now also a cicp chunk in ICCv4.4, which the nightly of Chrome 108 implements: https://crrev.com/c/3913326

but low-precision JPEG at the moment

Oh, so you can do PQ/HLG in an icc profile now?

yes, at long last

djxl now generates such profiles

https://github.com/libjxl/libjxl/pull/1753/files

HELP PLZ

I'm working on updating libjxl in Squoosh to v0.7.0 and I'm stuck with something beyond my comprehension 🙁

https://github.com/ziemek99/squoosh/tree/jxl-070

Clone it, then run `npm install; npm run build` in `codecs/jxl`.

Wait till the end and see Emscripten's (?) errors... WTF

How backwards-compatible is 0.7?

Particularly, compile tine compatibility

With projects that were using an earlier version of libjxl

How much breakage is there with software using really old libjxl, if you swap the newest libjxl in for the old? How far back do you have to go before you encounter problems of the newer version missing API surface from the old one?

Does anyone know how to build ruby-vips on Ubuntu, using my local build, rather than the ubuntu supplied libraries?

Depends a bit on what they used. I think the basic decode api hasn't changed much.

if a JXL is marked as 10-bit or 12-bit

is there a way to retrieve that 10- or 12-bit data directly?

without having to receive 16-bit and dithering it down yourself

or, for the encoder API, send 10 or 12-bit data?

I ask because lossless in theory should support sending and receiving 10 and 12 even if 16-bit is fine for lossy

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

I guess <@987371399867945100> is already on it

also keep in mind that in order to accept 12-bit input you have to actually accept 12-bit input

not just 16-bit input with four leading zeroes

just like how rgb24 and rgb0 are two different formats

or output

this is probably easier if it's done planar, anyway

yeah I guess we'll need to support all the ways in which people may want to do this: 12-bit as 16-bit with lsb being irrelevant, or with msb being zeroes, or literally as 12 bits (so two samples are 3 bytes), where I suppose you can do the packing into bytes in different ways too: `Aaaaaaaa aaaaBbbb bbbbbbbb` is one way (where A is the msb of the 12 bits of the first sample) `aaaaaaaa aaaAbbbb bbbbbbbB` is another way `Aaaaaaaa Bbbbbbbb aaaabbbb` could even also be a way

another possibility is to read it as a native endian 4 byte integer, where only lower or upper 24 bits are used depending on the endian

That kinda reminds me how 2bpp and 4bpp are packed into bytes, but that makes sense as it aligns well with bytes. 555 and 565 were usually packed into 16bit words. AFAIK 10bit RGB is being packed into 32bit dword, leaving 2 bits unused.

I think we need to implement something that is generic enough to support formats that are actually used (by relatively major things), without going all the way to supporting every possible way we can imagine in which you can put X times N bits into Y bytes

probably ceil(N/8) byte plus padding should be the default, with some exceptions made for individual packed formats like 10-10-10-2

I think OpenGL pixel format (https://registry.khronos.org/OpenGL-Refpages/gl4/html/glTexImage2D.xhtml) is close to a good source for those exceptions, having things like GL_R11f_G11F_B10F

if we are actually going to cover those cases in the API

Agreed, samples padded to whole bytes are easy to convert to anything else by the application. Adding some pixel formats used by common APIs would be nice bonus.

id assume first vs second would be configurable and depend on endianness, third seems unlikely to be useful

https://github.com/libjxl/libjxl/pull/1812 adds support for input/output formats with leading zeros

So I guess it went unnoticed... 🙁

I noticed but have no clue

I tried to reproduce that and my nvm tried to build nodejs from scratch somehow

speaking of things that may have possibly gone unnoticed, the benchmark_xl binary is busted on windows and doesn't function anymore in newer commits I don't know which commit broke it but I assume it was around when xyb jpegs where added since I have a binary from before then and it seems to work

I would make a issue on github but I prefer just using discord

How do you mean, busted? What happens when you run it?

I’m getting this: ``` tools\benchmark\benchmark_xl.cc:1121: JXL_CHECK: Args()->AddCommandLineOptions() ```

let me try and bisect

``` de08116d14db785431f3efb651dcf2af15bbb682 is the first bad commit commit de08116d14db785431f3efb651dcf2af15bbb682 Date: Mon Aug 22 09:40:05 2022 +0200 Improve 'custom' codec in benchmark. Add options to prepare input of custom codec in arbitrary file format and colorspace. Add option to suppress custom codec stdin/stdout. Fix endianness of pfm headers and check correct endianness of ppf when encoding into ppm/pgm. ```

<@794205442175402004> just sent you a fix

Thanks <@245794734788837387> for noticing this and <@604964375924834314> for fixing it!

Maybe <@228116142185512960>?

<@179701849576833024> Also is there a tool in the libjxl repo or anywhere that can just output raw XYB data either by converting YUV or RGB to it or by decoding a jxl file? There doesn't seem to be one at first glance.

There probably is a magic colorspace string for that

Yeah I think <@604964375924834314> might know how

Ah, see https://discord.com/channels/794206087879852103/803663417881395200/1028203576981463091

Sorry, I don’t have the setup to run it right now. What are the errors?

What matrix does libjxl use to do linear rgb to lms?

this one by default

those are the defaults that you get if you don't signal a custom matrix; currently we only use defaults but we left the possibility open to change things (there's an optional header field for custom XYB)

Thanks!

how does libjxl read/write 16-bit floats?

I was under the impression that float16 was deprecated

https://github.com/libjxl/libjxl/blob/main/lib/jxl/dec_external_image.cc#L65

is there any real advantage to doing so other than reading/writing 32-bit floats?

sure, it only uses half the memory 🙂

well, if I'm using floating-point values I probably don't quite care about RAM

also it is what GPUs can natively work with, iirc

but from what you linked it appears there's a 32-bit-to-16-bit conversion there

yeah internally jxl uses 32-bit only

wait what

I thought internally it used 16-bit

no all buffers are 32-bit float

well except some auxiliary uint8/uint16 things, but all sample values and dct coeffs are internally done in 32-bit float

so from a client's perspective it's probably better to just interact with libjxl in 32-bit floats, assuming there's already 32/16 float conversions in the client

which FFmpeg has, for example

yes, unless you're like chrome and you want to keep the memory size of decoded images low

chrome uses 8-bit int buffers for SDR and 16-bit half-float for HDR, iirc

I'm thinking of FFmpeg where the user would probably prefer to select how to dither 32-bit float to 16-bit

yeah just using float32 is probably best, the half-float thing is mostly for things like OpenEXR and GPUs

oh, speaking of which, do we have samples of JXL files tagged as 32-bit float, both as grayscale, gray-alpha, RGB, and RGBA?

there's this one https://github.com/libjxl/conformance/tree/master/testcases/lossless_pfm

for grayscale and alpha it's currently somewhat annoying to make a bitstream since afaik we don't have an input format for that — PFM only does RGB

Isn't speed also a good reason?

Dealing with 16b ints for 8-12b content is better and faster for CPUs.

yes, I suppose — reducing memory kind of always is good for speed, memory bandwidth is often the bottleneck

FFmpeg supports Gray32f, you can make it with that

e.g.

`--bits_per_sample` doesn't work anymore in djxl. I get `Encode failed` when trying to get 16bpc png/ppm/pfm from VarDCT or 8 bit modular. I get <#805007255061790730> when going from 16 to 8.

(tried 0.7, 0.8 behaves a bit different)

I can repo the "Encode failed", but couldn't get the glitch-art.. Consider opening an issue about that; it shouldn't happen

is it fixed already in the git version, maybe?

I need a clarification regarding JxlAnimationHeader.num_loops ( https://github.com/libjxl/libjxl/blob/main/lib/include/jxl/codestream_header.h#L95 ) When num_loops == 1 it means that whole animation should play exactly once? Or does it mean the animation rewinds once after first run and then plays again (so totally 2 times)?

0 = infinitely, 1 = once, 2 = twice, etc

Thx for confirmation!

is this normal? im sure i used to be able to do 16 before ``` djxl 2_jxl/001.jpg.jxl --bits_per_sample 16 test.png JPEG XL decoder v0.8.0 [AVX2,SSE4,SSSE3,Unknown] Read 1643105 compressed bytes. JxlDecoderSetImageOutBitDepth failed DecompressJxlToPackedPixelFile failed```

Is that on current git version? There were bugs indeed

yeah current git

That's not good, could you open an issue?

Is the butteraugli API in libjxl thread safe? It might just be written down in the read the docs and I'm dumb.

Is there also docs for clarification on what HFasymmetry is?

when you say thread-safe, how do you mean?

all instances of the butteraugli api take a context struct

so you could have multiple threads running on different context structs and there should be no thread-safety issues

if you want to compute butteraugli in parallel for multiple images, this works

if you want to compute butteraugli in series, or butteraugli for one image, I'd recommend using libjxl's setparallelrunner thing and just let it parallelize the computtation

Okay thanks

Ah no wait, I meant if you could share the API pointer returned between multiple threads. I'd assume settings things like target intensity isn't but once it's properly configured it should be fine as long as all threads share the "same" settings.

consider the scenario where I want to get the Exif or similar metadata from a compressed brob box in the libjxl container

I subscribe to the `JXL_DEC_BOX` event

then that event is fired

I check the box type with decompress=true, it's `Exif`

do I then call `JxlDecoderSetBoxBuffer` and then *immediately* call `JxlDecoderReleaseBoxBuffer`?

or does there have to be a call to `JxlDecoderProcessInput` in between somewhere?

I don't believe there's anything that says you can do that. That being said if you have a result computed you can probably share the result struct between threads, as it's *const*

Damn, thanks.

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

not sure if this fix is ideal

the problem is that we don't update the JxlPixelFormat based on the requested JxlBitDepth

I modified the file so it does, but there might be some better way to shuffle the pipeline here

so this fix isn't required

Yeah in particular it would be nice if you can decode to 10-bit ppm etc too

well `libjxl` itself doesn't support that

but this fix just allows djxl to work with what libjxl currently supports

since `--bits_per_sample=16` is currently broken on git master

(and in release 0.7)

I gotta get to class though so I'll look at your comments later if you have any

You have to call JxlDecoderProcessInput and handle JXL_DEC_BOX_NEED_MORE_OUTPUT if triggered. When another JXL_DEC_BOX or JXL_DEC_SUCCESS is triggered, you can call JxlDecoderReleaseBoxBuffer.

I see, thanks. Can anything other than those two events (or error) be fired?

JXL_DEC_NEED_MORE_INPUT

ic

~~Sorry for so many questions but~~ the fucntion `JxlButteraugliCompute` expects linear RGB as a input right?

docs don't say. probably should, tbh.

Does `cjxl a.jpg a.jxl` preserve exif? exiftool (the `exiftool` from the latest https://github.com/exiftool/exiftool) says there is no GPS location as in the original jpeg file. My libjxl copy has this commit https://github.com/libjxl/libjxl/pull/1834

Sigh, exiv2 just doesn't display GPS location information for either jpeg or jxl. `exiftool -v3` says the original jpeg file has GPS location information under`[IFD0 directory with 13 entries]` Latest exiv2 prints some information but none is related to GPS ``` % /tmp/p/exiv2/out/release/bin/exiv2 PXL.jpg File name : PXL.jpg File size : 5028864 Bytes MIME type : image/jpeg Image size : 4080 x 3072 Thumbnail : image/jpeg, 37159 Bytes Camera make : Google Camera model : Pixel 6 Pro Image timestamp : 2022:08:28 16:03:57 File number : Exposure time : 0.001299 s Aperture : F1.9 Exposure bias : 0 EV Flash : No, compulsory Flash bias : Focal length : 6.8 mm Subject distance: 1.99 m ISO speed : 34 Exposure mode : Auto Metering mode : Center weighted average Macro mode : Image quality : White balance : Auto Copyright : Exif comment : % exiftool PXL.jpg | grep 'GPS Position' GPS Position : 37 deg 26' 56.84" N, 122 deg 9' 32.40" W ```

As a stopgap `--compress_boxes 0` will (as the name implies) disable compression of the metadata boxes so exiftool/exiv can read them again

Nice! ``` % /tmp/p/libjxl/out/release/tools/cjxl --compress_boxes=0 PXL.jpg PXL.jxl JPEG XL encoder v0.8.0 99b07212 [AVX3,AVX2,SSE4,SSSE3,Unknown] Note: Implicit-default for JPEG is lossless-transcoding. To silence this message, set --lossless_jpeg=(1|0). Read JPEG image with 5028864 bytes. Encoding [Container | JPEG, lossless transcode, effort: 7 | JPEG reconstruction data], Compressed to 4123834 bytes including container % exiftool PXL.jxl | grep 'GPS Position' GPS Position : 37 deg 26' 56.84" N, 122 deg 9' 32.40" W ```

it definitely preserves it as that allows bitexact reconstruction of the data

you can check if there's a `brob` box as well by using `jxlinfo -v a.jxl`

It looks like libjxl is not whining if `ZeroPadToByte` return a nonzero value.

Is this ideal?

Here's a sample:

This is the `bench_oriented_brg` conformance sample, with the container stripped off

the ICC profile ends mid-byte

according to spec these bits should be checked to be zeros iirc

unsure if this applies in all the places padding happens though

that's what I was wondering, I'm not sure if libjxl should be rejecting them

this *is* from a conformance sample, after all.

Good catch, this is not supposed to happen

It's not super critical, but we wanted to define all padding bits to be mandatory zeroes so it doesn't become a potential source of entropy if something ever needs to do jxl bitstream recompression (the way jxl can do that with jpeg)

does this mean that alignment padding is like `jxlp` 4-byte sequence numbers? for compliant files they can be ignored safely

yes

speaking of which, here's a container-based jxl file produce with `cjxl` and it contains two jxlp boxes

the second one contains a sequence number of `0x80 00 00 01`

which notably is not equal to one

why is this?

you can inspect it with `hexdump -C ants.jxl | less` and search for `jxlp`

I produced this by taking `cjxl ants.jpg ants.jxl`

here's the source

the highest bit indicates it's the final one

ah, so that's intentional

I thought it was supposed to be increasing in order, but if `0x80 00 00 00` is set, it means it's final?

yes

good, so that's not a bug then. I just wanted to double check.

I've noticed that cjxl always encodes GIF as RGB+Alpha even if transparency is not used.

it does? Are you sure the gif does not use transparency? multi-frame gifs typically do use it

(even if no rendered pixel is actually transparent, it uses transparency as an inter frame coding tool)

It does for static images as well.

The original GIF images are not transparent. Resulting JXLs are RGBA.

I suppose this might be a bug.

Yes, it likely is a bug in the gif reader

In general, we should probably by default strip trivial alpha since there are quite a few applications that produce RGBA pngs even when alpha is all-255...

The only complication is that in case of multiframe, the encoder gets frames one by one and cannot strip alpha from the first one if it doesn't know that the next ones will also not need it

(the presence of alpha is an image-wide property, not a per-frame one)

It seems to be working correctly for PNG animations. I'm going to open the issue for GIF.

Automatic conversions like removal of unused alpha or converting to grayscale if R=G=B would be useful. I'm not sure if it's always desirable to do automatic conversions during lossless compression. There should be an option to enable that. For lossy compression, I think those conversions could be enabled by default.

hello

https://chromium-review.googlesource.com/c/chromium/src/+/3988999

do you know why ?

See <#803574970180829194> and <#822105409312653333>

<@794205442175402004> thank you, so no real answer why, yet

In the Docker image I am getting these 2 build errors, anyone else see this? `tools/flicker_test/flicker_test_autogen/include/tools/flicker_test/ui_setup.h:315:26:` `error: no member named 'setStepType' in 'QSpinBox'` `error: no member named 'AdaptiveDecimalStepType' in 'QAbstractSpinBox'` `intensityTarget->setStepType(QAbstractSpinBox::AdaptiveDecimalStepType);` `~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~ ^`

those were added in QT5.12

looks like the docker image is using an incorrect QT version

That's what I thought <:SadOrange:806131742636507177>

at least that's what another project ran into with that exact error via a google search

so I'm guessing, but it makes sense

Hm... it's acting like QT doesn't exist...

`qmake: could not find a Qt installation of ''` 🤔

I ran apt update and installed qt, looks like the latest version for Bionic is 5.9.5.

I think the Docker image needs updated.

bionic is a 2018 image, which predates JPEG XL by a lot

might as well upgrade to 22.04 LTS

Jammy

Did that yesterday. There is 1 package that is 0.1 behind what was needed.

I believe Kinetic is the only one that can be used without installing packages outside the package manager.

Huh

I find all versions of ubuntu to be relatively stable

since they're not rolling. it's not archlinux

<@532010383041363969> Is there any function in libjxl that can convert a linear grayscale input into its pure Lightness component(HSL)? I'd like to attempt the low "luma" adaptive quantization mode after all since I feel a lot more confident doing so now 🙂

HSL is just a matrix transform on RGB btw, just like YUV

note that grayscale with XYB is just X=B=0

Yes, I know.

I'd just like to know if there was a function directly available already.

then I'm not sure what you're asking, since HSL lightness goes from black (0) to white (1)

so isn't this just requesting the output in float?

Yes.

when you request an image out buffer via `JxlDecoderSetImageOutBuffer` set the corresponding JxlPixelFormat appropriately

JxlPixelFormat has a field `data_type` which is of type `JxlDataType`

which is a typedefed enum, one of which is `JXL_TYPE_FLOAT`

this means that you're requesting 32-bit float

see: https://libjxl.readthedocs.io/en/latest/api_common.html#_CPPv411JxlDataType

also: https://libjxl.readthedocs.io/en/latest/api_common.html#_CPPv414JxlPixelFormat

Oh thank you, I didn't even notice that.

I should probably bookmark the documentation website.

JxlEndianness is useful to set to native in this case since it lets you reinterpret cast the `uint8_t *` as `float *` and it will work