JPEG XL

it only makes sense to set `N >= 2` for this

Together with Junfeng He, I made a model to calculate good starting point for center first tiling and some scripts to use it together with libjxl: https://github.com/google/attention-center Feedback welcome!

Hi all. What is the best tool right now to convert pictures with the latest JXL feature on Windows ?

cjxl, the built-in tool

I've downloaded updated tools for Windows from this repository (it's linked on Wikipedia): https://artifacts.lucaversari.it/libjxl/libjxl/latest/ Is it somehow "official"? I ran to a small problem. Some of the programs, namely jxlinfo and jxl_ng tools, require brotli dlls, but those are not included. I located some brotli dlls in the Gimp installation, so I borrowed them from there and they seem to work. At least the programs don't complain.

... I wonder who linked that from wikipedia xD

they're just the github artefacts

Yup, that's me. I'm pretty sure the link is useful for people who want to try JXL after reading about it on Wikipedia. Or…? 🙂

It might be, although I make no promises on uptime or the like :P

Veluca, cool encoders!

Superfast lossless coders

BTW, we never talked about it much, but some of us use a special tool to check out video quality utilizing butteraugli-jxl/ssimulacra: https://github.com/shssoichiro/butter-video It may be a bit slow, but it does work quite well.

was that a sentence

Apparently, no.

I somehow posted a garbled mess of words and did not notice.

huh, noice

~~--tune butteraugli in x264 when~~

That would actually be a good, but very heavy compute replacement for the hand made psy metric used lmao.

right, butteraugli is slow

so it would make more sense to use XYB-MSSIM or something

Yes. It would be better to use SSIMULACRA2.

In fact, it would be great if butteraugli_jxl and ssimulacra1/2 became available in ffmpeg 😳

like, as a video filter that took two inputs and outputted frame metadata?

I'm not entirely sure how useful that would be, to be honest

ideally XYB would be added as a pixel format first

(that way, the JXL decoder that lynne is writing will just output XYB data, with a cms filter to turn it into sRGB or whatever)

Yeah, like libvmaf. You add it as a video filter that takes a reference input, and then a distorted input and outputted average scores and per frame data. It'd be very useful to get the metrics to be much more widely used.

Is there any overview of tweaks for the best possible lossless compression? -e 9 really doesn't do the best compression. There are so many options and it's all trial and error. It would be nice to have an overview of known good combinations somewhere everyone can find it easily.

I have a particular picture where jxl is struggling to compete with webp. Lossless jxl produces a bigger file than lossless webp no matter I try.

-e 9 -E 3 -I 1

15MP image took me about 40 minutes

I will try that, now I'm trying different group sizes if it has any effect. In recent cjxl versions, the range of -I is 0...100, according to the help. Shouldn't that be 100 then?

i dunno, i think last i heard of it, it was something like only 1 was implemented

What's interesting that lossless webp did very good job in pretty short time. Lossless AVIF on the other hand completely failed, the result was almost two times the size of the PNG.

makes sense since I think lossless avif is the same as lossy avif

"-I 1" makes the compression actually much worse, "-I 100" improved the compression a little, another slight improvement was achieved by adding "-g 0", so the best result was made using "-d 0 -e 9 -E 3 -I 100 -g 0", but it's still far behind WebP. I also tried turn on pacthes with no effect, is there anything else I can try?

Could be that -I went from float 0..1 to int 0..100 when they switched to _ng

You can try turning off patches, and -g 3 can sometimes be better

Also -X 0 and/or -Y 0 can sometimes help

We should add a more exhaustive -e 10, I guess

But mostly we need to make -e 4 to -e 7 have better performance without losing too much compression, imo.

Currently only fjxl and cjxl -e 2,3 have good speed/density trade-offs

Trying all possible combinations of settings, the resulting jxl file is still about 25% bigger than webp with default settings. The image is 10000x10000 pixel art. If anybody is interested, search for "Lenser Pixel ART"

Also cjxl says WARNING: CPU supports 1800 but software requires 2000000000000000 What does it mean?

https://github.com/google/highway/issues/882 seems that it can be safely ignored

I found a suggestion to try -P 0 and that helped a lot. The jxl file is now smaller than the webp.

The current heuristic to decide whether to use palette or not is the same at the group level as on the image level: if less than N different colors are used, encode it with a palette. Default N is quite high (1024 iirc), which can lead to counterproductive use of palette

Tweaking the palette options -X and -Y didn't make much difference, the biggest improvement was achieved by setting the modular predictor to zero. The picture consists of large areas of solid colors so I guess the zero predictor works the best for this kind of pictures.

Ah right, -P is predictor, --palette is for palette

When there are few colors, zero predictor works well

The abbreviations can be sometimes confusing, P could stand for either palette, predictor or patches. Anyway, it seems that zero predictor is equivalent to filter none in PNG. That also works very well for pictures with solid colors.

Speaking of palette, increasing the number of colors in the palette helped too.

Is there any maximum number of colors allowed in the palette?The picture has 7286 unique colors.

No maximum

Or I guess there is some implicit maximum from the header syntax

About 70.9k is the maximum number of colors in a palette

Yeah I thought about 65536 colors could be a practical maximum.

