JPEG XL

Thank you for the replies so far c; Okay; When I export from Krita or Gimp in lossless, would that be more safe? Or would it just be best to test each individual image? > insane in the membrane. I am insane. But besides. > If you're going for maximum compression, you might want to add --compress_boxes=1 --brotli_effort=11 to compress the metadata more. I do try to go to maximum compression for now. I do not need metadata, unless this refers to jxl needed data. ~~*currently looking in to fining info bout -E -I -g*~~ found it: `cjxl.exe -v -v -v -v --help`

Gimp and Krita both just use libjxl, so it shouldn't be any better or worse.

Testing each image is a good idea if you can script it. e.g. with ImageMagick, you can do `magick compare -metric pae original.png converted.jxl null:`, which will print `0 (0)` if all pixels are identical.

I think `-E 3 -I 100 -g 3` is typically a good combination for maximum compression at the expense of encode/decode time, but it will depend on the image.

The metadata that gets lost would be (non-Exif) comments and embedded timestamps and things. Nothing that JXL cares about.

Ahh, that took me longer than expected; I am in due need for coffee now. (They started at webp, this was before I knew jxl)

Note that `compare` can concatenate warnings to its result, so you might not get the outcome you expect if you naively compare the string.

Was about to ask about the comparison anyway: When it fails to do lossless compression, does it than corrupt, or does it "just" change a few values hard visually to perceive? And, when I decode it back to a `.png`, would loading it with python `PIL.Image` be good enough for comparison (in-case you know by chance), since there I would know how to do that.

Well if you find a new encoder bug... it could do anything or nothing. In the past it's been anywhere between "completely fails to decode" and "decodes with a weird rectangle in the corner". FWIW I've encoded thousands of pictures with zero issues, so you'd be incredibly unlucky.

PIL should work fine for comparing the pixel values as long as it can read JXLs (or you convert them back to PNGs first).

I'd need to convert back first. -- Good to know; Those chances are fine for me. I've looked through all them using image glass right now, and visually they all loaded correctly; -- So far, thank you all c;

A PNG-to-JXL conversion will show the same image hash between both images, no need to convert the JXL back to PNG

Simply use imagemagick's `identify` to compare hashes `/usr/bin/identify -format "%m %#\n" FILES`

PIL should work as well as IM, but neither consider color profiles as far as I know. ssimulacra2 would for example if you care to catch that.

Would colour profiles not stay the same if not explicitly stripped during conversion?

Bug don't typically follow rules.

True

Krita's implementation for JXL exports is more mature, GIMP for example does not allow exporting JXL with layers

You actually don't even need to specify --help lol

Hmm, good to know. -# Wondered if PIl did or didn't but it's hard to find this info for me.. Good thing tho is, they all have been only srgb / D65 grey. They are scans that I work over anyway, so I do not need the profile to be 100% correct, but I do not want to throw value information out due to "accidental lossyness" >> Okay did do the conversion thing, and checked, they converted back to the original png information. << Thank you guys again for the help 🦦 💖

I'm looking closer at the jpegli source and I'm even more confused why it was put in a separate repo. It depends on a lot of shared code from libjxl and it's properly a part of the same library as libjxl. Also the cjpegli/djpegli tools share a lot of code with cjxl/djxl. Isn't it a burden to have two separate, duplicate branches of the same library code and tool code? Since they share a lot of duplicate code, when fixes and improvements are made to one, they don't automatically apply to both anymore like they used to since they are separated now. Wouldn't it make way more sense to merge them back together again, and instead put the cjxl/jpegli/djxl/djpegli code all together in a separate repo, so they can all benefit from the shared code, while at the same time making the library-only build much lighter?

Honestly this seems like a serious issue.

Having them separate I mean, with two branches of the same duplicated code in two separate repositories. That's really bad.

jpegli shares a VERY substantial amount of code from libjxl that's redundantly copied over and having two separate branches of the same code maintained separately seems like a massive error needlessly increasing maintenance burden.

Would it be better if I just opened an issue on the github bug tracker or something instead of lurking on discord?

It was actually implemented a while ago https://github.com/libjxl/libjxl/pull/4062

The header info is essentially non-recoverable, but it will skip any corrupted (HF/LF) groups

1. Lossless encoding for the most part is pretty mature. You can always decode back with the software and compare if you wish, just in case. If the software decodes it to the original now, it'll always be recoverable. 2. Not at all error-resilient, like most things. You'll want to back the file up, or use some sort of physical redundancy (e.g. RAID) to protect it - those will both be far more reliable than anything in the format. 3. Except for the `-e 10` part, yes. e10 is unnecessarily slow, you're looking at a massive massive waste of cpu cycles for fractions of a percent of bpp saved. Not worth it.

I *always* verify when lossless encoding with a separate tool, it's cheap to do so there is no real reason not to.

I wrote an image-checksum feature which dumps both images to `RGBA:-` with imagemagick and then feeds it into a hasher

I use sha3-384-base64 as the checksum

but there's probably something more useful as it's noncryptograhic

I just use `magick identify -format "%# "` and compare the outputs in bash lol

what does `"%# "` do?

I would assume it prints a hash

based on context yea but I was looking for more specifics

print's magick's signature hash

It prints the image hash, ignoring metadata etc.

https://web.mit.edu/GRAPHICs/src/ImageMagick-6.0.6/www/api/magick_wand.html#magickgetimagesignature

``` MagickGetImageSignature MagickGetImageSignature() generates an SHA-256 message digest for the image pixel stream. The format of the MagickGetImageSignature method is: const char MagickGetImageSignature ( MagickWand *wand ); A description of each parameter follows: ```

it's not the fastest thing in the world, but it does the job

I do something very similar

if I need faster I will setup a decoder and pipe to xxhash now or b3sum depending on system

I guess I could just make a simple hash tool using image-rs now that I think about it if I need something faster

I feel that decoding instead of just calculating the hash will probably not be faster, I may be wrong though

