JPEG XL

thanks

This was the result of a 21 channel image (Hence huge sizes and low settings), referencing 1 previous channel on the second row. So there are definitely savings to be made, but the encoder needs to be improved to do the same for frames instead of channels (Or at least something similar) ```Encoding kPixels Bytes BPP E MP/s D MP/s ------------------------------------------------------------- jxl:d0:2 19902 388341101 156.0957291 16.161 27.586 jxl:d0:2:E1 19902 340987540 137.0617185 9.782 13.807``` So depending on your workflow/use case, extra channels could be an option

is there any possible way to get previous frame data available to prediction trees? or is the only interframe stuff that's possible patches and blending on top?

You cannot get it in prediction, but you can do kAdd blending which means you just subtract the previous frame before encoding

Which is basically the same thing as using PrevFrame (corresponding pixel value at the previous frame) as a predictor

It also doesn't need to be the previous frame, it can be any previous frame

But currently you have to do this manually, it can be done with the libjxl API but only manually

Could probably test it with this https://github.com/kampidh/JXL-Frame-Stitcher

How significant is EXR support for libjxl? I am having problems with a few files but nothing too important.

ideally, it would work

I have an EXR file I created in GIMP that encoded fine to JXL, but djxl cannot decode to EXR. PNG PPM etc. work fine

I also have some EXRs that will have the same image signature if encoded to JXL at e1 but will differ in signature at higher efforts

Are you lossless?

Always, yes

This sample image is from the openexr github repo

This image will always have a different image signature, no idea why. Image signature of the EXR is 70916b4572ec6fbf5fcc09d1e9f31103619669c6ab8923d11141870b1a057e82 Image signature of the JXL decoded to EXR is 43088446e910f9a0e56361bc0c29083afd990d85d3cd29ef9630f9a82772fbcc

Maybe someone more knowledgable than I will know the reason

it’s probably metadata being stripped or moved around

EXR to JXL is not bit exact lossless

Getting image signature using ImageMagick's identify only compares image data

Some are, which is why I am a bit confused

https://files.catbox.moe/96q4f5.zip This EXR will have the same image signature if EXR -> cjxl at e1 -> EXR, that being 39e545aea2084e369257e1dd323bda6ae05bb24930a3d40e8801ff042c1c5fec. At e2 and higher it will always be 165e11d4ad6dc8ff8e92a877850dcfc34a32ecc2d8f6a7646c7cde31fd316d0b.

lossless alert 👀

I think that might be https://github.com/libjxl/libjxl/issues/3881

I see (0.0000, 0.0000, 0.0001) turning into (0.0000, 0.0000, 0.0000)

could be rounding issues / error

<@794205442175402004> how tricky would this be to solve?

i'll need to dig into it, maybe it's related to subnormal numbers?

So in the API, you can use `JXL_BLEND_ADD` to do this kind of inter-frame decorrelation - would this only work using `float` buffers? Because subtracting the reference frame will typically produce some negative samples. Or can you just allow uint8/16 samples to wrap around and expect `kAdd` to do the same in reverse when decoding?

negative samples are allowed AFAIK

Yeah, so is float the only suitable type for this?

Basically I'm starting with 8-bit frames and wondering if using kAdd would work better than my current approach of just setting all the identical pixels to transparent black and using `JXL_BLEND_BLEND`.

negative integers are also allowed

The API only accepts unsigned integer types though...

uh, hm

If the entire unsigned integer range is allowed, the negative signed range is also allowed.

This is what I meant about letting the subtraction wrap around. Will the encoder understand though, given that it uses float internally?

(I could write some code and find out - just thought I might get a quicker answer here :))

i.e., if I pass in 255 and 255 (-1) as uint8s, using JXL_BLEND_ADD, and then decode back to uint8, would the result be 254, or 510 clipped to 255? Wouldn't it get decoded as an out-of-range 2.0f sample?

I'm testing some EXR files and they're failing to convert with v0.11. I'm pretty sure they worked before… It's the image I used on the website. It it a known issue?

Mostly dealing with lossless, if it makes a difference.

I've seen a lot of EXR issues lately, including support being removed by default from the tools until it's fixed, but that might've been old news...

Thanks. I'll park that for now then. On a side note, looks like Apple's Preview in 15.1 beta fails to export EXR files at all now. Maybe if someone else is running it they can test before I report it as a bug.

I have had the same issue with multiple sample images from the openexr repo

Yeah with the API you would need to convert to float.

Yes it would decode to 2.0f, there is no wraparound

Makes sense, thanks!

Dumb follow-on question: if I was encoding uint8 or uint16 data converted to floats, how many `exponent_bits_per_sample` would I want in order to losslessly recover the uint8/uint16 samples?

I was thinking setting it to 0 wouldn't work if the samples were all floats in 0..1, but thinking about it... this setting is independent of the data type I'm supplying isn't it? So e.g. `bits_per_sample=8`, `exponent_bits_per_sample=0` should be fine for lossless round trip of uint8 even if the samples are floats in between(?)

Yes, up to bits_per_sample 24 it roundtrips losslessly

And I guess to account for `kAdd` delta frames with samples ranging from -1 to +1, it would need one extra bit beyond the size of the original integer type? I'll do some experiments...

Wait is 255 considered 1 or 255/256 ?

Say the image is 8-bit, you can just set it to 8-bit, use float32 buffers, pass the first frame using `value*1.f/255.f`, and pass the second frame using `(thisvalue-prevframevalue)*1.f/255.f` with kAdd blending, and that should work.

uint8 value 255 is 1.0f

Is it possible (in the future) to have a simple setting parameter to set the number of progressive layers, number between the first and the last... so as not to create cjxl fork just for this. https://github.com/libjxl/libjxl/blob/main/lib/jxl/enc_frame.cc#L207

Sure, we could expose more control over the progressive passes script.

https://www.trust-in-soft.com/resources/blogs/libjxl-code-unboxed?utm_source=lk&utm_medium=soc&utm_id=cdu&utm_content=cta_reg interesting way to promote a code analysis tool

A friend of mine who does a lot of testing and fuzzing told me that it's very easy to make libjxl segfault.

why did this person not open security issues? 😛

idk!

Nice ! Can you ask him to do so ?

if it can segfault does that open security vulns?

segfault *can* mean that there's an exploitable memory corruption, or it could just be something like a null pointer dereference (only impact there is denial of service)