In my experience with prior versions, `cjxl -d 0 -e 9 -E 3 -I 1 -g {2|3}` generally produced great results compared to `cwebp -z 9`. g3 tended to be favored over g2 as the number of pixels increased. The two areas where WebP was generally denser were pixel art and text. For pixel art, `cjxl -d 0 -e 9 -I 0 -P 0 -g 3 --patches 0` supplanted WebP. I never landed on a setting that generally supplanted WebP on text, WebP is just really good with highly repetitive content. (Per discussion, I1 should be I100 in latest cjxl.)

yeah can all these be put into something like cjxl -best

In this particular case, to achieve the highest compression, I ended up turning off all the fancy features and used just old plain indexed color. -d 0 -e 9 -P 0 -I 0 -g 3 --patches=0 --modular_palette_colors=8000

The -e 9 -I 0 makes it use lz77, which is indeed probably a good idea in those cases where beating webp is hard.

I've noticed that the format of JXL files transcoded from JPEG has slightly changed at some point and djxl v0.6.1 is unable to decode those newer files.

That's not good - can you open an issue about it?

Modulo bugs, djxl is supposed to decode all valid codestreams since 0.5

Yes, I can open the issue. Looking at the files in hex editor, I see the file structure has changed. Notably the jxlc box was split into two jxlp boxes and the jbrd and Exif boxes were wedged between them. Exif data is now compressed but that's not the problem because even files without Exif won't decode.

Hm, I guess maybe that's expected then

Codestream decoder was done in 0.5, but file format was still a bit in flux then

So maybe not so surprising that it couldn't handle jxlp yet or had trouble with jbrd not being in the beginning

File format handling was still quite ad hoc before djxl_ng

I've already opened the issue so let's see if anybody can tell what's going on.

I suppose we could add a compatibility mode to cjxl to only produce files that will decode on djxl 0.2

Though tbh I don't think we already have enough integrations that will not be updated quickly after the 0.7 release to make that a necessity

If it's a limitation of the old version of djxl which is hopefully going to be replaced with a new version soon, so be it. I've tried a few programs with jxl support and they load the files just fine.

The old djxl can't even decode the image to pixels.

I think the old djxl just doesn't properly implement the box format.

Adding a compatibility option would be just confusing. If it's just a problem of djxl, nobody should use old version of djxl anyway.

I think the problem will be resolvad when v0.6.1 won't be the "latest release"

I have many JPG images from mobile phone. They have various orientation. I tried newest cjxl from git to covert them to JXL. When I decode them via API, orientation is wrong (images are not rotated).

Please open an issue. Possibly the new cjxl doesn't inspect the exif to set orientation correctly, that needs to be fixed then

I've noticed that different versions of JXL decoder have slightly different output when decoding lossily compressed images. There's nothing wrong about that but I've also noticed that IrfanView has exactly the same output as djxl 0.6.1 so I assume Irfanview uses libjxl 0.6.1. As Irfanview can decode newer jxl files just fine, I believe we don't need to worry about djxl being unable to decode them. The library is apparently working OK.

I did some testing about this issue https://github.com/libjxl/libjxl/issues/1657

If the distance is not specified, cjxl is actually trying to compress images using VarDCT at the distance close to zero. It does so for both GIF and JPEG with -j 0.

It actually adds DCT artifacts in my GIF image.

Thanks for opening the two issues about the GIF and the exif orientation!

Would it be possible to create uncompressed metadata boxes with the cjxl? Compressed metadata are small but existing support in other project is so far limited mostly to uncompressed metadata.

Adding an option is not a bad idea but Exiftool needs to be updated anyway.

Hi, is there a way to convert .psd to .jxl and back?

Is there a way to make multilayered .jxl out of separate images then?

atm you'll have to write your own encoder to do that

I have a psd recompression tool that mostly works but I made it on company time and it hasn't been cleared for open sourcing yet

(it uses libjxl)

<@794205442175402004> So, when SSIMU2 gets merged into libjxl, do you think there could be a possibility of it getting a separate repository on Github or Gitlab?

That would probably be useful, it's just a bit annoying to extract it since it uses quite a bit of stuff from the libjxl repo: input file loading, color management, XYB conversion, highway implementations of image operations, etc

Yeah, it would be very nice, since some other projects would prefer not having to pull in the full suite of libjxl 😄

<@&803357352664891472> Do we have an easy way to get (the libjxl version of) butteraugli, ssimulacra, ssimulacra2 without fetching all of the libjxl repo? I don't think we currently package those or produce compiled versions of them, do we? So the only way atm is to build them from source, for which you need to pull in the whole libjxl repo....

Extracting them to a minimal separate repo is quite cumbersome since they depend on quite a few different things: image.h, image_ops.h and all that, highway, color management (lcms2 or skcms), the decoders for png/jpg/etc, and so on. You'd end up having to copy quite a lot of stuff...

could we add a debian package `jxl-metrics` or something? and also include these in the build artifacts?

Alternatively, I suppose we could make some kind of mini 'image library' that defines an api for basic image loading/saving in various codecs, color management (including XYB), and some image operations like convolutions. Then we could let all the tools depend on that, which would make cjxl, djxl, benchmark_xl, butteraugli, and ssimulacra(2) have very small binary sizes.

I think butteraugli and ssimulacra2 use a different xyb

butteraugli uses the original version with log, tuned to my eyes %-), and everything else a simplified version with cube root tuned to the butteraugli's xyb

for releases id suggest inlining submodules, and deleting `.git` dirs of these

so that one could fully compile the library just from a single tarball which wouldn't be too large

https://github.com/cloudinary/ssimulacra2

not particularly elegant but I just trimmed the libjxl code to remove stuff that is not needed (like encoding and decoding jxl :))