you need to decode to generate the hash

if you don't it's not meaningful

Yes, but it decodes "raw", if you know what I mean

we're comparing pixel data so you have to decode to pixels first

`magick convert input.png 'RGBA:-' | sha384-base64` is what I use

except if the decode were to bmp or something like that, which should be pretty instantaneous

sha384-base64 runs sha384sum (or equivalent), encodes the hexdump to binary then decodes it to base64

just to make the representation a little more compact

it doesn't really matter, pipes are uber fast

true

In general it's a quite tricky thing to even define what real lossless means. Same pixel data sure, though maybe in some cases it is fine to convert RGBA to RGB or RGB to Gray if the data allows it. But also colorspace info should be kept (though does it need to be the exact ICC profile or is an equivalent one also ok?). Then there is Exif and XMP, which I guess should just be kept as is. What about other kinds of metadata? And where exactly is the boundary between image data, metadata and format-specific stuff? E.g. is the palette of a PNG part of the data that has to be preserved?

~~unless powershell on windows~~

in this case it only compares pixel data and not metadata associated with it

you can define lossless if you're talking about a rectangle of integers

personally, I am fine as long as the pixel data matches, this is the only thing I *really* care about. Yeah keeping the metadata is nice, but for me, as long as the picture renders accurately, I can mess with metadata if needed

which is I believe how most people intend it to mean when they say lossless

the same rectangle of integers, if mistagged, is the same pixel data but a different image

If I give you a Rec2100PQ image and you store the data exactly but tag it as sRGB, I would say what you did is not lossless since it would ruin my image.

true, but I can fix that myself so IMO it's not really a major issue, ofc that is unless you are using some really wacky gamut/transfer

I guess you could do a best effort render to sRGB for testing

yea, that would be a bug in the encoder

but yea, but if you're trying to figure out if, say, JXL mangled your image, for the purpose of archival, if you can recreate the rectangle of integers bit-exactly then that's usually good enough for most people since the metadata tags can be fixed

You can fix it but if it's a subtle difference in colorspace you might not even know that the image was supposed to look different

would be hard to validate for higher bitdepth images

well, unless you handle all the transform stuff

By that logic, XYB JPEGs are lossless even if color management is disabled

most people when they say "lossless" refer to the preservation of the rectangle of pixels. ideally teh preservation of metadata happens as well

but it's generally possible to recover that if that is destroyed

unlike the pixel rectangle

I wonder if there is a good way to validate "crucial" metadata. I guess you would have to use some kind of framework that has a "decode to srgb" or "decode to linear" or whatever

I mean, I wouldn't call cjxl 'lossless' myself because it discards PNG text chunks unless explicitly XMP or EXIF, so I'd loose all my screenshot metadata from my 5K VRChat photos over the past few years. I asked the relevant people about using XMP/EXIF instead, but they cited Discord stripping them as the cause not to

does jxl have a sort of "generic" data payload thing that can be punted into?

An old idea was just storing it *as* an XMP tag, which djxl could re-insert into decoded PNGs

The three standardized metadata boxes in jxl are Exif, XMP, and JUMBF. But of course you could add your own boxes if you want, spec says unknown boxes should just be ignored by a decoder.

There should be an option for simplifying/converting ICC data to a more compact lossy representation

Since a exact copy of icc data is usually not necessary at all

Or maybe it should be an option to preserve the exact icc profile and simplifying it should be the default

perhaps a reccomendation could be made on how to handle metadata that doesn't map well, by doing it in a somewhat generic way?

Well obviously cjxl and other conversion tools should just convert tEXT to XMP

Currently it does simplify by default when doing lossy and it preserves when doing lossless.

Yes, I know. There should be an option to opt into simplification during lossless. Or maybe it should just be the default with an option NOT to simplify, since lossless already discards some metadata during conversion

Is there any theoretical advantage to preserving the exact icc profile instead of replacing it with an equivalent?

Aside from possible bugs where it fails to recognize a profile is not equivalent

Speaking of bugs in libjxl color, I wonder if it still has that horrible bug where it decodes images to 8 bit int linear by default...

I think it does

It looks like it would be simple to solve by simplifying the logic in that file that decides on the output format. So it's more...logical.

The way it's written, it's difficult to figure out what it actually does and how it actually makes the final decision, because there are several different places that can affect it

That style of spaghetti code is kinda the norm throughout libjxl unfortunately

Ar least it's all in one file though. I think.

So it shouldn't be that difficult to change and make it simpler.

I think it would be helpful for there to be a standard “unknown metadata” box like “mbox” or something

I think there should be an option to copy any metadata regardless of type. Quite important for archival

Also an option to copy the timestamps of the source file would be nice

Bit-exact PNG transcoding would be nice but probably more difficult. What could probably be done is bit-exact png header reconstruction (the IDAT chunks will be different but all others are preserved)

