JPEG XL

AFAIK, the only drawback of the CLA used by libjxl is that it requires a Google account to sign it. I'm aware that this caused issues on other projects, see e.g. <https://github.com/protocolbuffers/protobuf/pull/8710#issuecomment-856879761>.

That's what I was trying to explain.

It makes sense considering that the license was already changed from Apache to BSD before. There are few licenses that are more permissive than 3 clause BSD though

Agreed. I think at this point it's mostly a safeguard to prevent introducing patent-encumbered techniques. Not foolproof of course, since an external troll who did not sign the CLA can always show up and make claims, but at least we can be sure that contributors are not sneaking in things they themselves have patents on so they can then later start asking royalties.

That would be pretty silly. And not very consequential. libjxl is just an example implementation of how to implement an encoder/decoder library.

would be good to have a fix for palette detection for -e 1 before the 0.8 release https://discord.com/channels/794206087879852103/794206087879852106/1060234070409347173

I tried compiling fast-lossless and apparently it depends on libgcc_s.so.1 - wouldn't it make more sense for it to statically link this library for performance reasons?

wait, what?

did you use the bash script?

if so you could try adding a `-static` there and see what happens

static linking is needlessly hard on linux tbh

I'm on Arch Linux using the build.sh script, yeah. Using clang. Seems weird that libgcc would be dynamic and not static

adding `-static-libgcc` does nothing

is it added in all the places where it's needed to be added i wonder

actually is it strange that clang is using libgcc?

nah that part isn't that strange

I would think clang would have its own similar runtime

i think for C++ code there's one more flag

u need to use

`-static-libstdc++`

ok but I doubt that would make as much a performance impact as libgcc

i'm not sure why are you talking about performance impact here

well it's called fast-lossless, it's supposed to be fast...

i think that libstdc++ being dynamic ends up pulling in dynamic libgcc too

either way i can't see static compilation doing much either way