Nice nice, very nice 😄

Does benchmark_xl work on windows?

yes, but the `custom` codec does not

Thanks! I have been trying to run it without success, I get "Illegal instruction" error message despite using sample command from the documentation. Am i missing something?

in our codebase, “illegal instruction” often means a failed assertion; maybe rebuilding with `-DJXL_DEBUG_ON_ERROR=1` added to `CXXFLAGS` (or even `JXL_DEBUG_ON_ALL_ERROR`) would shed some light on what is going on

or with debug symbols and then running through gdb

Thank you very much! will try so shortly

https://github.com/libjxl/libjxl/pull/1727 that should be fun for applications that ignore icc profiles

So, Does it decode and convert to standard sRGB and send it to image viewing apps?

No, it saves png and jpg in XYB (using an icc profile that describes XYB, so viewers should display the image correctly IF they actually do color management)

E.g. discord is stupid when creating preview images, so that should be fun

<@987371399867945100> could you share an example png/jpg image here?

What's the purpose of that and is it optional?

It is entirely optional, you have to pass the --color_space XYB_Per magic flag to trigger it.

Oops, it seems that discord is indeed ignoring ICC profile (just like Imagemagic display)

pretty amazing that 😄

So you will get nonsense if displayed RAW.

Yes, if you display it by ignoring the embedded profile, you get this greenish version.

Firefox displays nonsense as well.

now *that* is bad

Images like that are a good stick to hit lazy devs who think color management is optional and just assuming everything is sRGB is "good enough"

If you open the original? The discord preview is nonsense but that's purely discord's fault

Yes I've downloaded the file. It looks OK in Chromium.

But not in firefox? That is weird, I thought firefox handled ICC profiles fine, just handles untagged images incorrectly by default iirc.

In Firefox, it looks wrong.

Perhaps FF only supports RGB profiles? Just guessing.

it might not support LUT based profiles

or some such -- that XYB profile does some fairly uncommon things

my firefox (on MacOS) displays it correctly

I tried it on an older tablet, and it is looks wrong there too, even in the Google Photos app

Windows Photos app displays OK.

Gnome Image viewer looks OK too

But Firefox on Debian is wrong.

the problem with how icc profiles have been used so far (mostly only for describing sRGB, Adobe98, and DisplayP3) is that most of the profiles used in practice are not sufficiently different to make people complain when their viewer ignores them — instead they'll think it's just their display being a bit off, or the image being a bit dull or oversaturated

which is annoying because it causes bugs to not get fixed

HDR says hi 🤣

yeah HDR will make things noticeable, that's for sure

it reminds me a bit of the days before sRGB became the norm, when Apple was doing gamma 1.8 and the rest of the world was doing gamma 2.2

that was also pretty noticeable

That reminds me that there seem to exist two variants of PFM format. If I try to encode this PFM image using cjxl, the resulting image is very dark. http://www.pauldebevec.com/Research/HDR/PFM/

The original PFM looks OK in Gimp, though.

And any JXL image decoded to PFM using djxl looks too bright in Gimp.

PFM has no colorspace info, so cjxl assumes it is in linear sRGB

Presumably Gimp makes a different assumption, possibly that it's nonlinear sRGB

you can tell cjxl that it needs to interpret the PFM differently

OK, so that's good. I juts need to know what the values are supposed to mean.

JXL uses 32 bit float internally, right? So it won't do 32 int, I suppose.

The Discord app (Android) is even weirder: The embedded preview is incorrect, but the full preview is correct.

same thing happens on desktop

it's because the embed is a lower quality image generated by discord while the full preview is the actual original image

I find it interesting that Eye of GNOME generates a correct image, while the preview you get by pressing space (GNOME Sushi IIRC) is incorrect. They both use gdk-pixbuf.

Some viewers will give a Flash Of Non-colormanaged Image, that's also nice

I think it's the v4 setting, iirc it's only enabled by default in dev builds and on macOS

gthumb and vivaldi works fine.

yes. v4 setting fixes it.

hmm, chrome color management no longer works at all on d3d9, it used to be that d3d9 - images working and video working, also opengl - images working, video working d3d11 - images working, video not working and chrome is still slightly wrong

and chrome still does not support cLUT properly, but interesting to see that it is saved in jxl

Is this image licensed? This image caught a bug in `vipsthumbnail`'s ICC profile handling, and I would like to make a regression test for it.

IIRC it was publicly available somewhere at some point, but I could not find the license now, maybe <@532010383041363969> who took the image can help with that. But now that the PR that generated this image is merged, you can create such jpegs from any image you like, by first compressing it with (lossy) cjxl and then decompressing it to jpg with the --color_space XYB_Per flag. (The ICC profiles that libjxl attaches have "CC-BY-SA 3.0 Unported" licenses themselves.)

I live in this village, just behind all the nice terrace houses 🙂

I have taken this photo and I have licensed it for CC0: https://drive.google.com/drive/folders/0B0w_eoSgaBLXY1JlYUVOMzM5VFk?resourcekey=0-NN9Ocbh5zx9bPxhGf5CDkw&usp=sharing LICENSE.txt: """ I, Jyrki Alakuijala, have taken and processed the photos in this directory and license them under CC0 1.0 Universal. https://creativecommons.org/publicdomain/zero/1.0/legalcode """

I'll be very happy if you use my photo 🙂