Is there an even more verbose build of jxlinfo ? Dealing with an image extracted from a game and getting `Decoder Error` and would like to see which part is returning `JXL_DEC_ERROR` but I guess that will require rebuilding the code (can do but don't have VS installed rn) ?

If it's not against the rules I can upload it

it is okay in general

Seems like an issue with the extra channel in the header, trying to figure it out (i used wsl instead of vs)

but i think there are some other issues too

```JXL_QUIET_RETURN_IF_ERROR(visitor->Enum(ExtraChannel::kAlpha, &type));``` this line in image_metadata.cc is problematic. Seems like they might be using extra channel for something that's not alpha ?

thought i could simply skip over it, but no i have to figure out how to parse it because skipping over it causes it to read the frame header at wrong place

Try using jxl-oxide with `-I --show-offsets --show-all`

`jxl-oxide -Iv --all-frames image.jxl`

``` ←[2m2025-02-02T12:56:54.581731Z←[0m ←[34mDEBUG←[0m ←[2mjxl_threadpool←[0m←[2m:←[0m Initialized Rayon thread pool ←[3mnum_threads←[0m←[2m=←[0m12 ←[2m2025-02-02T12:56:54.581929Z←[0m ←[33m WARN←[0m ←[2mjxl_image←[0m←[2m:←[0m Unknown extension ←[3mextension_idx←[0m←[2m=←[0m0 ←[2m2025-02-02T12:56:54.582344Z←[0m ←[33m WARN←[0m ←[2mjxl_image←[0m←[2m:←[0m Unknown extension ←[3mextension_idx←[0m←[2m=←[0m1 ←[2m2025-02-02T12:56:54.582686Z←[0m ←[33m WARN←[0m ←[2mjxl_image←[0m←[2m:←[0m Unknown extension ←[3mextension_idx←[0m←[2m=←[0m2 ←[2m2025-02-02T12:56:54.583066Z←[0m ←[33m WARN←[0m ←[2mjxl_image←[0m←[2m:←[0m Unknown extension ←[3mextension_idx←[0m←[2m=←[0m4 ←[2m2025-02-02T12:56:54.583529Z←[0m ←[31mERROR←[0m ←[2mjxl_oxide←[0m←[2m:←[0m failed reading JPEG XL image: bitstream error: Enum(BlendMode) read invalid enum value of 5 ``` second image I have ``` ←[2m2025-02-02T12:55:28.160078Z←[0m ←[34mDEBUG←[0m ←[2mjxl_threadpool←[0m←[2m:←[0m Initialized Rayon thread pool ←[3mnum_threads←[0m←[2m=←[0m12 ←[2m2025-02-02T12:55:28.160287Z←[0m ←[33m WARN←[0m ←[2mjxl_image←[0m←[2m:←[0m Unknown extension ←[3mextension_idx←[0m←[2m=←[0m0 ←[2m2025-02-02T12:55:28.161242Z←[0m ←[33m WARN←[0m ←[2mjxl_image←[0m←[2m:←[0m Unknown extension ←[3mextension_idx←[0m←[2m=←[0m1 ←[2m2025-02-02T12:55:28.161616Z←[0m ←[33m WARN←[0m ←[2mjxl_image←[0m←[2m:←[0m Unknown extension ←[3mextension_idx←[0m←[2m=←[0m2 ←[2m2025-02-02T12:55:28.161981Z←[0m ←[33m WARN←[0m ←[2mjxl_image←[0m←[2m:←[0m Unknown extension ←[3mextension_idx←[0m←[2m=←[0m4 ←[2m2025-02-02T12:55:28.162442Z←[0m ←[31mERROR←[0m ←[2mjxl_oxide←[0m←[2m:←[0m failed reading JPEG XL image: F16() read NaN or Infinity ```

jxlinfo says these are the unknown extensions if that matters ``` unknown box: type: "exif" size: 64 box: type: "pdfl" size: 24, contents size: 16 unknown box: type: "pdfl" size: 24 ```

Which encoder produced that jxl?

no idea it's ripped from a game. it's not truncated because the length matches that in the header correctly and the next byte after that is the start of the next filename in the capsule (or whatever it's called) anyways. i was able to extract working JXR files from the same capsule using the same method (checking for headers of JXR/JXL and extracting the bytes). it's just these JXL files that they have encoded weirdly

Can you upload the original file the JXL was derived from?

Is this really an image?

Final Fantasy?

Gran Turismo

yes, I have working JXRs extracted from it

they add up to 2048x1024 when combined together, just in chunks for some reason

How do you know it's a JXL and not just random bytes?

it does look like the thumbnail preview (the JXR).

the JXL has a half valid header

it shows the resolution, bit-depth and stuff like that with correct looking values

How did you extract the JXRs?

it has somewhat valid jxl container format (except having `exif` and `pdfl` box which is undefined), and `jxlc` box starts with `ff 0a`

ah

i do need to create a proper extraction script which preserves the filenames inside it too

this file has some repetitive patterns which doesn't look very jxl...

```box: type: "JXL " size: 12, contents size: 4 JPEG XL file format container (ISO/IEC 18181-2) box: type: "ftyp" size: 20, contents size: 12 box: type: "exif" size: 64, contents size: 56 unknown box: type: "exif" size: 64 box: type: "pdfl" size: 24, contents size: 16 unknown box: type: "pdfl" size: 24 box: type: "jxlc" size: 608300, contents size: 608292 Decoder error Animation length: 0.000 seconds (looping) Error reading file: JXL1.jxl```

Definitely *funky*

ExifTool says it's `4096x2048`

i got jxlinfo to say that and alot of other info like bit depth by forcing the extra channels count to be 0

got invalid frame header or some error after that tho, but I thought it's because it would be skipping over the extra channels and reading at the wrong place ?

``` box: type: "JXL " size: 12, contents size: 4 JPEG XL file format container (ISO/IEC 18181-2) box: type: "ftyp" size: 20, contents size: 12 box: type: "exif" size: 64, contents size: 56 unknown box: type: "exif" size: 64 box: type: "pdfl" size: 24, contents size: 16 unknown box: type: "pdfl" size: 24 box: type: "jxlc" size: 499275, contents size: 499267 JPEG XL image, 4096x2048, (possibly) lossless, 10-bit RGB num_color_channels: 3 num_extra_channels: 0 have_preview: 1 Preview image: 68x51 have_animation: 0 Intrinsic dimensions: 4096x2048 Orientation: 2 (Flipped horizontally) Color space: RGB, D65, sRGB primaries, sRGB transfer function, rendering intent: Relative Decoder error ```

so my guess is that I have to make a new parser for the extra channel info so it reads starting from the correct place

Is there a PDF or something documenting the file structure ? Can't seem to find anything

The header syntax of jxl is quite compact and avoids redundancy so any random sequence of bits has a chance of corresponding to something that looks like the beginning of a header

It has a 68x51 preview frame and an unusual orientation — I would guess that it does not actually contain a jxl codestream but this is just some arbitrary bytes interpreted as jxl by making it start with 0xff0a

Very strange though

It does seem oddly specific with the correct `JXL` and `ftyp` sizes, with common power of 2 dimensions. I'd be more impressed if they actually used JXL than if some random data made an almost-valid file though

I am not aware of any encoder writing `exif` boxes (the standard box name is `Exif`) and I wonder what `pdfl` could be

Could it be something that was made based on a super old version of libjxl from before the bitstream was finalized?

Very mysterious 🙂

A leaked test of JXL PDF support? xD Whatver it is, it's very strange to be in Gran Turismo

There is also a frame header with the correct dimensions (at pos 26 (dec) after removing everything before ``FF 0A`` codestream), but everything else about it seems messed up.

So its is definitely written to meant to be a JXL, as it has a fully compliant 18181-2 container (other than the misnamed `exif` box), it would be weird for it to be anything other than a JXL

used the container with their own format i guess

was hoping the issue would just be with the extra channel parsing. if it helps it's likely an HDR or high bit depth image

Maybe it’s a fork of JXL

Like removed certain things to improve decode speed

what does that file correspond to in that game?

it's a texture on a mesh used in a photo mode environment

Found that `cjxl -d 0.05` produces larger than `-d 0` and even the original PNG

`-d 0.1` could be already larger than `-d 0`

Depends on image. Adobe's lossy JXL DNGs are fairly often larger than lossless if bayer instead of linear RAW

Is that preventable?

If you lower the quality

It's because VarDCT isn't particularly efficient at storing almost-lossless images

that's why Modular mode exists

that's why lossless AVIF sucks so much

Seems libjxl v0.11 sometimes compresses worse than v0.10 and before

in lossless? yes, it is natural consequence of performance tradeoffs, bug fixing, whatever. lossy? much more challenging to measure, but similarly unsurprising. in general, the encoder improves.

Except when it doesn't

Lossless JPEG transcoding compression got worse after version 0.9.2. Version 10.0.0 gives worse results than 0.9.2 and it's that way in the current builds as well. Lossless JPEG transcoding seems to be slightly broken in the current version, -e - 9 gives better results than -e 10. Version 0.9.2 still does better lossless JPEG transcoding compression than current builds.

I think we got it the first time, but makes sense. Effort 10 didn't exist, so I'm surprised it does anything different to effort 9

Inflation of compression?

For lossless jpeg transcoding, 0.9.2 -e 9 produces smaller files than either-e 9 and -e 10 in the current version.

Pure `-e 10` or the so-called incantation `-e 10 -E 4 -I 100 -g 3`?

I was trying only efrort options alone.

I will give it a try.

The additional options are definitely helping, but they're helping to 0.9.2 too.

And yes, all these jxl files do decode to the same pixels.

have any benchmarks been done on a size optimized libjxl? > Ren'Py now has decent support for C++. > > Right now, my main issue is adding 4mb per platform. Can someone get the size of a compiled libjxl down significantly?

if I change `CMAKE_BUILD_TYPE` from `Release` to `MinSizeRel`, it goes from 4.0MB (3.6MB stripped) to 2.9MB (2.4MB stripped)

(upx can then compress those 2.4MB down to slightly less than 1MB, but not sure they’d want to use upx)

(https://upx.github.io/)

is it possible to just compile decoder stuff?

ah, right, we already do that, forgot about it

libjxl_dec

Release: 1.63MB, strips to 1.42MB (upxes to 570kB) MinSizeRel: 1.27MB, strips to 1.01MB (upxes to 412kB)

interesting, I forgot libjxl_dec exists since arch doesn't package it. I wonder how hard it will be to get renpy's build system working on my PC then

even just lossless recompression of JPEGs would probably more than make up for those 4MB anyway

does libjxl_dec also get made when compiling for static?

ah, right, that’s what I wanted to look at (since the size I gave were with dynamic brotli)

I have a feeling that compiling static + LTO should be small enough

Release: 2.8MB `.a` MinSizeRel: 2.3MB `.a` but it’s difficult to draw conclusions on the size difference of an executable that would link to it vs not

This never got merged either https://github.com/libjxl/libjxl/pull/2766

Oh wait, I should've scrolled down a bit more :P

There's a lot of old threads about binary size fluctuating https://github.com/libjxl/libjxl/issues/3841

Also reminded me of this https://forum.zdoom.org/viewtopic.php?style=5&p=1244398&sid=b853fcc65268fff4e7d13902db3a6451#p1244398

So, lossless jpeg transcoding in version 0.9.2 seems to be consistently better than in 0.12.0. I've tried different combinations of the options. Group size doesn't do anything. -I and -E improve compression in both 0.12.0 and 0.9.2, so 0.9.2 is still performing better.

The size also depends on the c runtime too right? Like glibc tends to bloat the size of executables.

And there's also the c++ runtime, the clang vs the gnu one

oh right, context of what I was talking about for people who don't want to try and find it https://github.com/renpy/renpy/issues/3865

basically the current blocker for renpy support seems to be size increase

I gave the three kinds of size optimization ``` * Use libjxl_dec.{a,so} instead of libjxl.{a,so} * use CMAKE_BUILD_TYPE="MinSizeRel" (this can hurt performance, but libjxl is fast enough that this is likely not an issue except for ultra low end hardware, I my N3050 laptop has no problems and neither does my LG G7 thinq) * if building static using LTO ```

if anyone else has other ideas post them there

interesting

I need to try that

That's weird. How big is the difference?

Look at the comparison. It's not a big difference but it's there. At least I would expect improvements during the development.

Brotli effort didn't make a difference but that's probably because my jpegs are bare, so jbrd box is very small.

Lossless recompression seems a lot harder to screw up. It's surprising that there would be regressions even there.

Regressions in regular lossless or lossy mode are more understandable.

Those are a lot more complex

It’s probably different optimisation in the Modular encoding

Additionally, -e 11 is equivalent to -e 10 in jpeg transcoding. And -e 10 is consistently worse than -e 9.

I was also surprised that some options that are seemingly meant for Modular do apply to jpeg transcoding too.

Modular sub-bitstream for the DC encoding

> Compressed to 3728.8 kB (6.069 bpp). > 1920 x 2560, 0.012 MP/s [0.01, 0.01], , 1 reps, 6 threads. > JPEG XL encoder v0.11.1 0.11.1 [AVX2,SSE4,SSE2] > Read 1920x2560 image, 5529683 bytes, 227.8 MP/s > Encoding [Modular, lossless, effort: 10] It says using 6 threads, but `-e 10 -E 4 -I 100 -g 3` actually uses one thread only

Yeah, that's because chunked encoding is disabled at effort 10 for Patches, ect

Thus `--num_threads=N` wouldn't work either for it, correct?

But it seems I can let multiple workflows run at the same time

Each would consume 100% of CPU, aka one thread each

Genius

Yeah, the threading *might* improve with `--patches 0 --dots 0` but I think it still does full-frame heuristics

Maybe it's not that smart— RAM becomes the new bottleneck

They're now together running much slower than my expectation as they've been consuming almost all of RAM

Oh yeah, `-g 3` hugely increases memory usage, especially with chunked encoding disabled

When I bought my current pc, I thought that ~~640KB~~ 64 GB would be enough for a long time, but then I discovered -e 10\11

we were promised 64/128GB DIMMs, but those exist only for the professional segment smh

I also have few images where `cjxl -e 11` just gave up and terminated without a word after a minute.

Same thing that blocked off JPEG XL from GZDoom.

ls *.png | parallel —bar cjxl {} {.}.jxl -d 0 -E 10 -g 3 -E 4 -I 100

Double `-E`

Also `-E 11` is max IIRC, not that even 4 should do anything since there's only 3 channels before Alpha

extra functionalty like jxl support could very well be handled as post-install downloads (required, optional or selectable during install) since theyd have their separate update pace. decoding-only should be barely over 1 megabyte for games shipping

Two `cjxl -d 0 -e 10 -E 4 -I 100 -g 3` processes have done several huge images (over 100M pixels) over night

To finish more when I'm not at home

Hmm... I wonder if in time effort-limited decoders (i mean decoders which can only decode files encoded up to certain cjxl effort) which would have smaller binary size will appear.

This repository stopped updating. https://artifacts.lucaversari.it/libjxl/libjxl/latest/

It happens from time to time

... Not the best timing, I doubt I'll be able to give it a look in the next week or two

It might be because the CI is failing though (?)

Seems to be passing from what I can see

... in which way did it stop updating? libjxl doesn't seem to have any commits after 30-01

10500 x 10500, 0.006 MP/s

e10/e11 was added as a trap to get naive people to waste tons of time and electricity saving 2 bytes on a 2,000,000 byte image

--allow-moron-settings

I've already done 16 images of 10500 x 10500 pixels

I knew it was a good idea to go to 3 decimal places

That's 6 KP/s, not that bad

That's horrible

That's like a full second to process a postage stamp

No, not even

It's even slower than that. Several times slower

That stuff really needs to be locked behind --allow-moron-options

10500 x 10500, 0.004 MP/s [0.00, 0.00]

What do these 0.00 and 0.00 mean?

I guess it's min/max throughput but truncated

It's glitchy and probably meaningless

Last time I read the source code it was pretty bad and didn't actually calculate anything

Unless they fixed it

The quality of the cjxl/djxl tools is much worse than the library code. Another reason I wish they were separate

No it's not, when used with `--num_reps x` it shows the lowest and highest MP/s within x repetitions

In terms of bugginess, benchmark_xl takes the cake, I personally consider it borderline unusable

Most functions simply don't work for me in benchmark_xl

is it even being actively maintaned?

For normal-sized images running multiple `cjxl -d 0 -e 10 -E 4 -I 100 -g 3` processes is fine

Memory usage won't skyrocket

modular outperforms VarDCT for very low distances

try `-d 0.05 -m 1`

I'll see if the dozens of my gigantic images by `cjxl -d 0 -e 10 -E 4 -I 100 -g 3` are finally done later today

The process was re-initiated about 42 hours ago

With the different approach this time, the speed is now faster than 10 KP/s

Post savings when finished

What kind of layouts do you want to see?

Just a before and after

Seems it needs one more day

These settings?

What KP/s are you getting?

It's now processing some stubborn ones and falling below 10 KP/s

Since e10+ is single threaded I could probably experiment running long cjxl sessions on my server. How much RAM does it use?

It would be nice for cjxl to output progress info for longer encodes

Like: processing group 4/160: testing MA tree 4/32

Mine has 32 GB and the memory usage is at Level 4 (highest)

I have 16 GB ram on my system, around 10 gb free.

I'm running two cjxl processes

We should all set up some distributed cjxl server.

Like you register you device and when people send in image transcode requests it would calculate approx memory usage and allocate each job to the best system for it

CPU is just slightly warmer

Having encodes run on your device earns you points and those points can then be used on “buying” encodes.

Is there a way to calculate the max bounds of cjxl memory usage given a certain parameter set an image size?

I'm not even sure about how much it really uses now as macOS enables swapping for it

Does swapping hurt performance for it too much or is it usually only reading parts of the memory at a time

Each uses over 20 GB now

The system isn't significantly slowed down however

Probably not great for your ssd though 🤷‍♂️

When I checked last month the lifespan was at 96%

Found the old 'first test' of chunked encoding that Veluca posted https://discord.com/channels/794206087879852103/804324493420920833/1204090760148942910 just for context as to what e10 is sacrificing

It *should* cause massive slowdowns, but I don't think anyone has specifically compared adding more RAM to a system. Here's a throwback to a 300GB JXL encode though :P https://discord.com/channels/794206087879852103/794206170445119489/1204734729522515999

The slowest one it recorded > `10500 x 10500, 0.002 MP/s [0.00, 0.00]`

aka 2 KP/s

The whole process finished 6 hours ago

I'll test -e 7 (default) again

I wonder what kind of impact using the fixed MA tree on higher effort levels would have

I was about to update the encoding effort docs again after finding this, but then I realised... Is that meant to be `>` instead of `>=`? <https://github.com/libjxl/libjxl/blob/f73fc6f045268e2d12c17490ac490e0721116657/lib/jxl/enc_ac_strategy.cc#L1128>

Seems it was changed back in v0.5 but the comment wasn't updated <https://github.com/libjxl/libjxl/commit/a8740af7f889292c606ba143e5996247b9f4765f#diff-4bcf87d9b41e940d20a14b016f4f8c7316cfbb9a2bf43142ebbeb0e84a1526dfL1365>

perhaps. it used to be the case that effort=4 would allow for custom varblocks

effort=4

effort=5

appears that's enabled on e=5 now

So is fjxl now simply `cjxl -e 1`? I can't find the exact answer about that

Pretty much, yeah

Do people really use -e 1?

Can be useful for large images

I found `-e 10 -E 4 -I 100 -g 3` very useful for gigantic images

Yes new idea: how fast is -e 1 for tiny images

Will lead to better compression, yes, but also to vastly higher times before an image is opened due to higher decode times

Extreme memory usage and many orders of magintude longer encode times, along with rather slow decode times usually 2x that of PNG

Exactly

e 1 uses effectively the same memory as the raw image plus a dozen MB or so and is 2x **faster** than PNG decoding

For some context, I did some very rough tests and e1 was 10% larger than max Oxipng settings and 40,000x faster at 6ms per 1080p image and 26ms for 4K

e2 has the same decode speed and slightly better size, but is 10x slower

Is that OxiPNG with Zopfli?

Actually, I don't think it was... Please hold for a 2,000,000x speed difference :P

```wintime -- oxipng -o max --fast -Z -vv Oxipng.png 2921960 bytes (20.82% smaller): Oxipng.png PeakWorkingSetSize: 121 MiB PeakPagefileUsage: 184.5 MiB Wall time: 0 days, 00:00:58.028 (58.03 seconds) User time: 0 days, 00:00:00.484 (0.48 seconds) Kernel time: 0 days, 00:01:00.437 (60.44 seconds)``` 1000 reps to warm the cache and make measuing easier ```wintime -- cjxlClang --disable_output -d 0 Oxipng.png -e 1 --num_reps 1000 JPEG XL encoder v0.12.0 [_AVX2_,SSE4,SSE2] Encoding [Modular, lossless, effort: 1] Compressed to 2826.1 kB (10.903 bpp). 1920 x 1080, median: 282.788 MP/s [118.54, 309.26] (stdev 67.773), , 1000 reps, 16 threads. PeakWorkingSetSize: 32.35 MiB PeakPagefileUsage: 30.28 MiB Wall time: 0 days, 00:00:07.899 (7.90 seconds) User time: 0 days, 00:00:01.171 (1.17 seconds) Kernel time: 0 days, 00:01:08.828 (68.83 seconds)``` 8ms for 1080p compared to 60,000 for Oxipng, over 7,000x faster and 80% less memory ``` Original: 3.51 MB (3,690,257 bytes) Oxipng Zopfli: 2.78 MB (2,921,960 bytes) Effort 1 JXL: 2.69 MB (2,826,103 bytes) ``` And in this instance, effort 1 is actually 3% smaller too

Depends on image, since apparently I *did* use Zopfli and cjxl was 60 MP/s faster than this time (ignore Brotli)

Does libjxl still offer Jpegli now?

I'm editing the libjxl part on Wikipedia

I'm pretty sure jpegli is still included with the lastest nightly builds

Are talking about jpegli being in a separate repo?

Then it should say the both

Is https://github.com/libjxl/libjxl/tree/main/tools/fast_lossless different from `fjxl`?

Maybe comparing to `oxipng -o 0` would be fairer?

xnconvert can select "effort 0" and I thought it would be something like cjxl -e 0 (?), but it's actually -e 7

Probably just means “default effort”

Good that jxl-x64-windows-static.zip allows me to use `cjpegli` on Windows successfully

Also nice to learn `wintime` on Windows

Counting width * height / pixels per second isn't a pleasant experience with libjxl

anyway `fjxl` was merged in `cjxl -e 1`

Looks good comparing `cjxl -d 0 -e 1` with `oxipng -o 0 -a` ```byte type sec 67,283,398 original PNG 57,563,195 oxipng -o 0 -a 8.433 53,017,186 cjxl -d 0 -e 1 1.799 byte type sec 44,123,818 original PNG 38,332,388 oxipng -o 0 -a 13.910 29,846,465 cjxl -d 0 -e 1 2.157```

The same image with/without the background

Using alpha optimization?

The second image has alpha

--keep_invisible 0 is the cjxl equivalent

May compress slightly better

As `oxipng -a `didn't make any different, `--keep_invisible 0` didn't either

The same sizes as well as very similar speed

Ah right

Yeah I did check ssimulacra2 after I used `oxipng -a` for my personally owned artworks

All 100

That post above is just a quick test for the minimum effort of `cjxl` and `oxipng`. Some `-e 10` spell can take almost a half day for the same two images

```-e 10 -E 4 -I 100 -g 3 29,236,724 17,997,945``` Just for the reference

nice! what aspect are you most interested in?

perhaps issues detailing everything that needs to be done still would be warranted? then one could pick an issue and express interest in working on it to not overlap with existing efforts

That was quite the speed hit https://github.com/libjxl/libjxl/pull/471

When I'm home I might do some resampling benchmarks. I think it could trigger at distance 15 instead of 20 for equal quality, but the encode speed gets hurt a lot by that

Made a fork and a start on updating the effort docs (again). This time looking at code instead of just comments, but my head hursts just from looking at this <https://github.com/search?q=repo%3Alibjxl%2Flibjxl+%22if+%28cparams.speed_tier+%22&type=code> So any help digging out the decisions would be appreciated (I messed up the first commit name too :P) <https://github.com/jonnyawsom3/enc-effort>

I'm realising effort 5 does a *lot* more than effort 4... Maybe we should spread things out more if some aren't a big speed hit

Does libjxl guarantee that the alpha channel has the same bit depth as the color channel(s)? I.e. when an alpha channel is present, `basicInfo.alpha_bits/alpha_exponent_bits` is the same as `basicInfo.bits_per_sample/exponent_bits_per_sample`.

The libjxl GIMP plugin and Krita appear to be making that assumption, along with my Paint.NET plugin. AVIF allows the color and alpha images to use different bit depths, but I was not sure if that is also true for libjxl/JPEG XL.

The bit depth can be different, but when you decode to uint8 or uint16 RGBA, it will always produce 8/16 bit buffers regardless of what the actual bit depth is

Hi, tutti! Does anybody know why `total_pixels` value is overestimated in `ModularEncode` function if its initial value is 0? I tried to figure it out, but to no avail

can you provide line numbers so I can know where to look? ty

talking about here: <https://github.com/libjxl/libjxl/pull/4135/commits/72b2299bae2f42f6191b21ea771e29db7b915e66>

i guess the claim is elsewhere it counts differently?

Yeah, exactly

The link is here, and my initial thoughts are in the PR description

at a glance it seems correct to me, because tree_samples iterates all channels

Yes, but it increases total_pixels by itself!

https://github.com/libjxl/libjxl/blob/main/lib/jxl/modular/encoding/enc_encoding.cc#L163 and so on

not sure it makes sense to call `std::max()` for this

`if (!*total_pixels) *total_pixels = 1;` or something

seems cleaner

maybe the compiler will optimize it out tho

So that is what appears finally: if initially `total_pixels = 0` then we have after the function `total_pixels = 2 * (number of pixels in the image)` increased by this part and `GatherTreeData`

In any other case we have `total_pixels += (number of pixels in the image)` increased by `GatherTreeData`

And I don't get if it is intentional or a bug 🙂

looks like that number only really matters for this: https://github.com/libjxl/libjxl/blob/main/lib/jxl/modular/encoding/enc_encoding.cc#L318 unless I missed something

Yeah, I've got to the same conclusion

it scales the threshold needed to decide whether adding a node to the tree is worth it; if fewer pixels were sampled then it more or less assumes the cost saving in the sample will be representative (but not quite)

Ah, also in the `PredefinedTree` - zero pb was fixed in https://github.com/libjxl/libjxl/pull/4134

if the total_pixels is wrong by a factor of two then that more or less boils down to `options.splitting_heuristics_node_threshold` being different

`git diff --trans`

So overestimation increases a threshold to accept a node, right?

decreases it, since the threshold is basically multiplied by nb_samples / total_pixels

the base threshold is set here: https://github.com/libjxl/libjxl/blob/main/lib/jxl/enc_modular.cc#L519

``` cparams_.options.splitting_heuristics_node_threshold = 82 + 14 * static_cast<int>(cparams_.speed_tier); ```

which means higher threshold at faster settings (lower effort)

Hmm, I think I miss something: if less pixels are sampled, then any resulting decision should be more informed - by larger threshold, not the other way

the threshold is expressed in number of bits estimated to be saved by adding the node, in the sampled data. But if the amount of sampled data is smaller, the absolute number of bits that is saved is also smaller

and yes, it should be more informed, I think that's why it's not quite just multiplied but there's this * 0.9 + 0.1 thing

obviously there is room for improvement in how these thresholds are determined

Aha, got it then

`82 + 14 * static_cast<int>(cparams_.speed_tier)` is a pretty arbitrary formula that is not really based on anything

basically it makes higher effort settings get a lower threshold so more likely to produce larger trees, but there is no fundamental reason to link that threshold to the speed setting

also there are some additional heuristics around https://github.com/libjxl/libjxl/blob/main/lib/jxl/modular/encoding/enc_ma.cc#L431 that apply some creative interpretations of the threshold

So for fast encoding `libjxl` uses effectively twice lower thresholds (as any of `stream_images_` are encoded separately)

from the compression point of view, the threshold should correspond to the signaling cost of the extra node, which is a bit hard to estimate since you don't know the histograms for the MA tree signaling yet, but probably 82 bits is a safe overestimate of that

in the bigger picture, it's also beneficial for speed to keep trees small, avoid the weighted predictor, and encourage static tree properties since they do not need to be evaluated per-pixel. So having a somewhat higher threshold helps with that

probably it would make sense to rethink that whole threshold computation since I don't think it has been touched in ages and it was just a kind of placeholder in the first place anyway

<@167023260574154752>

hah

it's not perfect (pink and white inverted) but it did make me smile a bit when I saw it

nice

There is a mess around using `responsive` parameter, what was the intention to use it? For example, it is set inside the `ModularFrameEncoder` copy, but then its generally uninitialized value of the `cparams_orig` is used further

Intention is for it to be disabled by default unless it gets enabled explicitly

I will try then to follow data flow and fix the problem

I have a few GIFs that encode properly to lossless JXL, but checksums do not match. Does anyone have an idea why that might be?

Pretty

could it have to do with alpha?

Checksums are not a reliable way to check if two images are same. Small differences in the header like tiny bit of exif metadata will change the checksum while the pixel data is identical.

Well, you could decode the gif and jxl into individual ppm images and use ssimulacra2 to compare them

or maybe there is a special image magick command that does that

presumably RaveSteel is using imagemagick, which presents this issue

`magick identify -format '%#\n'` will give you a hash for the pixel values of each frame.

Also I brute forced it and decoded every frame and stitched it back together in a gif and used `gifdiff.exe` to compare the pixel values. They are 100% identical.

I am, yes

magick does give different results, but yeah, it could be related to alpha.

ImageMagick normally outputs matching image hashes

For GIF as well, I have encoded hundreds of GIFs in a dataset and it always matched, of course only if nothing went wrong during the encode

But yes, I assume it has something do with alpha

Decoding the GIF and converted JXL to their frames indeed shows same hashes for all of the frames, but it is still weird, or rather, unexpected, that the hashes would differ. Not just using Imagemagick but ffmpeg's framemd5 as well

ooh, ssimulacra2 accepts .gif input `ssimulacra2.exe original.gif djxl.gif` = 100

Does it actually decode the entire GIF, or does it just diff the first frame?

Testing rn

only first frame 🥲

darn

I feel like it wouldn't be hard to implement tbh

Oh cool, I didn't know that djxl decodes animated JXL to APNG

I guess my main gripe is that djxl does not output natively to .gif. I had to output as apng then reconvert to gif carefully without ruining the per-frame palette the original gif had

I just extracted the frames to PNG using ffmpeg

Works perfectly fine

except you get many more frames for the JXL, but deduplicate those and you're golden lol

I just use `apngdis.exe` to split it into frames

I skipped decoding via djxl entirely because ffmpeg can handle it just fine

makes sense, idk what setting to pass to ffmpeg for deduplication tho

convert can also give you the frames ...

There are params for that I believe but I just used `rclone dedupe --dedupe-mode newest --by-hash .` lmao

A very brute force approach I must admit, but it works

Looking at ImageMagick's identify with -verbose for both files, the GIF does not have an alpha layer but some of the colours in the ColourMap are "srgba". I assume this could be the reason why the JXL gains an alpha channel during conversion?

I'll test some more

how so? the JXL animation has 12 frames and ffmpeg outputs 12 frames

Right, but ffmpeg outputs over 100 frames, with all except the real 12 frames being duplicates

Don't ask me why

what version are you using?

n7.1

interesting. I just tested it on the JXL you uploaded and it outputs 12 frames

``` ffmpeg -i 61472748_ugoira1920x1080\ -\ 神社と星.jxl -c rawvideo -f framemd5 - ```

you're not doing something like setting `-r` are you?

I tested it with ffmpeg 7.1 and got a similar result to git master

That's the interesting part, ffmpeg detects the JXL as having 12 frames, as is correct, but outputting to png via `ffmpeg -i JXL img%04d.png` yields the many frames

oh, that's the image2 muxer

It's not JXL specific, I have seen this behaviour with other animated files as well

problem in this case is the image2 muxer is setting the framerate to 100 based on the timebase, and then just duplicating frames

Which is why I then have to deduplicate to get the real 12 frames in this case

just add `-fps_mode:v passthrough` as an output option

that prevents it from duping or dropping frames based on "framerate"

it just passes them through

for ex `ffmpeg -i input.jxl -fps_mode:v passthrough img%04d.png`

I did use that once but couldn't remeber it earlier and by then I had just deduplicated, thanks!

I will add it to my personal documentation xd

it's basically the old vsync option but vsync is deprecated

Good to know

I know a project where -vsync is still used, I will open a PR to update the setting

vship.

likely imagemagick hashes are based on the non-coalesced frames so they will be different since libjxl decoding coalesces by default

I know libjxl doesn't, or at least didn't, handle unspecified disposal types in GIF. So it would error or have slight artifacts

I am getting some ads here x) thank you blue

What PNG library does `djxl` use?

libpng

Hmm so my procedure of quickly "resetting" PNG works: `cjxl -d 0 -e 1` -> `djxl`

`decode_and_encode` from the dev tools might also work

oh, but I think it requires a colorspace hint

though I also think it will ignore it with PNG input

yeah, maybe cjxl/djxl isn’t so bad

what is "resetting" a PNG supposed to do, exactly?

As some may be optimised either really well or badly

what I do is I typically run it through `umbrielpng`, then `optipng`, then `zopflipng` in that order

This resets them to the same pre-optimisation status

you can also use `optipng -zc6 -zm8 -zs1 -f5 foo.png` to force zlib compression level 6, zlib memory 8, zlib strategy 1, filter strat 5

or something of that form

`umbrielpng` to strip a bunch of unnecessary chunks too

https://github.com/Traneptora/umbrielpng

If this is an optimisation it's not what I want to do

I wanted them to be big and at the same rate of compression, and cjxl d0 e1 + djxl can do it well and rapidly

thoughts `-e 11` not attempting to override parameters which were explicitly specified? for example so that if I pass a group size like `-g 3`, it doesn't include the group size in its brute forcing efforts and just always goes with the specified size instead

the reason I'd want this personally is because Jon's code for visualizing predictors and the MA tree will only output images for a single group (which should be 1024x1024), but I think it might also be nice that you could lock down or focus on specific parameters when you're testing their effects on compression

`oxipng --force --zc 1 -f 0 input.png` There ya go, an unoptimized png.

just try your own e10 runs in that case

is there a way I can emulate e11's "e10 + previous-channel MA tree properties" in e10?

Oh that's what `-E` does!

e11 does `-E 4`, but it is not useful on single-channel stuff

yeah for the visualizations i'm using single channel grayscale anyway

then yea just force specific parameters with optipng or similar

Hmm may try later

btw, it's not a brute force search over parameters, it uses pre-selected configurations which were proven useful. as such, it doesn't really make sense to integrate user choice as implemented.

is it done by default?

ah i see, yeah that's fair

yes

that's kind of the point

I could add a setting "--no-strip" but I haven't yet

and that's perfect <:YEP:808828808127971399>

Yeah `-f 0 --zc 1 --force` results larger ones

Tried `--zc 0` for just one initially and it's too large

Much faster than the `cjxl -d 0 -e 1` + `djxl` approach