I really wish the tree was better organized and segregated so it was easier to make sense of libjxl :(

Is this JPEG quantisation table low enough to decode to pixels? ``` 00: Luma 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 2 1 1 1 1 1 1 2 2 1 1 1 1 1 1 2 2 1 1 1 1 1 2 2 2 1 1 1 2 2 2 2 2 1 1 1 2 2 2 2 2 1 1 1 1 2 2 2 2 01: Chroma 1 1 1 1 2 2 2 2 1 1 1 1 2 2 2 2 1 1 1 2 2 2 2 2 1 1 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 ```

Look at the image, if you can't see mosquito noise then it's probably good enough

One very small problem: I’m legally blind

Yeah, that should be fine then

Also as an Australian I am really good at detecting mosquito noise

The nightly dev builds stopped updating/uploading again. 🥲

Oh! maybe because error checks.

How do I build jpegli (on Windows, for Windows) to get lib/dll files for x86-64 and arm64? When I build libjxl repo I don't get the files.

I follow the MSYS2 MING64 environment guide (Libjxl/doc/developing_in_windows_msys.md) and after the build i copy and paste the required .dlls from the C:/msys64/mingw64/bin folder.

better from the google/jpegli repo?

cmake option

iirc it's -DJPEGXL_ENABLE_JPEGLI=ON

not sure tho

jpegli is in a separate repo now <https://github.com/google/jpegli/>

Using `developing_in_windows_vcpkg.md` I substituted $VCPKG to vcpkg folder as said in instruction, all libraries are installed, but it still errors out: `include_jpeglib.h(16,10): fatal error : 'jpeglib.h' file not found`.

Sounds like you don't have the libjpeg-turbo dependency

maybe

maybe a problem with the build system... you can get jpegli by building libjxl with the cmake flags to enable jpegli

by default it builds for libjpeg api 6b

but you can set it to 7 or 8 with cmake flags

mozjxl anyone?

IJGjxltran

i recently saw JPEG-li

JXL-li \:D

in 30 years time

Jpegli = small JPEG

JPEG XL = extra large JPEG

JPEG Lite

JPEG 51 and JPEG 40

Uh how I could forget JPEG 51

looks both smaller and modern

GDAL's JPEGXL Driver shows bad behaviors for lossy compression of multispectral images. Can anyone help? Thanks! Problem described: test.tif is a 31x512x482 image, and lossless compression with the following command is as expected. gdal_translate -of JPEGXL -co EFFORT=7 -co DISTANCE=0 test.tif test.jxl But lossy compression with the following command using different values of d is as unexpected (I increase the d value (even up to 25), but there is still a big bitstream, i.e., no too much bit reduction but with reconstructed PSNR decreases). gdal_translate -of JPEGXL -co EFFORT=7 -co DISTANCE=d test.tif test.jxl

The behaviors are as expected for images with no more than 4 bands. For images with more than 4 bands, the command shows no error but the results are not as expected. Maybe my problem is related to the distance calculated using https://github.com/google/butteraugli ? I also have a small question about the d value. In the source code, I can see the minimum value of non-zero d is set to 0.01. But the convert function from q to d can only result in a non-zero d that is larger than 0.1. Setting a d value in [0.01, 0.1] will not get a warning in cjxl, but I can see a warning in gdal_translate if d is smaller than 0.1.

Distance for extra channels needs to be set separately from the distance for the main image, maybe that's it?

Thank you. I had tried to set alpha_distance before. And I did not see config for the extra channels.

I used `cjxl -v -v -v -v` to see all options. And I use gdal based on https://gdal.org/en/latest/drivers/raster/jpegxl.html

For GDAL, ALPHA_DISTANCE=[-1​/​0​/​0.1-15]: The default value is the special value -1.0, which means to use the same distance value as non-alpha channel (ie DISTANCE).

For cjxl, -a A_DISTANCE, --alpha_distance=A_DISTANCE Target visual distance for the alpha channel, lower = higher quality. 0.0 = mathematically lossless. 1.0 = visually lossless. Default is 0.

I had tried -a with different values before (I losslessly compressed tif to jxl with GDAL, then applied cjxl to the jxl file with -d and -a options). The behaviors are the same bad (i.e., for images with more than 4 bands, the total bits are approximately the same as the lossless ones even with larger d and a).

The libjxl version is 0.12.0, GDAL version is 3.10.0.

maybe GDAL is not setting the extra channel distances correctly?

You have to call `JxlEncoderSetExtraChannelDistance` for each extra channel, they can all have different distances

I also encountered the same issue with cjxl (With the jxl input file, no GDAL anymore.)

could also be that there's a bug in libjxl that causes it to not get passed properly, this is likely not something that has been tested well

well cjxl only knows about RGB and alpha, it doesn't have any options for all of the other extra channels there might be

So cjxl also cannot set extrachanneldistance except for alpha channel?

Got it.

(having jxl as input was added relatively late, and all other input formats don't have anything other than RGBA)

please open an issue for this, should be easy to add some option to cjxl to set distances for all extra channels

So maybe if cjxl did not call JxlEncoderSetExtraChannelDistance, the default value is 0, then I always got large bits for multispectral image compression?

OK, thank you, I will open a feature request.

https://github.com/libjxl/libjxl/issues/3906#issue-2607691300 Issue opened. Eagerly await the update. Thank you again!

If color profiles are a required part of jxl, how does that work if you have a bitmap of non visual data like a depth map

Is depth map linear or exponential?

Or any other kind of bitmap like a specular map

I think it would be linear... wouldn't make sense for it not to be

as the main image? then I guess the color profile would be however you want to visualize it

another option is to make a visual main image that can be anything, like some visualization of the non visual data or just an image with some application icon and text on it saying "this is not a visual image, this file stores data of type [DATA TYPE]", and then put the actual data in extra channels

Is it possible to create a bitmap with only an alpha channel and no other channels? Or maybe an image with multiple alpha channels for hue-dependent opacity?

I guess most of the time opacity maps are stored as a greymap

Every image needs to have at least some visual main image (RGB or grayscale), but of course you could make it an all-black image that compresses to a few bytes.

Yeah, most non image data is usually stored as rgb or grayscale too come to think of it, as existing practice.

Then rebuild libjxl from the source to test the results of the cases where 0<d < 0.01?

You want higher quality than d 0.01? Why not just d 0 for lossless?

lossless compression results in a large bpp. JPEG XL with (d>=0.01) cannot reach many lossy points that JPEG 2000 can get. For example, JPEG XL (d=0.01) results in a PSNRa, JPEG 2000 (q=44) can get a PSNRb >> PSNRa. So I cannot compare the BD-rate performance of JPEG XL against JPEG 2000 within the PSNR range [PSNRa, PSNRb].

What kind of image is it? Such low distance values are usually even larger than lossless

Even at d 0.2 I had a file bigger, yet alone at 0.01

uint16 multispectral images

Maybe the distance calculation for uint16 is the issue? just like something that official SSIM does not handle uint16 cases?

For example, I translate each channel of the ARAD_1K_0950.tif image to png images and use cjxl to compress them separately. Then add a header to combine the 31 bitstreams. Setting d=0.01 got bpsp=1.74 (smaller than lossless's bpsp=4.17), MSE=7.457365.

The actual bit depth of this image is 12.

Could it be related to this issue? https://github.com/libjxl/libjxl/issues/1763

Where the file is padded in the high bits instead of the low, resulting in very poor quality due to being so dark

Yes, it is a related issue.

This may also interest you https://github.com/libjxl/libjxl/pull/3611, as encoding them together allows reusing correlated data between channels <https://github.com/libjxl/libjxl/pull/3622>

Great, thank you!

The second link is even for spectral images too, so you can see real world results

Once the lowest bits are padded instead of the highest, you should be able to get far higher quality scores at much lower settings, and using the PAM optional channels should make lossless feasable too. Feel free to ask any more questions, although I'll be trying to head to bed myself

Thanks a lot. Good night! If there are still questions, I will leave messages here.

By setting `--intensity_target=4095` for my 12-bit data, I can reach a similar MSE with cjxl (d=0.01) ,i.e., `MSE=0.3146`, compared to JP2OpenJPEG (quality=35) with `MSE=0.2885`. Lossless mode: JPEG XL > JPEG 2000, but it seems JPEG 2000 > JPEG XL in lossy mode for the uploaded data ARAD_1K_0950.tif. Is this result reasonable?

By setting `--intensity_target=65504` for my 12-bit data, I can reach an MSE of `0.0155` with cjxl (`d=0.01`). So I can just shift the R-D curve by setting a different `intensity_target` value? In this setting and the lossy compression mode, for ARAD_1K_0950 data, JPEG 2000 seems better. I would test on more data to get a statistical result.

It's not exactly the same thing I think. Is your data visual or similar to visual?

I have not visualized the R-D curves. I just had a look at the R-D pair values of different settings. Yes, they were not the same thing, but they showed a similar trend just like a shift of the "whole" R-D curve.

Are there really no libjxl builds after 24th September? If I look in the Release build / deploy folder, there are just red X icons everywhere. Am I missing something?

Looks like it. https://artifacts.lucaversari.it/libjxl/libjxl/latest/ No new builds.

are jpegli nightlies only available as part of libjxl's btw ?

From what I see it's incorrect padding again https://discord.com/channels/794206087879852103/804324493420920833/1298859690373152800

yes, if you use uint16 but only use values 0-4095 then that will be interpreted as a very dark image

basically if the PNG looks like it should, all will be fine with the jxl

But if it's not visual data in the first place, then you should probably use `--disable_perceptual_optimizations`

I linked them to some relevant issues and the PAM extra channels PR to get better results

I'm late, but I should've linked to bottom of the issue. Intensity target mitigates the issue, but the root cause is incorrect 16bit padding for the 10bit data

Having to set JXL to be practically lossless to barely match J2K at quality 35 should've been a hint that something is wrong, although you did come here which was the right choice

That is the case for the maximum intensity of the true data. If I set `--intensity_target=65504` for the 12-bit data ARAD_1K_0950, A much smaller MSE (0.0155) can be obtained than JPEG 2000. So for a given `distance` or `qaulity`, I can just set a larger `--intensity_target` to get a smaller MSE (without handcrafted padding).

This data includes 31 bands of visible light, with wavelengths ranging from 400 to 700nm, and is visual data. Maybe I should also try pre-padding and post-processing the data to cover the full range of 16-bits instead of setting a larger `intensity_target`.

I have another small question. Does libjxl support inter-frame prediction (as said in the white paper) for apng file compression? Or do I have to merge the frames of the anpg file to a multispectral image and apply "inter-band prediction" by setting `-E` (and what is the best practice of `E` value)? In the meantime, I will need the option to set extra channel distances if I want to do lossy compression of multispectral images with more than 4 bands using `cjxl`.

<@446428281630097408> was encoding 21 channels of multispectral satellite imagery in the past, I know we spent a few days helping them and even improving the encoder to make it more suitable. Maybe they have some input

Although, if I recall that was lossless, so the distance issue wasn't apparent...

Yes it was lossless, for lossy I'm using video codecs since it's a time series. Of course channels per file are limited in video...

Thanks. I can use GDAL's JPEG XL for direct compression of multispectral images. Can I do this using cjxl? cjxl does not support tif, I translate tif to jxl losslessly. Then apply cjxl to the jxl file to get a new jxl file, but I cannot reconstruct the original jxl file through djxl (it is not supported). So is there any way to conduct tif file (with more than 4 bands) compression with cjxl and djxl?

> I translate tif to jxl losslessly. Then apply cjxl to the jxl file to get a new jxl file What does this mean? If you're already making a JXL file why do you need another?

I want to apply "inter-band prediction" by setting `-E=1` which is not supported in GDAL's JPEG XL Driver. So I just use GDAL's JPEG XL Driver for losslessly translating tif to jxl (to get an acceptable input format to cjxl).

Ah, I see

libjxl cannot "reconstruct" jxl from jxl, jxl-to-jxl conversion would be always re-encoding

I test cjxl on an apng file. It seems that there is no "inter-frame prediction". Thus, the results are similar to the case that using cjxl to compress all png files from single channel.

So, if I want to test the `-E` option on multispectral images (with 31 bands) in tif format, how can I do?

no idea, I'm not familiar with tiff; though if the application conforms to jxl spec, it shouldn't be a problem to embed newly encoded jxl...

You should be able to create a lossless JXL with GDAL, then.... Hmmm... We may be stuck due to the 'broken' distance setting for extra channels

it should be able to decode valid jxl image

The issue here is that only RGBA can have distance set in cjxl currently, so the other 27 channels are stuck as lossless, as far as I understand

Also the other channels can only use modular instead of the more vision based VarDCT

Yes

(All the more reason for lossy modular to improve, I see quite a lot of untapped potential)

Another thing is that I can apply cjxl to the lossless JXL file obtained from GDAL and get a tmp.jxl, but I do not know how to decode tmp.jxl to my data.

basically libjxl doesn't know how to lossy encode arbitrary extra channels in sensible way

If you want to go that route, this discussion may help somewhat https://discord.com/channels/794206087879852103/804324493420920833/1294414119541411924

If I recall running djxl -h -v -v might expose an extra channels option to write them all to PNGs again. At least for testing...

I see. But the lossy mode should be also needed for extra channels.

I personally don’t understand why even just grayscale VarDCT couldn’t work in extra channels but whatever

Thank you for this info `--output_extra_channels`

To get a very rough idea of the compression, you could store 4 of the channels as RGBA, then use `cjxl -m 1 -E 11 input.png output.jxl` to use Modular mode with the only with control over quality, bearing in mind the incorrect padding still...

Currently, I just did single-band compression with cjxl. Or just apply cjxl to apng file with band dim as frame dim.

How can I read the -ecN.png file? I successfully got one png file for grayscale and the other 30 extra channels as -ec{01...30}.png. I use PIL's Image to open it, it seems only the main png can be opened.

Huh.....

This is where I usually get new builds but after a month without updates I checked Github and there seems to be some problem preventing successful builds.

Afaik jpegli was supposed to be moved to the separate repository but it seems it's still part of libjxl.

Correct, cjxl/libjxl will just encode frames independently as they are given, it doesn't try to do anything inter-frame. You can manually try subtracting the previous frame from the current frame and setting the blend mode to kAdd instead of the default kReplace, to see if that helps.

(but that requires hacking cjxl or using the library API directly)

Extra channels are always modular. VarDCT is meant only for visual data for which the encoder knows how it will be perceived, so we decided not to allow it for extra channels (also to keep things simpler, since dealing with multiple sets of VarDCT data that each have their own control fields would get hard to implement efficiently).

once the encoder is fully developed and optimised, will lossy modular become close to / as good as VarDCT?

also for non-visual data should i be using Modular?

I think it depends on what kind of non-visual data it is, i.e. what kind of artifacts are acceptable for it.

The flag --disable_perceptual_optimization can be used to make VarDCT just optimize for PSNR instead of trying to do something perceptual

im playing with using JPEG XL as an audio codec (again)

I'll have a look at that, thanks!

I would recommend using lossless if you don't have a good psychophysical model to estimate distortion.

`Unknown argument: --disable_perceptual_optimization`

https://github.com/google/jpegli/

You forgot the s `--disable_perceptual_optimizations`

Thank you for explaining the "inter-frame". Do you have any suggestions on reading the -ecN.png file?

Related to this comment.

no idea, do those files open in a normal viewer?

They can not be viewed. These *-ecN.png files are the outputs of djxl by setting `--output_extra_channels`.

are you using the latest version from git? could be there's a bug that needs fixing

Yes, I built libjxl from the source several days ago (the showed version is 0.12.0).

79e02d0

I guess we have a djxl bug then, if it is writing png files that cannot be viewed

`--output_extra_channels` If set, all extra channels will be written either as part of the main output file (e.g. alpha channel in png) or as separate output files with suffix -ecN in their names. If not set, the (first) alpha channel will only be written when the output format supports alpha channels and all other extra channels won't be decoded. Files are concatenated when outputting to stdout. Only has an effect when decoding to (A)PNG or PPM/PNM/PFM/PAM. The separate output files with suffix -ecN in their names are in the format of *-ecN.png. But I am not sure whether these output files are png files.

as simple as `file --mime-type xx-ecN.png` to find out

I was going to say "Just upload it here", but these images are probably very high resolution

One extra channel file is uploaded.

JPEGXL-E_0_50.png-ec20.png: application/octet-stream I got this after `file --mime-type xx-ecN.png`

strange

these non-PNG PNGs ring a bell

I wonder if I didn’t come across this a few weeks ago

these are the first bytes

and the end

it does look like a PNG excerpt, doesn’t it?

yeah

just not complete somehow

Is it trying to write an APNG and just splitting the IDATs instead?

So the viewer told me that this file is broken. But I just got it from the `djxl` command with `--output_extra_channels`.

are you using an "old" version of libjxl ?

The very recent version.

I built libjxl from the source several days ago (the showed version is 0.12.0). commit 79e02d0

This looks like the PNG header is somehow missing?

Do the extra channel files share the same header as the main png of the grayscale image?

I tried some methods to fix the png, but it did not work.

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

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

The bug reported in that issue (3407) is: `--output_extra_channels` does not work and only a single PNG is written. But what I am facing is that the extra files are written (but maybe not in the correct way?).

Yes, but that's the PR that 'fixed' the PNG writing, but obviously it didn't...

maybe it is writing the extra channels in the same way it would write extra frames in an APNG

The extra channels are written into a file named with `Filename` function in https://github.com/libjxl/libjxl/blob/main/tools/djxl_main.cc#L294 The process happens at https://github.com/libjxl/libjxl/blob/main/tools/djxl_main.cc#L609

Yeah, that was my guess. Although it makes me wonder if outputting APNG would therefore work

I can have a try by setting the output to apng

apng_name = 'JPEGXL-E_0_85.bin.apng-ec07.apng' im = APNG.open(apng_name) len(im.frames) # 0. This is 1 for JPEGXL-E_0_85.bin.apng

So simply changing .png to .apng does not work

> .deb packages / debian:trixie > > Unsatisfied dependencies: > builddeps:. : Depends: libgimp2.0-dev but it is not installable All other binaries are available if you scroll down <https://github.com/libjxl/libjxl/actions/runs/11397389868>

I see. Thank you. So the builds apparently fail only partially.

i see some but not downloadable. does it require being logged in ?

I think so yeah

any chance the public nightlies could update again? they werent since september

I'd be curious to see a checklist of what components are implemented and what features they're for as the new codebase grows https://github.com/libjxl/jxl-rs/pulls

AFAIR they said that it would take two months. And it's been 1.5 months since Firefox's announcement, so release is very soon

you are assuming we've been actually working on it for those two months

we? Are you a dev on the rust jxl implementation?

yes they are. anyone in this server with the `core dev` role is an official JXL dev

He is the main (and only?) person working on it :)

He's really good at writing optimized assembly too

Multiple ppl are now involved, even including Tirr

libjxl will sometimes produce very large files compared to source with some `--faster_decoding` levels enabled. With the file I have tested this seems to only happen at efforts 4 to 7 and faster_decoding 1 to 2. I have only tested a single file, the input is an APNG derived from a GIF. ``` Source file: 2,1M skd5avtuo3ac1.apng ----- faster_decoding 0 2,0M fast0_e1.jxl 2,0M fast0_e2.jxl 6,5M fast0_e3.jxl 2,1M fast0_e4.jxl 2,2M fast0_e5.jxl 2,1M fast0_e6.jxl 2,0M fast0_e7.jxl ----- faster_decoding 1 2,0M fast1_e1.jxl 2,0M fast1_e2.jxl 6,6M fast1_e3.jxl 265M fast1_e4.jxl 247M fast1_e5.jxl 247M fast1_e6.jxl 247M fast1_e7.jxl 2,1M fast1_e8.jxl ----- faster_decoding 2 2,0M fast2_e1.jxl 2,0M fast2_e2.jxl 6,6M fast2_e3.jxl 265M fast2_e4.jxl 255M fast2_e5.jxl 255M fast2_e6.jxl 255M fast2_e7.jxl 1,6M fast2_e8.jxl ----- faster_decoding 3 2,0M fast3_e1.jxl 2,0M fast3_e2.jxl 6,6M fast3_e3.jxl 1,5M fast3_e4.jxl 1,6M fast3_e5.jxl 1,6M fast3_e6.jxl 1,6M fast3_e7.jxl 1,6M fast3_e8.jxl ----- faster_decoding 4 2,0M fast4_e1.jxl 2,0M fast4_e2.jxl 6,6M fast4_e3.jxl 1,5M fast4_e4.jxl 1,6M fast4_e5.jxl 1,6M fast4_e6.jxl 1,6M fast4_e7.jxl 1,6M fast4_e8.jxl ``` faster_decoding 1 and 2 at efforts 4-7 bloat up the filesize by over 100 times. According to the documentation `higher values improve decode speed at the expense of quality or density`. Any idea why higher efforts starting at faster_decoding 3 results in a small result than lower faster_decoding levels (well, those that do not output gigantic files)?

Likely disabling more advanced features and falling back to LZ77, ect which works well on that image

But it's known https://github.com/libjxl/libjxl/issues/3532

> making faster_decoding > 0 do the same as fd0. Hmmm

Yeah, imo faster_decoding is just a useless footgun

I never saw a significant decode speed boost when I tested it

Huh? I get a 20-40% boost in decoding speed, I would consider that significant.``` djxl --disable_output --num_reps 10 normal.jxl JPEG XL decoder v0.11.0 4df1e9e [AVX2,SSE2] Decoded to pixels. 2048 x 1080, geomean: 106.483 MP/s [104.26, 113.53], , 10 reps, 12 threads. djxl --disable_output --num_reps 10 faster-dec1.jxl JPEG XL decoder v0.11.0 4df1e9e [AVX2,SSE2] Decoded to pixels. 2048 x 1080, geomean: 120.869 MP/s [113.56, 132.01], , 10 reps, 12 threads. djxl --disable_output --num_reps 10 faster-dec4.jxl JPEG XL decoder v0.11.0 4df1e9e [AVX2,SSE2] Decoded to pixels. 2048 x 1080, geomean: 147.755 MP/s [141.99, 151.44], , 10 reps, 12 threads.```

it was massive in the past

should fast decoding be an encoder parameter? youd think its your viewer's decoder that can tier the effort it puts into opening images, like opening at half resolution, at a different bit depth if your monitor's differs or whatever other compromises make sense

fast decode in the encoder seems to only suit super niche uses smaller filesizes would accomodate better

probably for lossy it makes more sense to do faster_decoding than it does for lossless. For lossless the regression in density can be much more substantial and the actual impact on decode speed is less predictable

for lossy it is mostly doing stuff like disabling filters which has a rather predictable effect on both quality and speed

For lossless, faster decoding conflicts with low efforts like 1 that have specialised codepaths. Do you choose a low effort, or a high one with faster decoding? Most would pick decoding, but then you get the worst of both worlds with no fast codepath and no advanced JXL features

not really niche. I would use it in most cases if the penalties werent so harsh

If you were to do something similar in the decoder, you might as well just enable progressive decoding instead

Jon had an image decode speed browser test

The faster decode images were the same speed

It's pretty useless especially since low effort encoding produces files that are decoded faster than faster_decoding

If the option was removed entirely or replaced with a noop I would not mind

for me, doing e7 fd3 was a massive improvement, enough to make jxl viable for a mezzanine

e1-4 I found to not get close for size:quality:speed

I think it depends on what heurestics the image triggers, and if those are then blocked by faster_decoding

Hey there! I've been using XL Converter from Codepoems ( https://codepoems.eu/xl-converter/) for a while to convert my photography library to a lightweight jxl bakcup. I'm trying to write a script using libjxl to automate the process but im just unable to match the level of compression from his outputs. The same files using his program go from 12 to 1mb while using `cjxl` with the same effort and quality numbers give me a dramatically bigger size output 12 to 10mb. Any advice?

I'd guess the input is JPEG?

Oh, yeah i forgot to mention! Input is JPG and the output is jxl

XL Converter was probably doing lossy encoding, while cjxl does lossless transcoding for JPGs unless explicitly disabled

Oh, let me give it a try! I assumed increasing the distance setting would automatically turn it lossy

You can add `-j 0` to disable transcoding, but bear in mind that means you can't get the original file back anymore

Same output, quite interesting! I'll try to take some time later today and take a look at the source code of the program to see if he's doing anything funny and report back

Thanks for your help tho 🙂

Well nevermind, i did some mistakes and the script was ignoring the options so it was constantly running the default cjxl conversion 😅 Cant believe i spent so much time on this... Still, thanks a lot for your help!

Keep in mind that the larger files are lossless and reversible, and you can get the original jpeg back. Are you sure you want to irreversibly degrade the files?

Are there still conditions where libjxl will call abort in version 0.11.0? The release mentions that it was fixed for out of memory errors, but I wasn't sure about other things like file corruption.

Well, abort() issue (#1450) was closed as complete, and a lot of stuff was changed for that (#3631, #3639) Do you still have an old version of your plugin that causes libjxl to abort()? You can test it that way.

Last night I was playing with JPEG decoders and noticed that djpegli improves decoding quality, as advertised, but decoding the transcoded JXL has no improvement and actually dithers the output unnecessarily

Or maybe it was the blur mentioned here hiding artifacts... https://github.com/libjxl/libjxl/issues/1470#issuecomment-2197992496

oh hey that's me lol, I was gonna ask if the djpegli and djxl decoders should be consolidated into one. It seems weird to have 2 different "new and improved" jpeg decoders. Which is the more accurate one? idk ¯\_(ツ)_/¯

It would be nice to have both decoders be consistent at least

The JXL one was identical for the JPEG I was testing with last night, just with dithering in the dark areas for some reason. jpegli smoothed the image but I can't tell if that's actual improvement or the blurring you mentioned, since the file was quality 30 so heavily covered with noise

I do know jpegli also made the banding in the image less harsh and actually adjusted colors to be more accurate(?)

According to all metrics I tested (butteraugli/dssim/ssimulacra2) djpegli is in fact more accurate. My only gripe with it is that I don't like how it blurs really small details. It's not a big deal for quality 30 jpegs since all fine detail is destroyed anyway, but for quality 70-90 jpegs it kinda bothers me a bit.

cjpegli also has a similar blurring tendencies but there is an encoder flag to fix that. For djpegli there is nothing. I have a strong bias against blurring so it's not the end of the world but it's definitely a peeve of mine.

Are you using 16-bit output for both?

I was using 16-bit output idk about jonnyawsom

I was using 8-bit djpegli and Irfanview for the JXL

What encoder flag would that be by the way?

For djpegli it's `--bitdepth 16` For djxl it's `--bits_per_sample 16`

I meant to fix the blurring

Oh for cjpegli?

And I did do a quick test with 16-bit, but it didn't have an effect noticable enough for me to remember

Yeah

It's `--noadaptive_quantization`

Oh.... I guess that makes sense but it certainly wouldn't have been the first option I'd guess

Adaptive quantization only really helps when the quality is very very high (simulacra ≥~88) and/or XYB mode is used.

Other than that it kinda makes the image look worse to me

This isn't just my own subjective opinion, metrics also backup my claim but I can't find a good script to test against datasets like CID'22

Isn't 90 the default? Or is that only for cjxl

Yeah 90 is the default, and that's the lower bounds of quality I would recommend using adaptive quantization for YUV jpegs

At quality 80 it starts getting a lil blurry

XYB is exempt from this problem, too much chroma noise if it's disabled, so I found it best to leave on for most quality ranges

I'll post my findings in a new forum thread after I'm done eating lunch

I just made a new 'lossless' photo out of a raw (It's not great quality but resizing by 5 at least removed any artifacts :P), so I'll do some tests in a while

`JLI.jpg 84.09, JLI8.png 85.37, JLI16.png 85.48, JXL.jxl 85.75, JXL8.png 85.58, JXL16.png 85.78` Some ssimulacra2 scores. As expected the original JPEG is lowest, djpegli adds an extra point, 16-bit adds 0.01 and 0.02 for JPEG and JXL respectively. Weirdly the JXL decodes to different scores as PNG, with 8-bit loosing 0.17 and 16-bit gaining 0.03

But I was right, the JXL file dithers dark areas, even though it's already 8-bit, or should be... `JPEG XL image, 1623x1080, (possibly) lossless, 8-bit RGB`

Original, jpegli, djpegli 8-bit, djxl 8-bit

jpegli 16-bit, djxl 16-bit

1000% zoom bottom left, JXL and jpegli 8-bit

Compression artifact

This is transcoding though

Unless it's caused by CfL...

Does CfL run with transcoding?

I'll have to check later

First comparison complete: https://discord.com/channels/794206087879852103/1301682361502531594

Gonna work on a nonphotographic example after college classes.

Disabling CfL actually improves the score by 0.04 and encodes slightly faster but makes the file 300 bytes larger. Still dithered though

are we talking about direct jpeg to jxl transcode?

Yes

`--jpeg_reconstruction_cfl=0`

`Oxide8.png 85.64, Oxide16.png 85.79, Latte8.png 85.64, Latte16.png 85.71` Oxide and Latte don't have the dithering, and actually score (marginally) higher than djxl

My best guess is the dithering PR for djxl is getting trigged somehow, even though all files are marked as 8-bit

And just for completion's sake Oxide 8-bit, Oxide 16-bit, Latte 8-bit, Latte 16-bit

Oh... It literally just always dithers if the image is 8-bit, if I'm reading this right https://github.com/libjxl/libjxl/pull/3090

Is libjxl fuzz tested against invalid files?

I would assume so, but I don't know.

I think one of the developers implied that it was...

Either way I hope so

it is

there shouldn't be, unless there's a relatively serious bug of course (some code paths abort if the alternative would be to segfault, but I am fairly confident those code paths should not be reachable)

IIRC, CfL when doing jpeg recompression is done so the quantized coeffs don't change (so the original jpeg can still be reconstructed), but it may still have an effect on the dequantized coeffs. Whether the effect is better or worse depends on the image but I would assume it is typically slightly worse. In any case the difference should be small and within the threshold of what a conforming jpeg decoder is allowed to do.

In the process of discovering that, I found out the roof of the cathedral matches almost exactly to one of the DCT shapes. Even at d25 it had near perfect edges

Is CfL some form of prediction step?

It’s like chrominance from luminance or something

Is it using the Luminance to predict the chrominance?

Yes

According to repo, there supposed to be lib/jpegli folder with dynamic library binaries. I see lib\include\jpegli and lib\jpegli-static.lib, but no lib/jpegli folder.

jpegli is being moved to its own repo

I wish it wasn't...

Yeah, I'm having too much trouble with this. Does anyone have pre-built dll? The one that does not require cygwin/mingw installed on end-user machine.

I don't use windows as a development system so I can't help you

UNIX master race

Doesn’t jpegli share a lot of code with libjxl?

Bundling them could theoretically help with adoption of the new format...

I really wish the non-library code was separate, not jpegli...

All the stuff in lib/extras for example

Should go in a separate repo like libjxl-utils

Then there are less dependencies for people who only care about building the library code

I don't think so, no

There is some overlap iirc. But in general the libjxl repo is too bloated with all kinds of other stuff that is not libjxl. With jpegli in particular it became a bit of a problem since many issues and pull requests on the libjxl repo were about jpegli, which was not an ideal situation. That said, I do think it would actually make sense to tie libjxl and jpegli together in a single high-level library that can read/write both jpeg and jxl.

Good idea to have universal library.

It really perplexes me, to separate library code from library code, going in that direction instead of separating the frontend code...

Oh yeah, I've been meaning to ask but could someone upload their static Windows copy of 0.8 cjxl? The binaries on the Github are either missing or not actually static

This is... Painful. Think they're using ChatGPT? https://github.com/libjxl/libjxl/issues/3936#issuecomment-2480821860

Using a variable called `JXL_ENC_FRAME_SETTING_RESPONSIVE` and labelling it Adaptive Quantization, then using photon noise with what I assume is the AV1 noise synthesis settings and description...

Seems likely now that you mention it... Not sure where else you'd get such specific and wrong descriptions.

Suddenly had a thought. --progressive_dc=2 adds a 512 sized VarDCT image as a preview right? What if we changed it so the value corresponds to the distance of that VarDCT image, assuming it's not already low and that we can control it at all

The DC images have to be high quality, otherwise the final image will be low quality...

I thought the DC itself is still encoded like --progressive_dc=1, but an additional VarDCT frame is loaded first for huge image previews

You can have a separate preview frame that can be whatever you want, but with DC frames (including nested ones) the quality has to be very high because there is no way for the AC to bring corrections to inaccurate DC values...

So Progressive_dc 2 is a VarDCT base, with modular DC residuals, followed by AC?

What libjxl does now for that is first a modular LF frame at 1:64 resolution which is the LF of a varDCT LF frame at 1:8 resolution which is the LF of the actual varDCT frame

Anyone else getting `CodecTest.TestRoundTrip` failures when running the libjxl unit tests?

Also when is modular mode gunna be the default for lossy? It already does equally well or better than vardct does in human comparisons despite getting far less tuning and attention, so it seems to hold a lot more promise honestly.

improving performance by writing less code https://github.com/libjxl/libjxl/pull/3944

😛

using a conversion to float feels a bit like cheating but what can you do

fp unit counts bits for us

I suck at reading intrinsics — what's the float trick that is used here?

converting integer to float and using its exponent bits to get integer bit length

oh, and there's no equivalent simd instruction to just count leading zeroes in ints directly? feels like that should be possible with less effort than doing a full conversion to float

AVX512 has such an instruction, but AVX2 doesn't.

I suppose once AVX10/256 starts appearing in chips, it will be more common.

That’s actually very clever

I figured out this was the best way for rbrotli https://github.com/google/rbrotli-enc/blob/main/lib/src/hashtable.rs#L203 but I'm sure it's been known for a while

Just to check: when a new version of libjxl is released, if I only deal in lossless, is there any benefit to reencoding previously encoded images? At most I'd expect a possible reduction in file size if there were improvements to an effort setting/a new effort setting, yeah? Or am I mistaken?

Generally I'd just keep your existing files unless it's a major revision and people are talking about the improvements. Generally it might only be a percent or two, maybe even in the negatives if the tweaks were trading for speed

Currently nobody is really working on encoder improvements afaik. Focus is on jxl-rs and making sure there are no (security) bugs in libjxl.

Yep... No point in reencoding. There are still lots of potential improvements left on the table in terms of lossless encoding compression ratio and speed improvements, but at the moment no one has anything major like that ready or scheduled.

libjxl doesn't come anywhere close to the possible potential of the format and there's a lot of room for improvement left on the table, if someone gets around to either submitting a pull request or writing their own encoder.

Good to know. I'm in no rush to see any improvements. Glad security is the primary concern at the moment.

This isn’t libhwy right? This looks like intel intrinsics

If libjxl already has platform specific intrinsics then might as well have fpnge in the tree also

If you use fpnge then the intrinsics are even able to run cross platform

I mean if you use simde

It provides cross platform fallback implementations of intrinsics with minimal overhead

It's great

See? It does look better...(we totally didn't spend 3 hours fumbling in the dark trying to get blue noise to work making dumb mistakes). The blue noise LUT is 64x64 rather than 8x8 to avoid repeating patterns (no speed penalty!). Also, uncorrected means that all the numbers don't quite average to 0, it's more like 2.45 x 10^-9 or something like that. There is room for improvement considering our hacky caveman code indicates anything.

Here are the speed numbers, 150 reps, 12 threads``` 386.667 MP/s [280.59, 412.26] - blue noise 386.671 MP/s [258.49, 408.27] - ordered noise ```

We are doing more testing with inputs with no initial noise just as a sanity check

Uh, what's goin' on here?

Looking at the sunrise thinking "Damn... That'd dither well"

Real truth

Worst case bayer matrix behavior

Basically there's no downside to using blue noise, it's a free quality upgrade, and the exact same algorithm, just a different LUT. Of course whether you use a blue noise matrix or a bayer matrix, a larger table is better

In this case using a 16x16 blue noise matrix ended up causing equally if not more distracting patterns. 32x32 might've been good enough but we went with 64x64 just to make sure. Could also be our botched implementation not scaling it correctly, or it not averaging to 0. Needs work but the results are promising

A small matrix size will cause worse repeating patterns regardless if it's a bayer matrix or any other matrix.

Weirdly the smaller blue noise matrix had a distinctive L shape in brightened pixels. So using different textures could help a lot

https://github.com/libjxl/libjxl/blob/main/lib/jxl/render_pipeline/stage_write.cc I don't really understand why it says the matrix was doubled in width to avoid out of bounds reads. When or why would there be an out of bounds read, and why is doubling the matrix better than just fixing out of bounds memory access?

it means unaligned reads are still just one read instead of having to implement circular reading yourself

if you have `a b c d`, read from index 2 and want `c d a b` back, if you duplicate the array as `a b c d a b c d` then you get that automatically

instead of having to read only two from `c d` and then having to read `a b` from the beginning separately

I guess that makes sense... Either that or an internal, reusable circular reading function

a common trick with cicular buffers is to map the same physical memory to two virtual ranges next to each other

In this case it is at the level of a single simd instruction so I don't think that would work here...

Instructions don't operate on virtual memory?

the matrix is much too small, since pages are 4096 bytes (or bigger!) and the numbers aren't duplicated way at the end anyway, in terms of linear memory they appear to be in-line

I've stayed up until 7am again, this time finding a paper from 1997 describing how to make a Blue Noise LUT. The results there are a lot better than what we got

oooo, sounds interesting. I'll give it a shot after finals <:FeelsReadingMan:808827102278451241>

Can you share it ! I'm curious to understand how noise shaping can be implemented!

https://www.imaging.org/common/uploaded%20files/pdfs/Papers/1999/RP-0-93/1786.pdf

re: figure 20 (page 16), while the dot-on-dot matrices may produce more luminance modulation, I personally find that less objectionable than the chroma noise from the other three approaches

although this is perhaps less true as dots get smaller?

Yeah, the other three remind me of the lossless photon noise using XYB on RGB images

The CMYK JXL test image uses 255 for white. Is there documentation or metadata that tells readers if a CMYK image uses 255 for black or white?

I am in the process of adding CMYK load support to my Paint.NET plugin, and the image library I am using uses the convention where 255 is black.

> The K channel of a CMYK image. If present, a CMYK ICC profile is also present, and the RGB samples are to be interpreted as CMY, where 0 denotes full ink.

in short, 255 is always white (no ink)

Thanks

I hate CMYK so much lol

Bayer matrix can be a stylistic choice, like pixel-art version of crosshatching.

That can be somewhat mitigated with pseudo-random rotating, seeded with coordinates.

It's basically a moire pattern

bayer can cause moire pattern

The moire patterns can easily be mitigated with blue noise

We literally just swapped out the LUTs

It looks way better with no performance cost

I'm surprised our naive implementation looks as good as it does

That was with a non-normalized matrix, with likely incorrect scaling too

Just an old blue noise texture and some ChatGPT code to turn the PNG into a matrix

blue noise cannot and does not cause moire patterns

Yeah, that's why we want to use it instead

Are there any examples of how to implement libjxl's JxlChunkedFrameInputSource?

From the API documentation and libjxl source code, the intended usage pattern appears to be: 1. Set the output pixel format in get_..._channels_pixel_format. 2. Allocate and fill a buffer with pixel data in get_..._channel_data_at, returning a pointer to the start of the buffer and the row stride. 3. Free the allocated buffer in release_buffer.

It appears that libjxl expects JxlChunkedFrameInputSource to return a buffer that is the same size as the image, at least that is the behavior I have observed when trying to use it.

JxlChunkedFrameInputSource works correctly if it requests the full image, but it outputs a mess of corrupted tiles when xpos/ypos != 0 and the caller returns a buffer that is only big enough for the requested tile.

I may be misunderstand the design or expected calling sequence, but it seems silly for a streaming API to only work correctly in full size buffers.

How involved would lower bitdepth modular codepaths be? I assume it's far more than "If the image is 8bit, use uint8 instead of float32" or similar, especially when handling images under 8bit like 1bit monochrome

Should discussions around jxl-rs go here?

Sure. If the mix of libjxl and jxl-rs becomes too much we can always add another channel and split it up, but for now it can go here

whats the current state of jxl-rs?

https://github.com/libjxl/jxl-rs/issues/58 https://github.com/web-platform-tests/interop/issues/700#issuecomment-2551623493

I almost added a jpegli thread to <#1019989424232222791> with all the tests I had been doing lately

Are there long-run plans for jxl-rs to be able to decode plain-good-old-jpegs? Probably somewhere in this discord I've read that jxl decoder library has many tools needed to decode jpeg; what would have to be added, apart from container format parser (JFIF?) into complete JXL decoder implementation to be able to decode JPEGs? Huffman decoder is already there... <https://github.com/libjxl/jxl-rs/blob/main/jxl/src/entropy_coding/huffman.rs>

probably best keep it separate from whatever decoder for jpeg system already has (wich could be a bigger lib covering many formats)

if losslessly transcoded jpeg->jxl work it should suffice

I think it’s a decent idea as an feature flag,

Yeah... a JPEG XL decoder should already have everything it needs to decode baseline jpeg too.

As long as it can parse the structure of the container format

like 200-300 LoC max

In any other circumstance I wouldn't see a reason for a decoder for one format to include support for a different format, *however*, if it could market itself as a JPEG *and* JPEG XL decoder, then maybe a lot of people that want to pull in a JPEG decoder will automatically pull in JPEG XL support too :3c

JPEG XL should really be seen as JPEG 2.0 (jpeg2000 doesnt count its too different)

I recall a conversation in the opposite direction, jpegli decoding JXL files. It was shut down citing something along the lines of "If you want to decode them, or can decode them, just use JXL instead"

It's not a bad idea but if you're using the libjpeg api there's probably no way to tell if the image you're decoding is animated or not?

Maybe disable animation and use single frame

How would you even know if the image is supposed to be animated or not

I guess for applications where you have no intention to support animation anyways, it doesn't matter.

But at least with libjxl you would be able to know if an image contains an animation or not

There should be 3 programs, `cjpegli` to convert to jpeg, `cjxl` to convert to jxl, `djxl` to decompress JPEGs and JPEG XLs

Hmm... Yeah, why not? That makes sense to me. And maybe a fork of libjpeg that just has the tool code (cjpeg, djpeg, jpegtran) and header files, but the library code replaced with jpegli. That way it's easier to use jpegli as a full and complete drop-in replacement on systems that need the headers and command line utilities.

The main developer of Paint.NET [reported](<https://github.com/0xC0000054/pdn-jpegxl/issues/6>) that the Paint.NET JXL plugin produces artifacts when saving and image with an embedded ICC profile on effort 7+. This bug does not occur on effort 6 or lower, or when using the JXL 'color space' instead of an ICC profile.

I attempted to reproduce it using cjxl, but cjxl converts the ICC profile to the JXL 'color space'. Krita has the same behavior.

When using lossy, it's internally converted to XYB. Did you prevent that by enforcing RGB?

I don't think so, all my code should be doing is using an embedded ICC profile. Not sure if that counts as forcing RGB.

Artifacts can also appear due to wrong intensity target (or was it white point?) or something. Other people would know more.

Is it cjxl that converts the color space?

Would be nice if libjxl could do it

The face and hand shouldn't look like what what exactly? What should it look like? I don't see anything wrong at all

> You can use Image->Color Profile and either Assign or Convert to Display P3. Should see the artifacts then. Looks like the instruction is to assign wrong color profile to image with another color profile. Why would you do that? And why would you expect image to look fine after this?

Rick was referring to the read/blue blocking artifacts around the nose and bottom of the glasses.

That instruction was only to force the plugin to set `uses_original_profile` to `true` for a lossy encoding. The original image is sRGB, and for lossy encoding `uses_original_profile` would be `false` in that case.

I treat sRGB as a special case and use the JXL color profile instead of embedding an ICC profile.

I'm looking at it on my phone... I think I notice some blocks around her hairline that are larger than the pixel size, but it's hard to tell on the phone

That's pretty weird

on my end they are very visible

Yeah, it's because I can't tell where the pixel grid is when viewing it on my phone, so I wasn't sure if it was blocky because that was the pixel grid

How big are those blocks in pixel terms

2x2?

4x4?

8x8

AFAIK, `uses_original_profile = true` forces RGB. It should be `false` in all cases when using lossy.

I'm sadly am not In a position to test PDN 5.1+ however if the issue is arising because of forced RGB lossy then this might just be a bug on libjxl's side since no one is really expected to use RGB lossy from what I understand.

That was the issue, thanks. I think the origin of the bug was my misunderstanding of how `uses_original_profile` interacts with ICC profiles, I had thought that `uses_original_profile` was required for embedding ICC profiles.

libjxl always uses color profiles. There's no such thing as "no color profile mode".