What's the best tool out there to render JXL HDR images? Chrome seems to be having problems rendering FP images correctly when the JXL file embeds an ICC profile?

I would try Krita.

what ICC profile is that? HDR images should not have one (ICC cannot represent HDR)

For some reason, --resampling=2 doesn't seem to work in cjxl. Other values like 4 or 8 do work. Am I missing something?

`--resampling=2` should work in principle, can you give a example file where it goes wrong? Either here or open an issue on github..

Any PNG file I try with --resampling=2 will fail with message: Invalid flag value for --resampling: Valid values are {-1, 1, 2, 4, 8}.

hey everyone

just found out about jpeg xl a week ago

i want to talk about microscopy images 🙂

anyone here has tested different settings for lossless / near lossless compression with cjxl?

with microsocopy images i mean

i want to compare notes

what kind of images do you have? plain 8-bit RGB, visual? or are we talking weird microscopes?

The bug is now fixed.

Yes, I fixed it this morning and didn't remember to mention it here....

No problem. I just felt like it should be cleared out here as well.

its confocal microscopy but i am interested in anything that is relevant

so the images have something from 1 to 4 channels 16 bit linear

integer

and since its all false colour no colour profiles

then maybe just start with default lossless at various speed settings

yeah i tried -d 0.0

which is nice

but its the same compression as flif

i have a few settings i tested with lots of images

d 0.0 and d 0.001 among them

i was wondering if there is something like a middle ground between the two when it comes to 16 bit images

0.001 seems to be the lowest setting possible with near lossless

if your image is not really visual, then probably you shouldn't use the normal lossy stuff since it will convert the image to XYB and encode it perceptually

i guess that is what makes this use case tricky for jxl 😄

since all the data is outside of human perception

we don't have the option anymore in current cjxl to skip xyb but do lossy modular without assuming things about the colors

or almost all of it

wht is lossy modular?

sry i dont know much about the codec yet

cjxl -m 1 -q 95 would do a lossy encode without using dct

but it will still convert to xyb to do it in that space instead of rgb/ycocg

i'm assuming you want to be able to view the image with various false colors later, so compress with similar loss in the whole range of sample values, without making assumptions about transfer curves and all that, right?

`cjxl -m -c 1 -C 0 -q 95` would do that in the old cjxl as it was in 0.6.1, but we didn't bother to add that `-c` option in the current cjxl since it's a bit niche

so would it make sense for me to build a separate tool for this specific type of image file?

cjxl seems to be very centered around human perception

and it still does an amazing job for science data

but maybe there is more to gain

yeah, that could make sense

vardct mode in libjxl is pretty much designed to work in XYB and to be perceptual — in principle you could also make a vardct encoder that doesn't try to be perceptual and just aims to preserve the numbers as well as possible (minimizing MSE or something), but we don't really have that atm

modular mode was mostly made for lossless; when it does lossy it does it exactly in a "just preserve the numbers" way

could a stack of images work better?

one with a lossy image and one lossless

and the lossless only contains the photon noise features

but in current cjxl, modular will be fed with XYB data instead of the original colorspace as soon as you go non-lossless — that is a good idea when aiming for perception, but not when aiming for number preservation

even when only using one channel?

even then it will still adjust the transfer curve

ah

so if your input is linear (and marked as such), it will basically allocate way more bits to the darks than to the brights

one workaround I guess is to give the input as ppm and tell cjxl that it's in XYB space already

no idea if that will work but it should in principle

<@604964375924834314> do you have a magic command line for doing that?

(of course the image will look pretty weird then and different from how normal viewers would show the ppm, which is interpreting it as sRGB, and you would have to decode it back to an XYB ppm or else it will do the inverse XYB transform on your data)

decoding back is no problem

this would be mostly a tech demonstrator anyway since all the software we have here does not support anything besides tiff 😄

which is unfortunately still normal in the world of microscopy

I’m not completely sure – `-x color_space=XYB_Per` might do it but I haven’t tried

out of curiosity, may I ask what it is that you make confocal micrographs of?

i can give you some example images if you like

i can not tell you much about the content because its classified but its biological tissue

one sec

its hard to see stuff because its not very well exposed

and its 16bit

thanks, that’s quite interesting

tev lets me view it a bit brighter, although there seems to be a bit of banding

if you increase exposure to sensible levels there will be banding yeah

which is another reason why tiff is so silly for this

the compression is really terrible for images that only use a small dynamic range

i got 12bpp

1 channel 16 bit

and most of it is black 😢

just got sent a nice article about compressing these kinds of images: https://www.nature.com/articles/s41467-018-07390-9

seems like the jpegxl encoder doesn't like having `-` characters at the start of filenames lol

that's a common thing with unix-style options, use `--` or `.\-steven is looking good!.png` to work around that