there in theory (i haven't looked) shouldn't be a lot of standard library calls on hot paths

Heeeeey, that did the trick <@260412131034267649> thanks!

Yeah, but libgcc is not standard library. It's processor instruction emulation

Which ideally you would want to be inlined

I would assume

isn't it already?

I assume not if it's dynamically linking to libgcc

intristics and builtin perf critical functions i would assume should be static inline in headers

Then why do most of the packages installed on my Arch box require libgcc?

because pretty much all of them use some library calls for IO

IO would be in libc

oh. hmm

libgcc provides a number of different functions, mainly certain math functions and unwinding

libgcc seems to be a low level library for CPU instruction emulation

it's not really "processor instruction emulation"

Maybe other low level functions that the compiler inserts into programs

It's a low level runtime for the compiler to use and looks like something that is not meant to be dynamically linked

libgcc_s is the shared library, the gcc toolchain will link it when necessary

I was using the clang toolchain...

for example, libstdc++ requires stack unwinding which is implemented in libgcc

libgcc is arch-specific, libstdc++ is (theoretically) arch-independent

Yeah I guess like dec said libstdc++ was depending on that since it's part of the GNU toolchain and clang was linking to libstdc++ for some reason because I guess that's how Arch is set up

It's funny that Arch Linux used to pride itself as "the most BSD-like Linux" and absolutely nothing about it is BSD-like anymore...

it's kinda wild-west version of fedora now

not that it's a bad thing

clang uses libstdc++ by default because it used libstdc++ for many years because libc++ did not exist, and also because libc++ is not ABI-compatible with libstdc++ so if you default to libc++ then you can't link against any system C++ libraries

I doubt statically linking changes performance in any way 🙂

Well depends on how much the symbols are actually used I guess

Veluca should I write a makefile for you so you don't need to use build.sh anymore? :)

I can write makefiles 😛 I don't remember why I chose not to, there was a reason... (Possibly me not being super comfortable with the idea of doing wget in a makefile)

Well you're using curl so you should be a ok :)

why would you want to do that

Because they're low level routines that might be called often

at least that's what it looks like libgcc is

looks like stuff that is meant to be inlined

if it's stuff that should be inlined that makes sense but only if it's compiled like so, just statically linking a libgcc.a won't do that

since that ends up stripping things like "inline" keywords in C

which routines did you have in mind though?

I'm not terribly familiar with gcc's helper library but it looks like it's meant to contain low level routines that are meant to be embedded in the binaries GCC creates

How do you get the JNI to build? I can't seem to get it to build on the latest git master.

Nevermind, I had to run `sudo archlinux-java set java-19-openjdk` because it was defaulting to the Java 8 JRE.

I couldn't figure that out, since ninja also seems to use just one core... I just end up running `ctest` directly. FWIW, those two tests only fail when `-Wp,-D_GLIBCXX_ASSERTIONS` is passed. Without it, it's fine. And on the latest commit, all tests seem to pass fine even with the flag.

Oh, so I'm not the only one.

<@179701849576833024> Here ya go, it's pretty similar to your build.sh ```makefile CXX = clang++ CXXFLAGS = -O3 -march=native -mtune=native LDFLAGS = -flto -static-libgcc -static-libstdc++ OBJDIR = ./build TARGET = fjxl _GITHUB = https://raw.githubusercontent.com/lvandeve/lodepng/$(_COMMIT) _COMMIT = 8c6a9e30576f07bf470ad6f09458a2dcd7a6a84a OBJ = $(OBJDIR)/enc.o $(OBJDIR)/main.o $(OBJDIR)/lodepng.o $(OBJDIR)/$(TARGET): $(OBJ) $(CXX) $(LDFLAGS) $(OBJ) -o $(@) $(OBJDIR)/enc.o: ../../lib/jxl/enc_fast_lossless.cc $(CXX) -I$(OBJDIR) -I../../ $(CXXFLAGS) -c -o $(@) $(<) $(OBJDIR)/main.o: fast_lossless_main.cc $(CXX) -I$(OBJDIR) -I../../ $(CXXFLAGS) -c -o $(@) $(<) $(OBJDIR)/lodepng.o: $(OBJDIR)/lodepng.cpp $(CXX) $(CXXFLAGS) -c -o $(@) $(<) # lodepng retrieval $(OBJDIR)/lodepng.{cpp,h}: objdir curl -o $(@) --url $(_GITHUB)/$(@F) $(OBJDIR)/lodepng.cpp: $(OBJDIR)/lodepng.h objdir: mkdir -p "$(OBJDIR)" .phony: objdir ```

It's not very standards compliant or anything, it could be better.

Actually, funny story. I used < because I originally wrote inference rules.

For some reason they did not work, maybe due to a bug in GNU make or something, so I changed them all to target rules but forgot to change `$(<)` since that isn't standards compliant.

But it worked as intended anyways

For some reason if a target and a prerequisite are not in the same directory, make is behaving as if the inference rules don't exist.

cjxl can read sBIT chunk in PNG and encodes JXL accordingly. The correct bit depth is printed by jxlinfo. However djxl won't recreate sBIT chunk when decoded to PNG.

Please open an issue - should be easy enough to fix

From: https://github.com/libvips/libvips/issues/3132 Is a streaming decode API not available yet? I know progressive decode is available, but is that different from streaming? Sorry, I don't really know the technical details of most image formats, I'm just a normal user for the most part.

there's plenty of streaming decode options 🙂

Just no streaming encode yet. Decode is streaming already for a while (though there's no cropped decode option yet)

I will. cjxl ignores sBIT if different channels are said to have different bit depths but that seems to be intentional.

libjxl is currently tuned for the most part for high fidelity. So it would be nice if libjxl could be given a buffer of YUV-coded data and produce YUV JXL at high fidelity lossy targets.

Not sure how useful it will be in practice... Maybe it would benefit mpv usage.

If there are any mpv developers here maybe they would know more

Is there ever a situation where effort > 7 should ever be used (for lossy mode)?

Effort 8 and 9 are mostly there for "lol just because" reasons right? For VarDCT it's next to useless or am I wrong?

as far as I'm aware e8 uses buttleraugli but e7 just uses heuristics to estimate distance

e9 has minimal improvement over e8 so it's not useful

but e8 over e7 is actually useful

effort 8 is slightly better, also it is better to match the specified quality, because using real butteraugli calculations, instead of approximate, if I understood correctly

Alright. Still -e7 seems to really be the best possible speed/compression tradeoff both for lossy and for lossless, especially when using multiple threads.

That's why it is the default.

Yup. Very good default. Too bad https://github.com/Blobfolio/refract hard-codes effort=9 with no way to change this aside from recompiling.

This is also from the same guy that complains that JXL is too slow. I wonder if anyone has ever told this guy that there's a good reason why 7 is the default setting.

Oh that's really bad.

Will look at the issues once I went through this session of dental clinic.

Do they use the same kind of extreme setting for other encoders?

Yes

Always the slowest option

For avif they explicitly avoid speed 0 because it's too slow for little benefit, maybe the same can be said for jxl effort 9

Wow you're right, there's a comment saying "There is a speed 0, but ... brutally slow" for "very little benefit."

AFAIK there is very little benefit (maybe 2%?) of going above e7

Even less benefit than avif

for compressing photographic content, I'd actually just use e6

in most cases

or e8 if you're willing to make it 10x slower for a couple % of gains

Besides patches, what's the difference between e6 and e7 that makes e7 slower?

Maybe we should do patches at e6 already and make that the new default? Assuming patches is not what makes most of the difference (at least on photos)...

patches are very slow for no benefit on photo

(as in they easily take 25% of the encoding time)

other than that, the main difference is that -e 7 quantizes differently and has a different way of computing CfL, both of which I think have somewhat limited benefits

can we speed up patch detection? I mean in particular in the case where there are none. And is it mostly the is_screenshot type patches or the dot detection that is slow?

dot detection doesn't run at high enough q

unless we changed that, but I don't think we did

can we speed it up? probably

Maybe some cheap photo/nonphoto heuristic (say looking at a few rows per group) and only do the full patch detection if the overall image looks sufficiently nonphoto. And then probably there is some room to speed that up too, I dunno how simdified and threaded it is atm...

Not too much

In particular it's not SIMDfied at all

from benchmarking.md: squirrel (default) enables dots, patches, and spline detection, and full context clustering

didn't know there was spline detection

there isn't

don't trust that file 😛

Okay I've been playing around with gmake and bmake and I think I understand why no one wants to use this terrible garbage

Then again not all of it is make's fault

Just trying to use it for a use case that it's not designed for such as a separate objdir and srcdir

But it does seem overall unreasonably bad

I’unno, makefiles have always worked well enough for me. 🤔

Hmm, then can you explain to me what is wrong with this makefile? ```make CXX = clang++ CXXFLAGS = -O3 -march=native -mtune=native LDFLAGS = -flto -static-libgcc -static-libstdc++ OBJDIR = ./build TARGET = fjxl _GITHUB = https://raw.githubusercontent.com/lvandeve/lodepng/$(_COMMIT) _COMMIT = 8c6a9e30576f07bf470ad6f09458a2dcd7a6a84a $(OBJDIR)/$(TARGET): $(OBJ) $(CXX) $(LDFLAGS) -o $(@) $(OBJ) OBJ = $(OBJDIR)/enc.o $(OBJDIR)/main.o $(OBJDIR)/lodepng.o $(OBJDIR)/enc.o: ../../lib/jxl/enc_fast_lossless.cc mkdir -p "$(OBJDIR)" $(CXX) -I../../ $(CXXFLAGS) -c -o $(@) $(?) $(OBJDIR)/main.o: fast_lossless_main.cc mkdir -p "$(OBJDIR)" $(CXX) -I$(OBJDIR) -I../../ $(CXXFLAGS) -c -o $(@) $(?) $(OBJDIR)/lodepng.o: $(OBJDIR)/lodepng.cpp $(CXX) $(CXXFLAGS) -c -o $(@) $(?) # lodepng retrieval $(OBJDIR)/lodepng.cpp $(OBJDIR)/lodepng.h: mkdir -p "$(OBJDIR)" curl -o $(@) --url $(_GITHUB)/$(@F) ```

don't you need to swap the _GITHUB and _COMMIT lines?

both bmake and gmake know how to build all the targets if the targets are specified explicitly on the command line. But they seem to not have any clue about dependency.

And no, variables are evaluated as-needed in makefiles

If i run gmake or bmake, it tries to build fjxl right off the bat and immediately fails.

But if you explicitly tell it to build each target in order of dependency it works

The Makefile specifies a dependency tree which is utterly ignored.

my guess would be that it would work moving the OBJ = line above the definition of the first target

actually hold on I realized I made a mistake here while I was editing

veluca I think that might actually have done the trick

I mean, in general, not much of a point defining the OBJ variable no? it's used in only one place anyway

Yeah it's just tradition I guess

(and in the recipe you can put some automatic variable I don't remember the name of)

ah, `$?`

It's on two lines actually

obj

``` $(OBJDIR)/$(TARGET): $(OBJDIR)/enc.o $(OBJDIR)/main.o $(OBJDIR)/lodepng.o $(CXX) $(LDFLAGS) -o $(@) $(?) ```

wouldn't that work?

No because $? only lists OOD prerequisites, not all

ah you're right

So if only one file changes it won't be able to build fjxl with an incomplete list of objects

Yeah, it's pretty sad

`$^` perhaps

I made some changes

```make CXX = clang++ CXXFLAGS = -O3 -march=native -mtune=native LDFLAGS = -flto -static-libgcc -static-libstdc++ OBJDIR = ./build TARGET = fjxl _GITHUB = https://raw.githubusercontent.com/lvandeve/lodepng/$(_COMMIT) _COMMIT = 8c6a9e30576f07bf470ad6f09458a2dcd7a6a84a OBJ = $(OBJDIR)/enc.o $(OBJDIR)/main.o $(OBJDIR)/lodepng.o $(OBJDIR)/$(TARGET): $(OBJ) $(CXX) $(LDFLAGS) -o $(@) $(OBJ) $(OBJDIR)/enc.o: ../../lib/jxl/enc_fast_lossless.cc mkdir -p "$(OBJDIR)" $(CXX) -I../../ $(CXXFLAGS) -c -o $(@) $(?) $(OBJDIR)/main.o: fast_lossless_main.cc $(OBJDIR)/lodepng.h mkdir -p "$(OBJDIR)" $(CXX) -I$(OBJDIR) -I../../ $(CXXFLAGS) -c -o $(@) fast_lossless_main.cc $(OBJDIR)/lodepng.o: $(OBJDIR)/lodepng.cpp $(CXX) $(CXXFLAGS) -c -o $(@) $(?) # lodepng retrieval $(OBJDIR)/lodepng.cpp $(OBJDIR)/lodepng.h: mkdir -p "$(OBJDIR)" curl -o $(@) --url $(_GITHUB)/$(@F) ```

It works is OBJ is defined early

If OBJ is defined before the fjxl rule it does not work.

That is what was causing the bad behavior

I'm not entirely surprised 😄 old enough tools operate pretty much single pass

Also I have to have lodepng.h as a dependency otherwise it won't be fetched if it is not needed. Anyways this makefile works perfectly now including with parallel make

check this out: https://github.com/veluca93/magic_makefile

$^ is a GNUism. On BSD the macro $> does the same thing

Which is really annoying... One of them just needs to support both

... stuff like that is the main reason I have to use either `sh` or `cmake` 😛

Right now they support just one or the other. Would be nice if gmake adds support to $> as an alias for $^

Actually I can probably figure out a trick to use it in a way that works on both...

Well anyways that makefile does exactly what your build.sh does except more parallel and it creates object files for main and enc_fast_lossless before linking.

Hope you like it. WTFPL and CC0 and whatever else you like, I waive all rights to the shitty makefile

:)

I have been comparing the features and syntax of bsd make vs gnu make. I have come to the conclusion that all the fancy nonstandard conditional functionality in makefiles is better off being avoided completely. While it's fun and tempting to see what you can do and push the limits as far as possible, after you're done you should realize you created something that no one should ever attempt to use and should rewrite the whole thing as plain and simple and basic as possible with absolutely no smart conditional logic whatsoever

And then you'll see the "stupid" makefile is a lot less lines and a lot easier for you and everyone else to debug and a lot less time wasted :)

Basically everything that's not here should not be used: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html

Not because POSIX is particularly "good" or anything like that. But just because as soon as soon as you introduce complex logic into a makefile you are about to waste too much time with the build system.

In practice you and everyone else forced to use your build system end up wasting way less time making the makefile as stupid as possible rather than as smart as possible

At least that's just what I've noticed.

Despite JXL not packing pixels, images with low bit depth produce usually smaller files than the equivalent files using full 8 bits. Bit depth is expanded by multiplying rather than bit manipulations. For 2 bit and 4 bit it ends up with the same exact values like bit manipulations would, so it works out very well. When encoding an 8 bit picture marked as lower bit depth, it seems the LSBs are removed, although I couldn't figure out where in the code it's done.

could name the file GNUmakefile to force BSD users to use gmake

It's here: https://github.com/libjxl/libjxl/blob/main/lib/jxl/enc_modular.cc#L569

Basically 6-bit images get converted to range 0..63 and entropy coding will benefit from the symbol range being smaller.

We can effectively even do non-integer bitdepths, since the channel palette transform can compactify the ranges.

So say you have an 8-bit image but some values don't occur (this can happen e.g. when changing the contrast/brightness of an 8-bit image), so there are some holes in the range and it's effectively only a 7.5-bit image.

Then channel palette can remove the holes and turn the range into 0..200 or whatever. And for entropy coding, that will be better than keeping the range 0..255 but with holes in it (especially when doing RCTs and/or prediction).

That's what I thought. If palette is used, I thought there shouldn't be difference between 2bit 0, 1, 2, 3 and 8bit 0, 85, 170, 255.

Although the palette itself has to be encoded, so that could make the difference.

That's quite compact, since the palettes themselves are also treated like a 1D image (or not quite 1D, it's nb_colors x nb_channels, but for channel palettes that's 1D) and compressed. So especially if there's some structure in it, it will compress well.

E.g. if you take an 8-bit image but convert it to 16-bit and encode it like that, the channel palette will be basically a 16-bit 256x1 image with a very regular gradient in it, which should compress to just a few bytes.

(I suppose you could the experiment and see what's the difference in size between an 8-bit image and the same image but encoded as a 16-bit image, it should be small).

So the palettes are used for sample values in the individual channels, not for the whole pixels? I didn't know that.

No, both can be done

Palettes can be applied to N number of channels

Channel palettes (where N=1 and the palette transform is applied multiple times) are useful for these bitdepth-type things, but they keep the number of channels the same so for things like gif/png8 palettes, we use palette with N=3 or N=4. Palette represents N channels using 1 channel with palette indices (and 1 metachannel of dimensions nb_colors x N to represent the palette itself).

Alright. And if let's say 4 bit/channel image is encoded, the palette is 4 bits, but the palette indices can be as wide as needed or are those also limited to 4 bits?

Not sure if this is a libjxl bug or in the specification, but the transfer functions are documented differently (https://github.com/libjxl/libjxl/blob/f5d6e2922820d5862f0334cf1e15d5d9eed6ff1a/lib/include/jxl/color_encoding.h#L82):

Also, does the specification really state that the transfer function for 709 have to be 1/0.45? It seems like the recommendation is actually to use BT.1886 (gamma 2.4) since the Rec. 709 spec doesn't actually specify a transfer function *to* display things.

Or you could just write plain and simple makefiles without overcomplicating things with cool-looking features that in practice just end up eating up more time than they are worth.

you do it if you want to do it that way. lead others by example

if your simple features are so convenient to use and maintainable i'm sure people will accept your changes

Palette indices can be as wide as needed. I don't remember what the limit is of nb_colors that can be signaled, there is some limit but it's quite high.

Ah, that's a good point about rec709 not actually giving a gamma value. Can you raise it in <#1021189485960114198> too so we don't forget?

I guess for kPQ, the SMPTE and ITU-R reference should boil down to the same thing, right? In the spec I think we prefer ITU references since the J in JPEG is because it's working under both ISO/IEC and ITU.

Is there some way to disable multithreading in `cjxl`? I’m using a makefile for my project, which already has inbuilt concurrency.

`--num_threads=0`

I see! 🤔 Is there a difference between that and `--num_threads=1`? I guess I should have checked the manpage, but I thought it’d have been in `--help`.

I suppose in current cjxl/djxl it's --num_threads=1

(i think setting it to 0 makes it use the default number of threads now, which is generally more than 1)

🤔 then yeah, if that's the case, it should be in `--help`

ah no, -1 makes it the default

0 is doing everything in main thread

1 is forking one thread

there shouldn't really be any noticeable difference between 0 and 1, it's just technically slightly different

about 70k

note djxl is different, which we probably ought to fix xD

ah that's why I was confused

yes we should make it behave the same way in both cjxl and djxl, this is very confusing 🙂

and for fjxl <:YEP:808828808127971399>

right. IIRC the idea was that we wanted to be able to do channel palettes for 16-bit images where the number of colors is somewhat but not much smaller than 2^16. That could still be useful in principle. For multi-channel palettes, more than 2k colors or so is probably never a good idea for compression, so the limit is not limiting at all. We didn't really worry about > 16-bit, but I think that's fine since when you're using > 16-bit, likely it's in an authoring workflow where compression is not the main concern so subtle things like being able to do non-integer bitdepths effectively are not that important.

Yeah well like I said, in my practice, I notice that a lot more time is wasted debugging the build system once any non-standard GNU or BSD features are added to the Makefile. Trying to circumvent the built-in limitations by introducing logic and control flow to work around it, is not the correct solution and will waste everybody's time. The build system should be as stupid and basic as possible so time isn't wasted on debugging failures of the build system. Especially failures that happen for extremely simple reasons (some wrong flag) but are made way more complicated and time consuming to correct because of the complexity of the makefile.

So the correct solution is either, don't use any features other than very basic macro assignment and rule definition, and don't try to be clever or work around the built in limitations of make by using clever features from the GNU and BSD variants

Then as a side effect your project will simply build everywhere with a very minimum amount of time spent debugging `make`

If someone on an exotic system can't build it then it will be very quick to figure out what's wrong

do you think that things what actually reduce amount of typing like pathsubst in gnu make are here to waste everybody's time?

Alternatively, use a different tool if the limitations of make are too inconvenient for you. For example, if you want targets and dependencies to be in different folders, or if you want filenames with spaces in them, don't use make

There here because the `make` tool has extreme and obtuse limits on certain things in its design for no good reason. So it's very tempting to work around those limitations by introducing clever control flow.

But a better solution would be: don't use `make`

Or if you use `make` don't try to work around the limitations.

i've actually used very simple makefile.in with autoconf to generate makefiles that are capable of outputting binaries in separate folders than source

Yes, but then... you have to use autoconf.

It's possible but that doesn't mean it's a good idea.

yeah. but it ends up kinda okay. other than obtuse autoconf syntax

It's possible to do all sorts of things in make but then you are wasting way too much time trying to figure out how to get it to compile right

it hasn't been breaking in obscure ways and i didn't spend too much of my time getting it right, and i only need to use autoreconf to generate configure script for releases, and require gnu make for ones compiling stuff

also pretty minimal solution build dependency wise, only need gnu make

If you just stick with the most extremely basic features, common to all versions of make, then it's very clear at a glance what's going on if something doesn't build.

oh also i've used makedepend for header dependencies

Well makedepend is pretty clever and it does not really complicate things I don't think

It outputs standard dependency syntax

i have many .c and .h files so writing up these dependencies by hand woulda been pain

And `include` is a standard feature in makefiles

i think out of build systems i only really liked redo

https://redo.readthedocs.io/en/latest/ this thingy

but that would be either asking people to install it before building, or bundling it with source myself

and i just wasn't too familiar with it yet at that point

A lot of developers use GNU autofool. There's literally nothing good about it.

i hate gnu automake

autoconf is kinda oki but automake is ew

It really overcomplicates things and it's just plain bad

Like most GNU stuff.

I have been meaning to open an issue about that for a long time: https://github.com/libjxl/libjxl/issues/2073

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

Congrats on the 0.8 release!

0.8 is out already? Nice!

Grande Luca!!! <@179701849576833024> e anche tutto il team ovviamente

I don't know about other encoders, but rav1e default settings perform pretty outstanding. It produces files that are SLIGHTLY lower fidelity than JXL by default. However, the file size is a massive decrease compared to libjxl default. Typically more than 4 TIMES smaller files for a very minor reduction in fidelity. if you dial down libjxl to produce a similar sized file, a lot more image detail and texture is lost compared to the AVIF. Probably because rav1e is highly tuned for that bitrate and libjxl is not.

Would be nice for a low-bitrate-tuned libjxl to beat avif at its own game

``` $ ffmpeg -hide_banner -h encoder=libjxl Encoder libjxl [libjxl JPEG XL]: General capabilities: threads Threading capabilities: other Supported pixel formats: rgb24 rgba rgb48le rgba64le gray ya8 gray16le ya16le grayf32le libjxl AVOptions: -effort <int> E..V....... Encoding effort (from 1 to 9) (default 7) -distance <float> E..V....... Maximum Butteraugli distance (quality setting, lower = better, zero = lossless, default 1.0) (from -1 to 15) (default -1) -modular <int> E..V....... Force modular mode (from 0 to 1) (default 0) ```

useful settings like progressive or gaborish are not there

Only -modular lol

For some reason that setting just... has a strange attraction to people.

Also it would be nice if it supported additional pixel formats.

Both for encoding and decoding

After all, some JXL is YUV, like lossless-jpeg

such as?

Would be nice to be able to both decode and encode and if there was a way to inquire if the JXL is using YUV encoding

libjxl doesn't accept those as input

or provide them as output

Would be nice

needs to be added to libjxl first

and that's a post-1.0 target

Yeah I'm talking about the api

I don't really see the advantage of it anyway as the only kind of YUV that JPEG XL is capable of is full-range BT470BG matrix

and that's extremely rare in the wild outside of JPEG files themselves

and you explicitly don't want to take any other YUV, such as BT.709, and pass it as-is as JPEG XL cannot code anything else. so it will assume that it's BT470BG and the colors will be incorrect.

to properly code BT.709 YUV4:2:0 as BT470BG you'd have to convert it to RGB first anyway, and then to BT470BG

(well in theory you'd multiply the matrices and do it in one step, but my point is it requires a matrix conversion anyway so you gain nothing by being able to feed YUV)

All I know is that if you take a jpeg and losslessly encode it to JXL the JXL uses the same color encoding as the original JPEG it seems.

BT.470 BG is a color space I think, and, I'm not terribly familiar with all the countless color spaces there are... but it seems like a possibly useful thing for libjxl to support more pixel formats as input and output

If it really isn't a useful thing maybe I've got the wrong idea

BT470BG is a colorspace definition that includes in it a YUV matrix definition. That's the matrix that is used in legacy JPEGs

Two files can have the same pixel format but different color spaces

don't confuse color space with YUV matrix color space is a description of RGB properties like gamut or transfer curve

YUV matrix describes the affine linear transformation from RGB -> YUV

JPEG only supports YUV with the matrix defined in BT470BG

it doesn't support any other YUV matrix, and for that reason, JPEG XL only supports exactly that YUV matrix

the *color space* of a JPEG file is much more permissive, and can even be described by an ICC profile

it *would* be nice if libjxl accepted more pixel formats, especially planar gbr for bit depths between 8 and 16, so those can be done losslessly

but I don't believe YUV input would be useful

There's the RGB colorspace which depends on icc profile, and then there's the transform from RGB to (possibly subsampled) YCbCr, which is fixed in JPEG to a specific matrix and upsampling procedure (which implies a specific sample alignment), and JXL only supports specifically what JPEG does there. In video codecs, generally a variety of matrices and sample alignments exist, but we didn't want to put all of those in the spec / code since it just complicates things while it isn't needed for lossless jpeg recompression.

What buffer formats to use (planar vs interleaved, integer or float, endianness, various precisions, various component orders), that's only a software library API question, not a spec thing.

It seems that the maximum integer sample bit depth supported by JXL is 24 bits, but no format supported by cjxl/djxl can do that.

Correct. We could in principle extend ppm/pam to do that, using 3 bytes per sample instead of 2 or 3. So far we haven't really encountered use cases for that though. Anything >16-bit is in practice either float32 or fp24.

That makes sense, 24 bit depth doesn't seem to be that useful. I discovered that when I was playing with with --override_bitdepth to see what will happen. There is a hole in the range from 25 to 31, where the encoder refuses to proceed.

Speaking of ppm/pam, the PNM writer in djxl is pretty dumb. It requires specifying the exact appropriate format. The pnm extension is not accepted, although pnm extension can be used for both ppm and pgm formats. If pgm is specified for a color image, the decoding will fail. If ppm is specified for a grayscale image, the decoding will fail as well. PAM supersedes both ppm and pgm but the decoding will fail if pam is specified for images without alpha.

Is there anything PNM can do that PNG cannot?

Not really. Well it can do all bitdepths up to 16 while PNG can only do 1,2,4,8,16.

Strictly speaking e.g. 3-bit cannot be represented exactly in png, since a value like 1/7 cannot be represented exactly in 4-bit or in any other bitdepth supported by png.

(2/15 is less than 1/7 and 3/15 is more)

PNG can store information about the original bit depth in sBIT chunk. 3 bit samples has to be scaled to 8 bits but scaling is done in a way that the original bits can be restored by removing the additional LSBs.

Yes, but that's a chunk viewers can ignore...

Yes, sBIT chunk is not needed for viewers. That's why the scaling is being done, so the image will look right.

JXL decoder can also upscale bit depth and it supposedly uses more accurate method.

Well 1/7 is about 14.3% but represented in 4-bit PNG it would become 13.3%. The difference between how an sBIT-aware viewer shows that and how a non sBIT-aware viewer shows that might be noticeable. It's an off-by-two in 8-bit...

Well, 4bit PNG can be only grayscale, there is no 4bit RGB in PNG. 3bit grayscale is only 8 shades, so it's quite forgiving and slight inaccuracy would be unnoticeable. 3bit RGB would have to be expanded to 8 bits anyway.

Alternatively, 3bit grayscale could be converted to 16 color palette which is always 8bit RGB.

Why not just zero out all the least significant bits?

Because then white becomes light gray...

Even with sBIT set?

If you do that with a 1-bit image, white becomes 50% gray

That's my point: most viewers just ignore sBIT.

It's a chunk of the 'ancillary' type, so viewers are free to simply ignore it.

Sorry, I'm still reading the backlog.

Well, sucks for those viewers then.

Most people use libpng tho

So pretty sure most viewers support whatever libpng supports

So I really doubt most viewers have broken support for PNG

Sounds like the proper thing to do in this situation is tell the publishers of broken software "hey your software is broken"

png encoding step is quite slow indeed in djxl

So in my testing rav1e default settings produce file sizes that are approximately the same as -q 75 in cjxl. Yet at that size the AVIF preserves more detail if you compare the current state of both encoders.

At higher bitrate libjxl might preserve more detail but I have not tested this

So it's possible rav1e performs well at high bitrates too.

Better than libaom, according to my testing. But speed is even slower...

Depends on the CPU. libaom is basically garbage in my experience.

Slow, bad defaults, bad options, bad quality.

SVT-AV1 is decent speed but I heard it has no ARM optimization

The last word to the sBIT topic. The PNG spec requires the sample values to be upscaled. http://www.libpng.org/pub/png/spec/1.2/PNG-Encoders.html#E.Sample-depth-scaling The sBIT chunk itself is only informative. http://www.libpng.org/pub/png/spec/1.2/PNG-Chunks.html#C.sBIT

Wow that's really shitty. So PNG requires lossy sampling.

It's not lossy if it's done right. The goal is to fill only the additional bits, keeping the original bits intact.

Ah, I see. I'm reading it now and yeah there is a way to have it be lossless still

Too bad that everything except zero fill will be bad for compression

Even zero fill is bad for compression. PNG does not have separate context for the odd bytes and the even ones...

It's not as bad as replicating msbs though

And deflate is too dumb to notice the pattern either way

It seems in JXL all channels must use the same sample bit depth. And possibly all frames as well, am I right?

The 3 color channels have the same bitdepth. Extra channels can each have their own bitdepth.

And yes, it's an image header thing so the same for all frames

Alright, but if extra channels have different bit depth, that won't correspond to the image header.

Also, in cjxl's PNG decoder, alpha with different bit depth is being rejected, but alpha is considered to be a special case of extra channel, right?

What if there's only 2 color channels?

AFAIK there are always three color channels but two of them can be empty.

I dunno, pretty sure Y is luma.

:) Just being silly for the most part though

There are either 3 color channels (RGB or XYB or YCbCr) or 1 (grayscale).

Yes, in principle we could handle alpha being at a different bitdepth than rgb.

This might be useful for artworks, where transparency is just 1bit mask instead of full alpha channel.

Compression-wise, if alpha is only using 0 and 255, it will be encoded in basically the same way as when it's 1-bit.

but if the alpha channel is *tagged* as 1-bit then it probably shouldn't fail to encode to PNG

even if in theory it could have been tagged on encode as 8-bit

If RGB channels are tagged as different bit depths, the sBIT info is ignored and the bit depth from PNG header is used. If alpha is tagged differently from RGB channels, loading PNG will fail. I think the behaviour should be consistent in these cases.

The relevant part of the code starts here: https://github.com/libjxl/libjxl/blob/a67e97090d5e0287ededc5b691b56cee30becbf8/lib/extras/dec/apng.cc#L700

Expanding 1 bit alpha to the same bit depth used by color channels is probably better than enforcing 1 bit. After all, if the source was gif or png with tRNS, it is possible to restore losslessly encoded image to png with tRNS.

Is JXL good at compressing pixel art? I would love a codec that supports defining what "upscaler" should use the viewer. For example, pixel arts pictures would be compressed really well if we save only one color per block and specify that the viewer should use "nearest neighbours" upscale I'm just wondering how good JXL support pixel art compression (preferably lossless) 🤔 Don't really know if this is the good channel :/

lossless JXL does compress pixel art quite well because it uses a palette transform

Nearest neighbor upsampling can in principle be done with custom weights for the upsampler. Only 2x, 4x and 8x though.

can the library accept custom upweights?

as far as I know it is not exposed

I think probably in the future squeeze/wavelet/modular lossy compression might be more effective at low bitrate/fidelity targets than DCT-based compression.

Probably depends on the visual characteristics of the input too.

I have a question about the lossless conversion of jpeg to jpegxl, is the converted image pixel perfect (with optimized everything inside including coefficients if needed) or is everything saved to reconstruct exactly the byte perfect original jpeg ?

Both

The question missed the initial target 😄 can I have only the pixel perfect without the byte perfect ? 😅

Yes, just strip the `jbrd` box

Just be aware that without jbrd, the current implementation is not able to restore the coefficients to jpeg file, so it is one way conversion.

one way yes, but pixel perfect. Thank you all for the answers

Is this ever going to be fixed so that a legacy-compatible JXL can still be reconstructed into a valid pixel-perfect JPEG even after the JBRD is stripped?

Because maybe sometimes being pixel perfect is all that actually matters, not pedantically-perfect

I don't think there is a technical barrier. Someone just needs to do the work.

Yeah, I guess it was a dumb question.

I guess it will also be easier to do once the libjpeg API features are more fleshed out too

Hmm, if libjxl ever becomes a real drop-in replacement for libjpeg, I wonder if that means it will provide a cjpeg, jpegtran, etc tools as well

Or even better, jxltran tool and API

whoops, I think I trigger something when encoding with -d 25

the image is RGBA F16 with couple of extra channels

I've noticed that the Brotli related dlls have disappeared form the Windows build. Does it mean they're not needed anymore?

It seems the Brotli dlls have disappeared after the Brotli update, the build from 30-Jan doesn't include those dlls anymore.

do keep in mind that JPEG decoding isn't fully specified

so you can decode the same JPEG file to a pixel buffer in multiple compliant ways

converting that JPEG file to JXL losslessly will lock in a specific decoding of pixel data, since JXL is fully specified

Though you can still go back to JPEG and decode in a different way if you want

SSIMULACRA2 ```css 81.47468192 jpeg:enc-jpegli:q88 82.07433231 jpeg:enc-jpegli:q88:dec-jpegli 82.10371363 jpeg:enc-jpegli:q88:dec-jpegli:bd16 82.49778292 enc-jpegli:q88 - lossless jpeg.jxl ``` does jpeg transcoded to jxl has even more quality improvements than the jpegli decoder? and what are the differences, higher precision and jpegli needs to be faster?

distance max is 15, it should refuse to encode more than that

25 is maximum in cjxl but in headers there is written only 15.

I suppose jpegli only decodes to uint8 or uint16, while libjxl is decoding to float32 which is more precise

cjxl still refuses to work without the Brotli DLLs, so these are actually missing in the Windows build. It seems that something went wrong during the Broitli update.

ah yes, this discrepancy kinda confuses me~ because most of the time it encodes fine when I set the distance to 25

AFAIK, Brotli is now statically linked within the pre-built libjxl Windows binaries. Issue <https://github.com/libjxl/libjxl/issues/1694> contains some details on this.

This issue was once solved and now it's not working again. cjxl is complaining about brotlidec and brotlienc dlls missing. I'm testing the build from here: https://artifacts.lucaversari.it/libjxl/libjxl/latest/

Ah, I could also reproduce this on the artifacts listed at <https://github.com/libjxl/libjxl/actions/runs/4084058635>, investigating.

```diff --- a/.github/workflows/release.yaml +++ b/.github/workflows/release.yaml @@ -332,6 +332,7 @@ jobs: set -x mkdir build cmake -Bbuild -H. ${{ matrix.arch }} \ + -DJPEGXL_STATIC=ON \ -DBUILD_TESTING=OFF \ -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_INSTALL_PREFIX=`pwd`/prefix \``` would probally fix that, let me open a PR for that.

I think they just forgot to change 15->25 in the headers. Anyway, in my Qt plug-in I use distance range only from 0 till 10. Values above 10 didn't look very attractive.

I just opened PR <https://github.com/libjxl/libjxl/pull/2144> and <https://github.com/libjxl/libjxl/pull/2145> for this. Thanks for reporting this!

how did you installed it ?

sorry... switching languages every 5 minutes made me answer in french 😄

I can't find any good answer but ! looking here https://github.com/libjxl/libjxl/tree/main/debian should help you find the files you may have installed ... don't delete /usr/bin though ! But you can compare what you have in your build/ directory and find what was installed where

(because it is a shitty process, we invented package managers :D)

I mean, on a recent debian you can just do `sudo apt install libjxl-tools`

not sure how other distros are doing, but if your distro doesn't have a package, I would recommend complaining to your distro 🙂

could someone make a list of what distros have packages and what the commands are to install them? I agree that this would be useful to put in the README. We're no longer at the stage where we can expect most people to build it from sources to try it out, most people just want to quickly get a binary they can run. Maybe we should even move the build instructions to a separate document instead of spending half of the README on that.

<https://repology.org/project/libjxl/versions> tada?

FWIW, the build artifacts listed at <https://github.com/libjxl/libjxl/actions/runs/4085744605#artifacts> would probably fix this.

Everything looks good. Thank you.

If you need to reclaim space on your disk, uninstalling clang would be much more efficient than uninstalling libjxl 😊

What's the conf of your box to be in such a need?

can I ask you why you have that severe storage limit

yeah let's go to <#806898911091753051> for that

Try stripping debug symbols from all binaries, that can reduce their size quite a bit

To compile without Clang, just don't do `export CC="clang" CXX="clang++"`, then CMake will use your system default compiler, probably GCC. That's what the Arch package does IIRC, since it doesn't specify Clang.

wow, termux updates fast, it's the only one v.0.8.1, released 10 hours ago

when was JxlBitDepth added?

ah nvm, git blame says last october

does libjxl include version numbers as preprocessor directives?

or is it only the runtime JxlDecoderVersion()?

IIIRC we have both, there's a version.h

I see it, thanks. It's not documented though

is that patches welcome territory?

I guess so xD

So, I took a (rather large, panoramic) photo with my iPhone and tried compressing it using distance=2 and the results are... okayish I guess maybe? But I would not call it perceptually uniform. For an HDR-focused format, it seems odd how it gets noticeably blurry, but ONLY in the parts of the image with the shadow on the ground.

Details are preserved well across the image with this one weird glaring exception. The texture is noticeably smudged and blurred on the part of the ground where I'm casting a shadow

How did you get pristine pixels to start with?

Started out life as a JPEG.

It looks less noticeable than I remember the second time around. :)

But basically I thought that compared to the rest of the image this is the only part where it's actually noticeable.

And JXL and other HDR-focused formats are supposed to be good at retaining detail and texture in shaded areas

Likely that jpeg is transcoded from a heic, so doing a third lossy compression is not so great for retaining detail...

No, it was taken before HEIC was a thing

And I'm careful not to transcode HEIC to JPEG

I'm aware of Apple's automatic transcoding

Is there a way to get djxl to reconstruct jpeg to stdout?

For piping into another program that accepts JPEG on stdin

At some point `djxl foo.jxl -` would do that, no idea it that still works

No, does not

I tried

Also, cjxl does not support JPEG with arithmetic coding?

Ah wait, no idea if that would work for jpg reconstruction, since it doesn't know what extension the output file gas

``` JxlEncoderAddJPEGFrame() failed. EncodeImageJXL() failed. ```

Yeah it fails because it uses file extension to determine output format

I guess djxl does not support stdout

also cjxl does not support arithmetic-coding in JPEG input

Hmm also I can losslessly optimize my JPEGs almost as good with `jpegtran` compared to using cjxl

Especially if I use arithmetic coding

Within 10% of what I can get with cjxl

As in cjxl still wins but not by a lot

It might be a good idea to have a more helpful error message when this happen

making it clear why it fails and that cjxl is not capable of reading arithmetic-coded JPEG

but if libjxl intends to implement the libjpeg api it might be a good idea to implement arithmetic coding

JPG = 15 MB JXL = 14.1 MB

The reconstruction data is 289 KB... That's pretty big...

Too bad JBRD is required to transcode to JPEG...

Here is the whole, lossy d2 image. The lossless is too big for discord.

using rav1e at the highest speed setting I was able to produce this file just for shits and giggles. Despite using the highest speed setting it looks like AVIF actually retains more detail and texture in dark areas compared to JXL

This is despite being a smaller file size and using the highest available speed

Produced using: `avifenc -j all -c rav1e -s 10 --min 28 --max 29 IMG_0116.JPG IMG_0116.AVIF`

Here is the original file, truncated to fit within discord limits. Restore with `cat`

I used `dd` in order to divvy it up.

I hope this example has been helpful in identifying shortcomings with the encoder's strategy of economy.

also `jxlinfo` says that the image is "possibly lossless" somehow, but it's a DCT image that was encoded from a JPEG so it is definitely not lossless.

There is no possibility

Is that a bug?

It says "possibly lossless" it it's not XYB

So that includes losslessly recompressed jpegs

Of course you can argue that a losslessly recompressed jpeg is not lossless, since jpeg is already lossy.

It all kind of depends on what you consider the pristine source. If your camera produces only jpeg output (at q96 or something), then that's as pristine as it gets — converting it to 8-bit rgb pixels is not making it any more pristine, to the contrary.

But of course a jpeg can also be low quality, just like rgb pixels may be low quality. It only says "possibly lossless", since there is no way to know the history of the image.

Not only that but it uses chroma subsampling too

So calling it "possibly lossless" is just wrong on so many levels

I think it should only say "possibly lossless" on images that are "possibly lossless"

There is no way this is possibly lossless

If it's known for a fact to use lossy encoding then it shouldn't say that

The thing is, the current libjxl api exposes the color space (xyb or rgb) but not the frame encoding that was used (modular or vardct) or other frame header fields (like ycbcr and chroma subsampling)

"possibly" doesn't mean "certainly", and it is philosophically not so clear what "lossless" means anyway — if the only remaining source for the image is a q60 4:2:0 jpeg, then arguably that is "lossless", imo.

It would also be nice if there was a recommended way for an encoder to write to the output file what alleged encoder settings were used and whether the file is meant to be a lossless representation of the source or not.

It's a lossless representation of the JPEG source... But we know that JPEG images are never lossless by their nature, it's quantized and then approximated in a different domain than the one it's being displayed in, etc

So it's a bad idea calling an image like that "possibly lossless" if it's known to have undergone so many lossy transforms like DCT and chroma subsampling... Actually it's pretty weird that XYB is the only thing that is considered.

Because isn't XYB theoretically a mathematically reversible transform?

XYB is not bit-exact reversible

it's mathematically invertible if you had infinite precision

but you don't

The reason it says "possibly lossless" for nonXYB is that the frame headers aren't exposed by the API so the decoder client doesn't have that information

so it can't say "lossy" if VarDCT

cause it doesn't know if VarDCT or Modular

LMS* have a cuberoot and bias factor

Maybe LMS don't precisely coincide with RGB but I wouldn't understand why not

L* = cbrt(L - bias) + bias2

you apply this, then do that linear transform

It's possible that in the future content will be created in XYB domain from source.

https://github.com/thebombzen/jxlatte/blob/5b02554f9ab01134b7a19c1182f81b366fd3bcd1/java/com/thebombzen/jxlatte/color/OpsinInverseMatrix.java#L90

unlikely as XYB is modeled after human perception, not after tristimulus RGB hardware like CCDs

We wouldn't have RGB if we didn't have LMS cones in our eyes

Also XYB is specifically designed after linear sRGB

although the opsin inverse matrices could be multiplied

so I suppose maybe that's not an issue

it would make more sense to model hardware after LMS than XYB, for that reason

That's the kind of metadata that a new adhoc group in jpeg is going to standardize. But it's tricky, since not just the last step matters, but the entire history. If the last step is losslessencoding but the image has been a q50 jpeg that was converted to a gif before being converted to a 16-bit PNG, then it would be rather silly to have metadata saying it's a lossless 16-bit image.

at least encoding settings could be an extensions payload. safe to ignore on decode

Well you cannot control the entire history of the image but the encoder can at the very least have an opportunity to record how it was allegedly configured at the time it did its work.

For display/capture technology it makes sense to use primaries that allow you to get a nice gamut, i.e. as saturated as possible. For perceptual modeling though, LMS makes more sense. The L and M are commonly referred to as the 'red' and 'green' cones but in reality they both peak at a kind of lime green, L just a bit more yellowy than M.

L peaks at a yellowy green?

Making cjxl or libjxl add some custom xmp or exif field, or a new isobmf box with encode settings wouldn't be too hard.

The transfer curve of sRGB wasn't intended to be perceptually relevant, it was intended to model how CRT displays of the early 1990s translated voltage to intensity.

Is that a good idea of what those colors look like at that frequency? Because the spot where S is peaking is a lot darker than the spot to the right of it. I would expect the brightest-looking spot to be where the peak is.

Object-oriented code makes me want to sit in a corner and cry... :(

Its like it was invented by business executives trying to think of ways to suck all of the joy out of programming