oh yeah i could do `.\`, forgot about that

seems like with newer commits benchmark_xl.exe flat out doesn't work at all

i've been wanting to mess around with xyb jpegs but haven't been able to due to this

binaries I used are from here: https://artifacts.lucaversari.it/libjxl/libjxl/latest/

same here, doesn't seem to work for me

what's the best way to play with the encoder on Windows or WSL?

0.7 or newer, not old ancient crap I mean

also jxl-winthumb does not seem to do anything on windows 11

no thumbnails and no opening files "appears to be damaged, corrupted, or too large"

Click on the latest entry here, https://github.com/libjxl/libjxl/actions/workflows/release.yaml and then grab the "jxl-x64-windows-static" zip

That's what I thought and that's what I was playing with so far

Is there no wic codec that actually works?

jxl-winthumb is the only one I know of, I'd expect it to still work (Has it's own copy of libjxl, and WIC hasn't changed)

That being said, with https://github.com/saschanaz/jxl-winthumb/releases/tag/v0.1.19 I'm not seeing thumbnails in explorer either

I can still open JXL files in a WIC image viewer though (The old "Windows Photo Viewer")

A restart fixed it so ignore everything I said 😆

A restart hmm?

Didn't realize I need to restart...

<@794205442175402004> Suggestion for ssimulacra2 improvement: add in a low luma performance penalty. Most encoders perform fine in high brightness situations. The situation changes a lot when brightness drops.

Do you have any examples where ssimulacra2 gets it wrong?

I can basically just add more images to my tuning set

It should be able to find issues in the darks quite well, since the Y of XYB should have a transfer curve that sufficiently stretches the darks

(it might have a problem when applied to HDR, since it uses the cube from jxl's XYB and not the log from butteraugli's XYB, so it might see too much detail in the brights compared to what our eyes can see)

this sounds like an issue with transfer curve more than anything else

8-bit just doesn't have enough precision no matter what transfer curve you use, I think.

Especially when using tv range YCbCr, which effectively turns things into ~6-bit when there is a slow gradient with non-constant chroma

For an 80-nit display, 8-bit sRGB is just enough to avoid banding, but many current SDR devices do >300 nits and/or have a way darker black level than the displays from 20 years ago

So you already need dithering to avoid visible banding when using the 16m colors of 8-bit RGB. When using full range 8-bit YCbCr, you have only 4m colors, when using tv range it's only 2.7m or so.

Does avif use tv range or full range?

~~If my math is right, tv-range 10-bit YCbCr actually only represents about 22 million different colors~~ My math was wrong, this was for 9-bit

all YUV-based video codecs use TV range and AV1 is not an exception

8-bit RGB are 16.7m distinct colors. 8-bit tv-range YCbCr are 2.8m distinct colors. 10-bit RGB are 1073m distinct colors. 10-bit tv-range YCbCr are 178m distinct colors.

In video, mostly limited range. In Images, whatever the source has.

Ah cool, so avifenc will do full range when the source is a png?

Not like webp where tv range is obligatory (unless of course you use lossless)

Yes.

Not all of it. It's also a lack of deeper psy opts in many encoders at lower luma. But yes, wb makes a good point: in SDR, it should be fine.

don’t most of them support both, as long as it’s properly signalled?

``` --container=0|1 0 = Do not encode using container format (strip Exif/XMP/JPEG bitstream reconstruction data).1 = Force using container format (default: use only if needed). --jpeg_store_metadata=0|1 If --lossless_jpeg=1, store JPEG reconstruction metadata in the JPEG XL container (for lossless reconstruction of the JPEG codestream).(default: 1) ``` what's exactly the difference?

I haven’t checked the code but my interpretation of that excerpt would be that container=0 is incompatible with jpeg_store_metadata=1

and that other combinations should work

with only “both to 1” (or left to default) resulting in lossless jpeg reconstruction

`--container` determines whether to use a raw JXL codestream, or the ISOBMFF-like container-format

one thing stored in the container format is the JBRD metadata, which lets you reconstruct the original JPEG file

the container stores other metadata too like Exif, and it's required for level>5 for example

--container=1 allows you to enforce using container even it's not needed, for plain JXL image with no metadata.

However, setting --container=0 alone won't prevent cjxl to store JPEG reconstruction data, thus use the container.

I think there should be individual options for enabling/disabling exif, xmp and jbrd.

but it says in description that it'll strip. so `--container=0` should imply `--jpeg_store_metadata=0`, and `--jpeg_store_metadata=1` should imply `--container=1` incase it's jpeg being converted

just kinda unsure of practical implications, which one should i use if i just wanna convert some jpegs but don't care about reconstruction data, yet i care about how they are displayed, and have experience that some exif data can actually change how some jpegs are displayed

if i skip only reconstruction data, can these jpegs be converted to jpeg again, even if it ends up as a bit different representation?

iirc jbrd-less reconstruction was kinda discussed before but i fotgot...

i guess i'll probably avoid these flags for now until i understand implications better

does forgoing the jbrd even save that much space to begin with?

i'll try running a test on my jpegs

id expect it to save some but unsure if it'll be much

The size of jbrd may vary depending on the source file.

Yes, that's kinda confusing.

I would also expect disabling the container will disable it altogether.

not really

I'd rather figure that `--container=0` should error out unless you explicitly set `--jpeg_store_metadata=0` to prevent accidentally stripping when you didn't intend

What is the purpose of --already_downsampled flag in cjxl and how to use it? Do I understand correctly that the picture would be enlarged by the factor of --resamplig=X when decoded?

Yes

It's useful if you want to make a 2x image but you don't have a higher res source image. The jxl upsampler should be a bit nicer than most other upsamplers, and this way you don't pay for pixels you don't have anyway

Exif orientation should get copied into the jxl codestream so you don't need explicit Exif for it.

Theoretically yes, you could produce some kind of canonical jpeg bitstream if you know it's a recompressed jpeg (part of the role of the jbrd box is to signal that the data is an ex-jpeg)

I can't figure out how to make it work. My attempts are failing with error.

I used --resampling=2 --already_downsampled

it's still running >_<

I let encoding bunch of images run overnight.

Any suggestion what I'm doing wrong?

Doesn't seem to work for me either, I thought it might need a `--resampling` value supplied too, but no luck

Could be just broken in the new cjxl, maybe open an issue

I thought that might be a bug. I will open the issue.

Anyway. There are many ways to upscale an image. What algorithm is JXL using and it there a way to choose a different one?

it's using a nonseparable filter, the weights can be signalled but atm we just always use the default ones

Would it be possible to set the filter weights so it will just duplicate the pixels? In some kinds of pictures, especially pixel graphics, it's desirable the picture is displayed with doubled pixels.

Yes, that should be possible, that's just setting the weights to all zeroes except the nearest neighbor

however we haven't exposed a way yet in the encode api to set custom upsampling weights, so we'll need to do that first

>script is done >it had a bug so didn't count stuff right epic

discovered some jpegs that didn't convert right though

most of these are actually failed downloads with html inside lol

one cymk

one normal-looking jpeg though

cjxl's error reporting is pretty awful tbh

``` % cjxl -v -v Downloads/failed/v4esrgb.jpg v4esrgb.jxl JPEG XL encoder v0.7.0 f95da131 [AVX2,SSE4,SSSE3,Unknown] Read JPEG image with 27972 bytes. Encoding [Container | JPEG, lossless transcode, effort: 7 | JPEG reconstruction data], Note: Implicit-default for JPEG is lossless-transcoding. To silence this message, set --lossless_jpeg=(1|0). JxlEncoderAddJPEGFrame() failed. ```

it definitely could use some work

like an error string of "why" it failed

Part of my workflow is passing all jpegs through lossless JPEG transformations in IrfanView - autorotate and optimize. There's also an option to remove unneeded metadata. All jpegs written by IrfanView worked alright in cjxl so far.

looks kinda like a test image for something yet i can't exactly see what can be wrong with it

running thru `jpegtran -copy all` doesn't help

i'll fill a bug report

seems like could have something to do with weird profiles

Yeah, IrfanView didn't help this time either. It works if I strip metadata but then the colors are washed out.

reported <https://github.com/libjxl/libjxl/issues/1810>

Have you tried Gimp? It identifies the color profile but colors are wrong after loading the image.

it's a bit weird jpeg no doubt

https://www.color.org/version4html.xalter something something probably this

> e-sRGB is an early, primitive and basically failed attempt at a wide gamut specification. It is long obsolete and today we use AdobeRGB or ProPhoto.

harsh

apparently depends on rendering intent

The image just looks like loaded without any profile applied.

if you pick perceptual rendering intent or really anything else other than relative colorimetric, it corrects things right

this reminded me to enable gfx.color_management.enablev4 on firefox

Sigh, I know why I don't use any color profiles in my own stuff.

``` sums: * count: 9782 * srcsum: 6152075340 * jxlsum: 4987347916 * jxl2sum: 4980610212 ``` so additional savings of stripping metadata are... around 6MiB, when the general savings of compressing 5.73GiB downto 4.64GiB are 1.08GiB

it's, well, something, i guess, but yes not worth caring about

Hey, I was wondering if someone knew a CLI tool for either converting from YUV or RGB to XYB or for decoding a JXL image as raw XYB data?

Raw XYB only makes sense if you use floats, since it isn't designed to fit in uint types (X in particular is a small signed value close to 0)

But I suppose there is a djxl flag to produce a pfm in xyb? <@604964375924834314> what would be the magic colorspace string for that?

if there is such a string then that would probably be XYB_Per

Looks like that works to ppm 👍 not to pfm but hey I'll take it

to be clear I want this for development purposes mainly, I want a reference output I can test against, so this much is perfect

It seems to work for me

Interesting, I get "Encode failed" when going to pfm, but success when going to ppm

I'm using a pretty recent build from github, commit f38074f

Turns out mine actually did not work going into ppm either... it produced output but it's in an integer format. Hmm.

If I add `--bits_per_sample=32` then it looks like it tries to output float but the encode fails. Maybe I'll make sure I'm on the latest git version...

All right, yep, updating to latest git fixed it 👍

Can djxl take a JPEG as input and output a PNG while skipping the jxl conversion first?

so you can use it as jpeg decoder

and can libjxl do this?

Not currently, but it was mentioned as a feature that would be good to have: https://github.com/libjxl/libjxl/issues/455

This was recently added to benchmark_xl, long term plan is to have it in libjxl too but probably not before 1.0

See https://github.com/libjxl/libjxl/pull/1798

<@853026420792360980> So, now that RGB32A support is in ffmpeg, how long do you think it would take to get ssimulacra2 and butteraugli_jxl into ffmpeg?

probably never

Oof. How come?

Nobody really working on integration?

metrics in a color space that FFmpeg doesn't even support

Oh.

That poses a slight problem.

Does ffmpeg support linear RGB? The rest can be considered "part of the metric", no?

it does, although Lynne wants to add XYB as its own pixel format

the problem with adding metric is they don't really coincide with ffmpeg's goals tho

I can easily see the suggestion getting met by "but why? who needs this in FFmpeg" followed by "just implement the metric with a specialized tool that links to libavcodec"

Yeah that's a fair point tbh. But then again, it already does have some metrics, right?

Yeah, like through libvmaf and PSNR/SSIM.

bombzen makes a good point however: it would be better to have a libjxl-metrics package within ffmpeg instead of metrics directly integrated.

Currently, ssimulacra2 as a separate package I guess could be implemented?

yeah, it's still a bit of a WIP though, I'm still experimenting a little bit to tweak some shortcomings (in particular the conceptual SSIM bug Jyrki discovered, and doing multi-scale downscaling in linear color instead of gamma-compressed, as suggested by Kornel)

retuning takes some time so it's basically trying a slightly adjusted metric, waiting a day or two to see how it performs after tuning, trying something else, waiting a day or two, etc.

It seems some old sites are just deleting color profile on upload, without any conversion. Making it green on all browsers and devices due to missing profile

A lot of tools treat things like colour profiles and orientation as unimportant metadata so just silently strip them, completely wrong but as long as you only deal with "sRGB like" content it flies under the radar

A lot of them strip metadata as a privacy measure, to remove things like geotagging. This is where I think jxl really made the right move in ensuring everything that affects rendering is in the main codestream.

<@794205442175402004> Do you have a specific script for computing butteraugli and ssimulacra2 BD-rates in the libjxl repo? It seems like I'm blind in this regard.

I essentially want a BD-rate script because I'd like to say stuff like "Encoder is X% more efficient in SSIMU2 and butteraugli".

Uh, nothing in the repo afaik

I wrote some pyplot scripts to make various plots

They are somewhat hacky but I can share it if you want

Eh, if they work, I'm not refusing.

https://jon-cld.s3.amazonaws.com/test/plot.py-gain-avg-moz

https://jon-cld.s3.amazonaws.com/test/plot.py-gain-avg-moz-qauto

first one aggregates things per encode setting, the second one per metric result

`results2.csv` is one big csv file it takes as input that has all the metric results

``` image,encoder,effort,quality,ssimulacra1,ssimulacra2-B,bpp,MPx/s,butteraugli,psnr_y,psnr_cb,psnr_cr,psnr_hvs_y,psnr_hvs_cb,psnr_hvs_cr,psnr_hvs,float_ssim,float_ms_ssim,ciede2000,vmaf,aimos,ssimulacra2-D images/001.png,avif 444,s6,q1,0.00320952,92.73001073,5.34928268486077816706,.24933333333333333333,3-norm: 0.254147,0.00006562,53.003059,53.653564,53.950561,54.130895,51.398969,51.608721,53.462715,0.999716,0.999611,51.860649,96.258077,0.8644,98.06922025 images/001.png,avif 444,s6,q3,0.00532715,91.23095873,3.34074128711045546745,.37143835616438356164,3-norm: 0.342703,0.00012787,50.880798,52.100634,52.072439,52.418161,49.820971,49.824750,51.760323,0.999492,0.999329,49.232069,96.008621,0.8632,95.55174596 images/001.png,avif 444,s6,q5,0.00683009,89.47879958,2.50115434261478886225,.42869565217391304347,3-norm: 0.412035,0.00019964,49.441843,51.080607,50.897431,51.288430,48.778079,48.663369,50.639078,0.999236,0.999055,47.947825,95.744301,0.8613,92.32850954 images/001.png,avif 444,s6,q7,0.00802754,87.67982422,2.05590263691683569979,.51160377358490566037,3-norm: 0.485539,0.00029196,48.140296,50.362565,50.043732,50.161570,47.895052,47.647279,49.566185,0.998901,0.998721,47.049107,95.366444,0.8602,90.19840423 ... ```

so you'll have to replace that part appropriately to let it process your own data

Thank you.

I don't know if this is the right place to ask, but, why does Chrome display JXL images correctly when in an `img` element, but if I try to open the image in a new tab, it makes me download it instead of viewing it directly?

Actually, nevermind, why does it only happen on https://jpegxl.info/ ?

That will happen whenever a server is too dumb to recognize it is sending a jxl, so it doesn't send a response header with image/jxl in it but one with a generic media type

Like github, which is hosting jpegxl.info

For older image formats like jpeg and png, chrome will sniff the first few bytes and still show it as an image even if it has the wrong media type

But for jxl they didn't want that for "security reasons" that seem rather far-fetched to me.

aiui the logic is "sniffing html (with scripts) is insecure, and sniffing is a dubious idea to begin with, but we can't get rid of sniffing due to backwards compat, so we'll just disable sniffing for new formats, even if they aren't executable"

Yeah, I can see the reasoning, but it's exactly new formats where dumb hosts are most likely to get the media type wrong in their response headers. It might encourage people to rename the file to a different extension just so the dumb host will think it's a jpeg or png, send that media type in the response header, and cause the image to get displayed after all (since once it's in the image decode path, it will likely just look at the bitstream to see what decoder to dispatch).

I ran into an issue where nginx was sending woff2 fonts as application/octet-stream

I had to add an exception in my own nginx config

ah wait nvm it was wasm

er both?

```nginx location ~ ^/fonts/.*\.woff2$ { types { font/woff2 woff2; } } location ~ ^/js/.*\.(wasm|js)$ { types { application/wasm wasm; text/javascript js; } }```

this is in my config

I guess the idea is that by not making it work, it forces these "dumb" web servers to actually get fixed. It does however mean that you manually need to add it for server installations that predate the format existing.

What issue?

What is the command for benchmark_xl to decode a JPEG and save the output?

the issue was that nginx was sending woff2 fonts as application/octet-stream

I don't know that by heart, but <@987371399867945100> will know

are there tools for testing decoder output?

i.e. take the difference of two images and compare if they meet tolerance per pixel difference

etc.

https://github.com/libjxl/conformance

this requires a test.json

I'm just trying to compare output

since it's not bit-exact identical

Imagemagick can.

``` $ compare -verbose -metric mse gradient_8x8.png gradient_8x8.jpg difference.png gradient_8x8.png PNG 8x8 8x8+0+0 8-bit Gray 256c 120B 0.000u 0:00.000 gradient_8x8.jpg JPEG 8x8 8x8+0+0 8-bit Gray 256c 181B 0.000u 0:00.000 Image: gradient_8x8.png Channel distortion: MSE gray: 1.57475 (2.40292e-05) all: 1.57475 (2.40292e-05) gradient_8x8.png=>difference.png PNG 8x8 8-bit Gray 37c 484B 0.000u 0:00.004 ``` You can pick a different metric than mean squared error if you want, but it should be good enough for differences in decoder output.

in conformance we basically look at `-verbose -metric rmse` and `-verbose -metric pae`

thanks

what's considered acceptible tolerance?

for level 5 conformance the tolerances are larger than for level 10

ah I see that's in the levels annex

no that defines what are valid bitstream in the levels, the tolerances are in 18181-3

these are the typical values but the actual values are in the json and may differ per test case

that's with sample values between 0.0 and 1.0 so multiply by 255 if you're looking at 8-bit values

why is modular 16-bit not permitted in level5?

is that because you have to use 32-bit buffers?

yes

is 32-bit integer arithmetic actually that much slower than 16-bit arithmetic on modern CPUs?

I'm wondering if it's potentially worth it to duplicate code for shorts instead of int

No

faster probably

but I'm thinking I'll just stick with 32-bit integer arithmetic

modular mode has no cyclic rotations or other things that *require* 16-bit buffers, as far as I know

16 bit buffers could still be used with 32 bit math

I don't particularly care about memory usage, I care more about decode speed

and 16-bit buffers with 32-bit math just requires clamping and unclamping

16 bit means twice as much buffer in cache!

may or may not make a difference depending on access patterns

I'm targeting the JVM

so I doubt that I'm actually leveraging cpu cache

you definitely are in one way or another, the jvm is quite good at optimizing the machine code it generates.

whether java makes it easy to write cache friendly code is another question

huh, in that case, would having `short[][]` actually be faster than `int[][]`

for a typical 256x256 group

again, would depend on the access patterns. I haven't gotten to that stuff yet so I have no idea

For purely linear access, probably zero difference

Any sort of referring back to earlier stuff, yes it would make a difference. But I have no idea how big that difference would be.

I buffer with `buffer[c][y][x]` and I iterate over x on the inside

that way buffer[c][y] is a row, not a column

I could probably optimize the weighted predictor though, as I don't actually need to hang onto values way in the past

mm

not sure if that would actually save speed or just ram tho

either way beyond basic multithreading I'm not planning on digging into optimization until I finish VarDCT

you may be surprised, jxl *can* be memory bandwidth limited

the advantage of shorts is that (if you are extremely lucky) it may get SIMDfied and then be faster

hello

i would like to know how to increase the number of progressive 'steps' if such a thing is possible

e.g. consider this output truncated to 2MB

it has a very obvious border. it seems to go right from 8x resampled to 1x reampled.

it's more obvious if i more severely cut it.

```bash cjxl --group_order=1 -d 0.000001 -p copypaste1-commission-no14-1-with-signature1920x.png me1920x.jxl cp !$ !$.trunc && truncate -s 256KB !$.trunc && mv !$.trunc me1920x.trunc.jxl gimp -a !$ ```

output JPEG XL

lossless WebP if it helps. also i realize that that's a very silly value for `-d`. i was naively trying to get more progessive steps. a more sane value such as 0.5 results in a JXL of only 517KB, also attached.

Distance shouldn't matter, the number of passes is not affected by that

But not sure which progressive events are triggered by default, could be that only 1:8 and 1:1 are shown even if there are passes for 1:4 and 1:2 in the jxl

ohh really

i wrote (most of) the (current) gimp plugin <@794205442175402004> is there an api cal i'm supposed to be using

to enable all the progerssive steps that are there

i'd like to show users the best case progressive output obviously

yeah `JxlDecoderSetProgressiveDetail` i think

Yes that is it

well im gonna try setting it to `kGroups` and see what happens

wow im glad i asked about this lol

as my patch is "wrong"

currently `kGroups` is not implemented: https://github.com/libjxl/libjxl/blob/f927401bde3840802f9b93ffd36480de4e0563ad/lib/include/jxl/types.h#L156

Doesn't hurt to set it to that though, will just start to show more steps once it's implemented

doesn't seem to do anything anyway

at least for this input maybe i need to try more difficult one

and then i still don't know if the 2x / 4x are even in ther

is there a way to get cjxl to always include them?

hmm

``` box: type: "JXL " size: 12 JPEG XL file format container (ISO/IEC 18181-2) box: type: "ftyp" size: 20 box: type: "jxlp" size: 23 JPEG XL image, 1920x1080, lossy, 8-bit RGB num_color_channels: 3 num_extra_channels: 0 have_preview: 0 have_animation: 0 Intrinsic dimensions: 1920x1080 Orientation: 1 (Normal) Color space: RGB, D65, sRGB primaries, gamma(0.454550) transfer function, rendering intent: Perceptual box: type: "brob" size: 699 Brotli-compressed xml metadata: 699 compressed bytes box: type: "jxlp" size: 516802 ```

Jxlinfo will not know