JPEG XL

Or does that confuse more than clarify?

that would prevent accidental reassignment but would also prevent manual user assignment to nullptr after destroy which can be useful in some situations

and i think u can just pass it to free anyway

just document in big letters that jxldestroy is intended to free it and no extra free is needed

would prob be good idea to mention jxldestroy on constructor's doc too

Yes, makes sense. This is good feedback btw, we need to improve the API documentation (including example apps)

you can pass a `const int* const` to `free()` without any problem whatsoever 🙂

Yes but you might be less inclined to do it ;)

returning `* const` from func makes no sense as it's attribute for function return destination variable, function declaration itself i think can't enforce that, and no, it'd be confusing and pretty poor form of documentation, something what should be just clearly written down

Agreed, I was talking about using a *const variable in the example apps

ah, yes, for some reason i thought it would work with a pointer to anywhere inside a malloc allocation, but that can't be right

as far as I'm aware, JxlDestroy uses the memory manager that was assigned via JxlCreate, right?

or `free` if there was none

is someone working on https://github.com/libjxl/libjxl/issues/993 ?

Not afaik

i loose at least 1e-3 s on "big image" because of rgba -> bgra conversion.

on my computer

and i have to allocate the image to do the conversion, so it consume more memory than needed

except opengl or png, BGRA is commonly used

You can convert in-place, no need to copy

for the saver, i have to

Ah, I see

well, honestly, for our purposes, time for the saver is not so important

but loading time is very important

we use jpeg to create and compress our themes

so if libjxl is as fast as jpeg, we might consider using it, to have smaller theme files

we also use jpeg to decompress theme files, so decodeing speed is very importnat

why not using meson instead of cmake ? you already use a python module (sphinx) so you could also use meson

also the syntax is so much nicer than cmake

pros and cons to everything, I guess — feel free to make a pull request to add other kinds of build scripts, I don't have strong opinions on it

I do and I think 2 build systems are enough many 😉 (cmake and whatever it is Chrome uses)

there is likely a cost to using CMake over Meson, but our impression is that by this stage, much of that cost is sunk

switching to Meson _might_ take less effort than it took us to get here, but it would still be more than not doing it

so what it would save us in future cost would have to be greater than that

<@!179701849576833024> 2 build systels is too much, my suggestion is : replacing cmake with meson

when build system is too complicated, maintaining cmake build system is difficult and requires tricks

I mean, CMake as it is being used in libjxl is currently fine I believe.

example : https://github.com/libjxl/libjxl/issues/715

with meson, it just works

no special code to add

actually, i think that, anyway, the current build system should be simplified

there are too many dependencies

some are bundled and could be used as system too

some are not

it's just crazy

99% of the usage will be on linux

that is, a package manager will be used

that is, the system libraries will anyway be used

it just werkz

so my opinion is : forget about bundle dep libs, use system libs

that's anyway a sane choice

and the build system will be simplified a lot

<@!794205442175402004> different topic : about animated jxl file, iirc, you told me that with just JXL_DEC_FULL_IMAGE as subscribed event, the frames will be decoded one after the other. But either my code is wrong (which is most likely the cas, or it is not the case

I have to use JxlDecoderSkipFrames

except you cannot just use system libs, or things like running with memory sanitizer will not work 😉

do you really think that package maintainers will compile with sanitizers support ?

and sanitizers should be only for libjxl

so...

but we do

What does the noise stage do?

it applies noise 😄

it doesn't change much, it's a refactor

<@!794205442175402004> hello, did you see my question above ?

can you share your code?

<@!794205442175402004> https://phab.enlightenment.org/D12311

<@!794205442175402004> look at the added file evas_image_load_jxl.c, and its line 193

this function is called each time a new frame should be displayed

to make it work, i had to add line 274 ( JxlDecoderSkipFrames(decoder, animated->cur_frame);)

if not, no animation

Unrelated, but why are you doing `JxlDecoderSetKeepOrientation(decoder, JXL_TRUE);` ?

Ah, you are starting a new decoder object for each frame?

That seems not very efficient

Are you sure there is no way that can be avoided?

Nevermind, you are avoiding that

Or aren't you?

Can you check you're not just re-initializing the jxl decoder for every frame?

<@!794205442175402004> no, i do not start a new decoder for each frame, only if it has not been created (hence the test on the decoder at the beginning

<@!794205442175402004> about JxlDecoderSetKeepOrientation(), it is said in the doc that it is faster for libjxl

well it is faster but you don't get a correctly oriented image

ok

I see you have that test, but are you sure these functions end up getting called without destroying the decoder after each frame?

the argument Evas_Loader_Internal *loader is allocated when the module is loaded in mem

then it is passed to that function

hmm

checking

decoder is detroyed line 417, when module is closed

at the end

<@!794205442175402004> btw, can I use the same decoder to display several jxl images ?

or should I avoid this and use a different decoder for each jxl file ?

you can use the same decoder for different images

as long as you reset it between images, of course

ok, so what i'm doing is correct

ha, reset, ok

i'm wondering why you need the skipframes, that implies that the decoder is going back to the start each time

if I don't ad it, there is no animation

add*

i can remove it again and try again

compilation takes a lot of time

maybe instrument the code to do a printf each time you initialize the decoder with the input

I suspect you might be accidentally giving it the input at each frame

ok

indeed

called several times

there is something wrong in the module behavior

tanks

thanks

i'll have to dig a bit

arg ! i forgot to set the loader values

<@!794205442175402004> ok, working, but when i get the last frame, i rewind, right ?

yes, if you want to decode from the start after last frame

you rewind and have to set the input again iirc (everything except initializing the decoder object itself)

ok, i will try

<@!794205442175402004> i have these error messages from libjxl :

```./lib/jxl/dec_ans.cc:239: JXL_FAILURE: Alphabet size is too long: 130 ./lib/jxl/dec_ans.cc:361: JXL_RETURN_IF_ERROR code=1: DecodeANSCodes(num_histograms, max_alphabet_size, br, code) ./lib/jxl/dec_context_map.cc:81: JXL_RETURN_IF_ERROR code=1: DecodeHistograms(input, 1, &code, &dummy_ctx_map, context_map->size() <= 2) ./lib/jxl/dec_ans.cc:348: JXL_RETURN_IF_ERROR code=1: DecodeContextMap(context_map, &num_histograms, br) ./lib/jxl/coeff_order.cc:78: JXL_RETURN_IF_ERROR code=1: DecodeHistograms(br, kPermutationContexts, &code, &context_map) ./lib/jxl/toc.cc:60: JXL_RETURN_IF_ERROR code=1: DecodePermutation( 0, toc_entries, permutation.data(), reader) ./lib/jxl/decode.cc:1139: invalid toc entries ```

<@!794205442175402004> any idea what i have missed ?

these msg are for each frame of the animation

no idea, looks like you are feeding it a corrupted bitstream

are you sure the input bitstream buffer you give it remains alive long enough?

beside these msg, the animation runs fine

i'll check

what is the cjxl PR ? an attempt to have C code and not C++ ?

or compression part of jxl, actually

we're eventually going to migrate cjxl and djxl to use the api instead of directly calling stuff

Is there currently a use case for --resampling in combination with lossless images or you would agree that it is the worst idea for "near" lossless compression?

probably not the *worst* one

But is it useful or would you say that nobody would mind if that feature for (this particular case) would not exist?

I wouldn't say it's very useful 😛

XYB + "lossless" is prob better

It would be great if --resampling in combination with lossless (RGB) could be repurposed to use integer scaling for decoding so that it is suitable for upscaled pixel art.

With this behavior, the encoder could reach better compression for such image cases with a simple check.

Good idea or not?

Its not too bad currently. <:JXL:805850130203934781> currently gives a ratio in total corpus size of 1.43 for the size of the compressed 32px images (2.17MiB) vs integer upscaled 256px images (3.12MiB). Based on a corpus of ~2000 images (John Smith Legacy Minecraft resource pack), and just naively running `cjxl -d0`.

So it definitely could be improved, but large area's in pixel art don't take up proportionally more bytes.

A custom upsampling filter can be signaled that does NN, costs some bytes to signal it though

<@!794205442175402004> i have added JXL_DEC_FRAME event to JXL_DEC_FULL_IMAGE and i have no error messages anymore

so JXL_DEC_FULL_IMAGE alone is not sufficient

Ah, interesting, I don't know if that's an api bug

at leastit is working

<@!794205442175402004> do you want my code ?

i need to factorise it a bit, but otherwise it is good afaics

Not needed, but maybe you could open an issue on github to ask about dec_full_image not being enough

I think it's either a documentation bug or an actual bug

ok

btw, jpeg has quality value as a value bteween 0 and 100

libjxl has effort between 0 and 7

but is effort the only way to set quality in libjxl ?

between 0 and 9, sorry

Effort is not the way to set quality

Distance is the way to set quality

Effort determines how much time you want to give the encoder to hit the target distance as accurately as possible with a file that is as small as possible

But the target distance is what mainly influences quality (and size)

ok

'distance' is not very meaningful

so, if i don't care about encoding speed, are these values correct :

JXL_ENC_FRAME_SETTING_EFFORT to 1

JXL_ENC_FRAME_SETTING_DECODING_SPEED to 4 (i care about decoding speed)

and the quality based on what we pass for quality

is it ok ?

also :

JxlEncoderSetFrameDistance() should be called before or after JxlEncoderFrameSettingsSetOption() ?

or is the order not important ?

If you don't care about encode speed, better set effort to 9, more effort produces better files

Order should not matter for setting distance and other encode options

Default decode speed of lossy jxl should be good enough, if you explicitly set decoding_speed to max then it will decode even faster but at a cost in both density and quality

I recommend leaving effort and decode speed at their default values unless you really want to get a different trade-off than the one we think is reasonable

Distance is more meaninful than 'quality'. Zero means no distance, 1 means one unit of just-noticeable-difference, higher distance means more distortion. 'Quality' on a scale from 0 to 100 is misleading since 1) there is no bound on how much distortion you can allow, so the 0 point is very arbitrary, and 2) it makes people think it's some kind of percentage, which it is not.

does effort influence quality ?

It does in the sense that higher effort makes it more likely that you actually get the distance you requested

While lower effort has more error margin, you may get something that is better or worse than what you asked for

ok

there should be precise doc somewhere like this in doc

you can always just buy the spec 🤑

as a library, there should be doc about how to use it

otherwise, just throw the lib to trash, as it would just be useless

<@!794205442175402004> when I say that 'distance' is not meaninful, I mean that the word 'distance' is not meaningful. distance between what and what ?

i assume distance from the source

beats quality

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

🤔 what's a viewing distance of 1000 pixels?

From the eye to the display, I guess

pixels?

oh that must be including dpi i guess

Yep, because pixels can be different

as a human i dont normally measure in pixels

right, but this comes into play only for setting the d1 point anyway

this is correct

so d2 ± means that the quality is twice as far away from the original as d1 is, **not** that it’s the same quality if viewed from twice the physical distance

what does these messages could mean ? :

./lib/jxl/splines.cc:594: JXL_FAILURE: Too many pixels covered with splines ./lib/jxl/dec_frame.cc:425: JXL_RETURN_IF_ERROR code=1: shared.image_features.splines.InitializeDrawCache( frame_dim_.xsize_upsampled_padded, frame_dim_.ysize_upsampled_padded, dec_state_->shared->cmap) ./lib/jxl/decode.cc:1495: decoding frame failed

i'm wondering if there are not problems with threads

i add a printf and hop, different messages

What image are you decoding?

spline in conformance tests

ah, that could be a problem

probably we need to bump up that limit...

maybe my code is wrong

i don't know what the problem is

there also could be an interaction somewhere with our toolkit

it's probably our fault xD

i test the animation in a simple viewer i wrote

and when there are some GUI events that are executed, error messages are displayed

i must be sure that libjxl is thread safe and re-entrant

other solution is calling SkipFrames as i did initially. It seems to work but is overkill according to <@!794205442175402004>

btw, do you plan to remove deprecated API when you will release 1.0 ?

Not sure if it will be removed at 1.0 or later

ok

I'm encoding a 12899x8611 png using `cjxl input.png output.jxl -q 100 -e 8 -I 1.0 -E 3 --num_threads=12` and doesn't seem to use much cpu, tho it's using aroud 7GB of RAM

is it worth it to use that many threads per file?

yeah it can help

but tree learning is not parallelized atm

and it's the slowest part

Is there any way to request planar RGB output instead of packed RGB output?

internally, jpeg xl operates on planes, but libjxl packs it before returning the pixels

I'm wondering if you could request planar output, i.e. rather than provide one buffer to lay pixels into, you provide an array of buffers, one for each channel in the original Jpeg XL image

or even better, it would be great if you could ask it for a specific plane

something like

at worst, you can use the "pixel callback" thing

but AFAIU we don't have a specific planar option

```c uint8_t *red, *green, *blue; JxlDecoderRequestChannel(decoder, JXL_CHANNEL_RED); JxlDecoderSetImageOutBuffer(decoder, &format, bar, red); // decode function calls JxlDecoderRequestChannel(decoder, JXL_CHANNEL_GREEN); JxlDecoderSetImageOutBuffer(decoder, &format, bar, green); // etc. ```

that still lays the pixels one scanline at a time packed

it would make sense since some applications require planar input

for example, if you're planning on converting to or from YUV after the fact, you usually want planar RGB

since YUV is almost always planar

can you open a feature request issue?

I can open an issue for that after lunch, sure

.. and I forgot to open an issue

I have a more important issue to open though

something that bothers me is that libjxl will eat all data you give it

JXL codestreams can legally have anything appended at the end of them and they are still legal by spec

If you feed data to libjxl via a `uint8_t *` buffer, it tells you how much it read and how much needs to be fed again

is there any particular reason libjxl cannot refuse to consume data at the end of the codestream?

like it will happily just take it all and do nothing with it

it should report `JXL_DEC_SUCCESS` without consuming all of it

Maybe open an issue? I agree that there's no reason for it to eat past the end, and I bet it just does that because it probably always just eats all you give it before it even starts processing

what's the calculation that cjxl uses to map `-q` to `-d` (or better yet, where in the code is that done)?

https://github.com/libjxl/libjxl/blob/main/tools/cjxl.cc#L602

thanks!

``` [100%] Generating C API documentation /home/anon/Downloads/libjxl-git/src/libjxl/lib/include/jxl/encode.h:813: error: documented empty return type of JxlEncoderInitExtraChannelInfo (warning treated as error, aborting now) ``` .... meanwhile in CMakeLists.txt: ``` set(DOXYGEN_WARN_AS_ERROR "YES") ``` who though it was good idea and why

anyway made https://github.com/libjxl/libjxl/issues/1080

in addition to https://github.com/google/highway/issues/497

did i type it in wrong or is that discontinuous at q=30? https://www.desmos.com/calculator/pdjlj3cf2q

Not intentionally, if it is

it seems to be off by 1/6.25 because 2.5⁰ = 1

subtracting 1/6.25 from the x≤30 case seems to fix it

so 6.24 instead of 6.4

now my calculus brain wants to make it smooth as well

this was pointed out before <https://discord.com/channels/794206087879852103/794206170445119489/905841407900651580> <https://discord.com/channels/794206087879852103/794206170445119489/907668255454421023>

ah interesting

Wait, custom upsampling filters?

the weights used to do 2x, 4x and 8x upsampling can be signaled — atm we always use the defaults

I changed what I use for the formula

```c /** * Map a quality setting for -qscale roughly from libjpeg * quality numbers to libjxl's butteraugli distance for * photographic content. * * Setting distance explicitly is preferred, but this will * allow qscale to be used as a fallback. * * This function is continuous and injective on [0, 100] which * makes it monotonic. * * @param quality 0.0 to 100.0 quality setting, libjpeg quality * @return Butteraugli distance between 0.0 and 15.0 */ static float quality_to_distance(float quality){ if (quality >= 100.0) { return 0.0; } else if (quality >= 90.0) { return (100.0 - quality) * 0.10; } else if (quality >= 30.0) { return 0.1 + (100.0 - quality) * 0.09; } else if (quality > 0.0) { return 15.0 - (59.0 * quality - 4350.0) * quality / 9000.0; } else { return 15.0; } } ```

I had the exact same thought, so this is what I am using, which is differentiable at Q=30

shouldn't it be 15.0 **+** (59.0 * quality - 4350.0) * quality / 9000.0?

yes, it appears so

Oh, it looks like gflags is now needed <:thonk:855837053862150204>

This poses a small problem when building libjxl.

it's not, it's just needed for tools/

I know, but it's on by default, so I had to look into the cmakelist to see what to disable <:lul:853492073301540894>

Anyone else completely unable to build libjxl for wasm32 in the jpegxl-builder docker container?

``` [128/470] Building CXX object lib/CMakeFiles/jxl_extras-static.dir/extras/enc/jpg.cc.o FAILED: lib/CMakeFiles/jxl_extras-static.dir/extras/enc/jpg.cc.o /opt/emsdk/upstream/emscripten/em++ -DJPEGXL_ENABLE_APNG=1 -DJPEGXL_ENABLE_GIF=1 -DJPEGXL_ENABLE_JPEG=1 -DJPEGXL_ENABLE_SJPEG=1 -DJXL_EXPORT="" -D__DATE__=\"redacted\" -D__TIMESTAMP__=\"redacted\" -D__TIME__=\"redacted\" -I../ -I../lib -I../third_party/libpng -I../lib/include -Ilib/include -I../third_party/brotli/c/include -I../third_party/highway -I../third_party/sjpeg/src -fno-rtti -funwind-tables -Xclang -mrelax-all -Xclang -mconstructor-aliases -fno-omit-frame-pointer -O3 -DNDEBUG -O2 -fPIC -fmacro-prefix-map=/jpeg-xl/libjxl=. -Wno-builtin-macro-redefined -Wall -Werror -fmerge-all-constants -fno-builtin-fwrite -fno-builtin-fread -Wextra -Wc++11-compat -Warray-bounds -Wformat-security -Wimplicit-fallthrough -Wno-register -Wno-unused-function -Wno-unused-parameter -Wnon-virtual-dtor -Woverloaded-virtual -Wvla -Wdeprecated-increment-bool -Wfloat-overflow-conversion -Wfloat-zero-conversion -Wfor-loop-analysis -Wgnu-redeclared-enum -Winfinite-recursion -Wliteral-conversion -Wno-c++98-compat -Wno-unused-command-line-argument -Wprivate-header -Wself-assign -Wstring-conversion -Wtautological-overlap-compare -Wthread-safety-analysis -Wundefined-func-template -Wunreachable-code -Wunused-comparison -fsized-deallocation -fno-exceptions -fmath-errno -fnew-alignment=8 -fno-cxx-exceptions -fno-slp-vectorize -fno-vectorize -disable-free -disable-llvm-verifier -DJPEGXL_ENABLE_SKCMS=1 -DJPEGXL_BUNDLE_SKCMS=1 -std=c++11 -MD -MT lib/CMakeFiles/jxl_extras-static.dir/extras/enc/jpg.cc.o -MF lib/CMakeFiles/jxl_extras-static.dir/extras/enc/jpg.cc.o.d -o lib/CMakeFiles/jxl_extras-static.dir/extras/enc/jpg.cc.o -c ../lib/extras/enc/jpg.cc ../lib/extras/enc/jpg.cc:8:10: fatal error: 'jpeglib.h' file not found #include <jpeglib.h> ^~~~~~~~~~~ ```

seems like you're missing the libjpeg headers

I am using the official jpegxl-builder docker

and /usr/include/jpeglib.h exists

guessing you need `-I/usr/wasm32/include` then

I'll try that

how do you make it cross-compile for wasm32 anyway? i only see instructions for windows and arm

that would be ```CXX_FLAGS=-isystem\ /usr/wasm32/include``` for the build_and_test task right?

Here is the doc page for wasm https://github.com/libjxl/libjxl/blob/main/doc/building_wasm.md

<@!164917458182864897> we're trying to follow this, but it doesn't link gif_lib.h jpeglib.h

https://github.com/libjxl/libjxl/blob/main/doc/building_wasm.md

both files exist in `/usr/include`

idk what `-i` does but `-I/usr/wasm32/include` would typically be the way to add that to the include path

That seems to have fixed it, thank you

submitted a pull request to document this behaviour

I also had problems to build libjxl for Squoosh (which also uses Docker), I'll probably try building it once again now, maybe something fixed itself...? https://github.com/GoogleChromeLabs/squoosh/pull/1136#issuecomment-974329630

<@456226577798135808> https://github.com/libjxl/libjxl/pull/1104

here, this will probably help, we figured out that you need to explicitly add the `/usr/wasm32/include` directory, for clang++ to actually use it

Unfortunately it didn't help. Exactly the same error as here: https://discord.com/channels/794206087879852103/803663417881395200/911330790187597864

hmm

are you pushing that to the ci.sh file?

as an enviroment var

To reproduce: 1. `git clone https://github.com/ziemek99/squoosh.git` 2. `cd codecs/jxl/` 3. Edit `Makefile` to get the latest git version of libjxl: ```diff diff --git a/codecs/jxl/Makefile b/codecs/jxl/Makefile index 809a972..274bf65 100644 --- a/codecs/jxl/Makefile +++ b/codecs/jxl/Makefile @@ -1,5 +1,5 @@ CODEC_URL = https://github.com/libjxl/libjxl.git -CODEC_VERSION = v0.5 +CODEC_VERSION = 9f544641ec83f6abd9da598bdd08178ee8a003e0 CODEC_DIR = node_modules/jxl CODEC_BUILD_ROOT := $(CODEC_DIR)/build CODEC_MT_BUILD_DIR := $(CODEC_BUILD_ROOT)/mt ``` 4. Start Docker (I can give you my command if you have problems). 5. `npm run build`

`CMAKE_FLAGS=-I/usr/wasm32/include BUILD_TARGET=wasm32 emconfigure ./ci.sh release` this is how we got our compiles

using the ci.sh interface

from the docker

I'm not using `./ci.sh` at all, it's all abstracted away by `npm run build` from Squoosh project.

hmm

idk how <@!281115117884801025> got the squoosh build, idk if we just copied it from the squoosh lib repo, or if we managed to compile it

As you can see in a diff above, it's probably because you've got an older version. In Squoosh libjxl is stuck at v0.5.

v0.6.1 works, too, but it doesn't have a bugfix my PR is reliant on, so I have to use the latest git, which fails. https://github.com/GoogleChromeLabs/squoosh/pull/1136#issuecomment-974329630

1 question, do you know if squoosh uses the default wasm build of jxl?

just with a custom module wrapper?

because if thats so, you can just use the docker to get your build, and drop in replace the .wasm

The thing is I don't know a shit about their building systems. I only wanted to make a simple PR involving just a few lines of code, not deal with the whole Docker and Makefile BS... ;_;

yea...

i'll try doing some tests

*when <@!281115117884801025> gets up

and see if the docker build can be used

Would you like to try doing the same thing as I did and see if you get the same error?

nope, because for that i would need to install node

and i dont really want to DX

in short no, squoosh adds a some extra code to the wasm

so you'll just have to try and get the node build to work

<@456226577798135808>

skcms can be found at https://skia.googlesource.com/skcms/

Koromaru said it could be helpful

I believe I've gotten it to build with version 0.6.1 of libjxl

I'm going to test it out

and more debugging

I believe I've finally found a solution

one more build

HOLY FRIG IT BUILT

<@456226577798135808> I got libjxl v0.6.1 under squoosh to finally build

This took an embarrassing amount of time, but here it is https://github.com/CanadianBaconBoi/squoosh/blob/dev/codecs/jxl/Makefile

Another issue, going to push a fix

<@456226577798135808> It built, both the encoder and decoder wasm/js files are there with version 0.6.1

you should be able to change the revision in the Makefile to whatever version of libjxl you need

Now it also errors out on the latest git, but later...

So it kinda... helped? At least we're closer, I think...

the parameters taken in by EncodeFile seem to have changed

I would try to retrofit the existing data for the new function

The main issue with building anything past 0.5.0 was the missing libskcms

and i had already fixed a similar issue with the upgrade to 0.6.1

https://github.com/CanadianBaconBoi/squoosh/blob/fd6b17b9fe52fb45a976079f890c1ea21f6df089/codecs/jxl/enc/jxl_enc.cpp#L101

issue is at this line

are you trying to use revision `9f544641ec83f6abd9da598bdd08178ee8a003e0`? <@456226577798135808>

The new method signature is ```cxx Status EncodeFile(const CompressParams& cparams_orig, const CodecInOut* io, PassesEncoderState* passes_enc_state, PaddedBytes* compressed, const JxlCmsInterface& cms, AuxOut* aux_out, ThreadPool* pool) ```

so calling ```cxx EncodeFile(cparams, &io, &passes_enc_state, &bytes, /*aux=*/nullptr, pool_ptr) ``` inside of jxl_enc.cpp is now invalid

```cxx EncodeFile(cparams, &io, &passes_enc_state, &bytes, /*[[CMS]]=*/nullptr, /*aux=*/nullptr, pool_ptr) ``` Would be the new way to call it, of course assuming you have `cms` of type `JxlCmsInterface&`

because nullptr cannot be cast to JxlCmsInterface&

This snippet here is the type definition and is what needs to be passed to EncodeFile https://github.com/libjxl/libjxl/blob/a52d5784c673b1954e19bd1516e72aaba71a799a/lib/include/jxl/cms_interface.h#L133-L224

Oh

I found out how to do heh

One second, I'm going to try to build

turns out there is a default cms at `jxl::GetJxlCms()` inside of "lib/jxl/enc_color_management.h", so I'm just going to change the use of EncodeFile from ```EncodeFile(cparams, &io, &passes_enc_state, &bytes, /*aux=*/nullptr, pool_ptr)``` to ``` #include "lib/jxl/enc_color_management.h" ... EncodeFile(cparams, &io, &passes_enc_state, &bytes, /*cms=*/nullptr, /*aux=*/jxl::GetJxlCms(), pool_ptr) ```

It now builds

You may find these changes at https://github.com/CanadianBaconBoi/squoosh/ on the dev branch

Version supported is libjxl rev.9f544641ec83f6abd9da598bdd08178ee8a003e0 (aka current latest)

<:Smile:428375414847700993>

Tested, builds and works

HOOOOLYYYY SHIIIIIIT IT FUCKING WORKS NOW

AFTER MONTHS OF DESPAIR

https://github.com/GoogleChromeLabs/squoosh/pull/1136

I cherry-picked some of your commits to this PR's branch (as you can see in the link above) and did some Git magic in order to avoid unnecessary compiled version being stored and obscuring the history.

Don't worry, you still get the credit. GitHub shows "**CanadianBaconBoi** authored and **ziemek99** committed" because of those intermediate compiles being stripped, same in Git.

You can test the (hopefully final) version here. Check out "Alternative lossy mode" checkbox (which enables lossy Modular) and "Noise synthesis" slider (WHICH FINALLY WORKS IN BOTH MODES!) https://deploy-preview-1136--squoosh.netlify.app/

Alright, glad I could help out 😸

Wait, are you on Keybase?

Yes I am

So am I 😉

hehe

le followed

Hmm, when compiling the c(d)jxl_ng version (for Windows), not all the required libs are statically linked by default, like brotli (even in dev-auto builds) and Gflags

probably need to change the default for windows to do static linking then, dynamic linking is inconvenient in windows afaiu

And, as I already said, there is something wrong with the encoding speed in the official Windows builds

I've been abusing :jxl: today and have been testing out creating images with ludicrous dimensions. I noticed two things that may be issues, but I just want to check that they are in spec before I open any issues on GitHub. The first thing was that attempting to encode a one by one billion (10^9) pixel tall ppm image with cjxl immediately fails with the error ILLEGAL INSTRUCTION, pointing to line 94 of /lib/jxl/image.cc. This is different from the the case of a hundred million tall image, which try to encode it, and then gets killed after a while when it runs out of memory. I actually managed to get that image to encode with an effort of 1 and creating a 100GiB swapfile, but then it wouldn't decode, instead saying that it "Failed to decode to pixels." I managed to get a million pixel tall image to decode fine. I've attached the 100,000,000 pixel tall image below, so you can have a go at decoding it yourself.

All the images were created from ppm files that I handmade with dd.

interesting exercise, i'm sure you'll hit all kinds of implementation limitations

Its quite interesting watching how the memory usage varies throughout the encode process. This image was encoded with the default, so VarDCT. I'll have a go later with modular and see how that effects it.

probably atm fjxl can get the largest images encoded

Does fjxl support the container then, given that is required to go above level 5 of the specification?

it doesn't, it will just write a codestream that is technically not compliant until you put it in a container with a level 10 jxll box

but the libjxl decoder doesn't check the level anyway so it doesn't really matter atm

I'll give it a go then.

to get a large image decoded, it's probably best to use your own version of decode_oneshot, one that doesn't decode to float but to uint8, or even better, avoids the decode buffer and uses the pixel callback

I'll have a go at hacking that together. Also I'm going to need a bigger swapfile for cjxl modular e 1. ~130GiB is not enough memory, lol.

then if you do things in a single thread, if groups aren't permuted (which fjxl doesn't do), you should be able to decode strips of width x 256 and write them to disk without having it all in memory

cjxl modular is a mess

it converts the input first to 32-bit float, then to 32-bit int, then collects 64-bit tokens, so minimal memory must be something like 96 bits * number of channels * number of pixels

which is pretty clearly not the optimal thing to do, lol

I thought your estimate of only 12x raw size (on github) was a bit far from what I was seeing.

Ah well, something to optimise later.

In theory, I'd like to be able to get libjxl decoding an image of the full 2^40 pixels, just to prove it can be done. I'll need a lot more swap for that though, as its about 3 TB of data (assuming 3 channel 8 bit).

But decoding in in strips is definitely the way to go with that.

well 96 bits is 12x 8 bits — but that's just a lower bound, probably it uses memory for other stuff too

||*~~just buy 4 TB of RAM~~*|| <:HaDog:805390049033191445>

<@!794205442175402004> how do you feel about me implementing a wasm_extras directly into libjxl? currently there is no easy way of using libjxl without building ontop of it. it would only be built when using emscripten. my plan is to export a few common use case functions, such as decode and encode then slowly expanding it from there exposing more of the library.

I ask because I'm going to make it anyway and making all the extra files just to properly incorporate the library is annoying, and I could skip that step. also since libjxl currently doesn't export via emscripten anything on its own, building it as a standalone for the web is currently useless.

if you know how to do it, more than welcome I'd say

Agreed

excellent

for now im just going to export a quick and dirty solution, so i can test, and then as i go ill refine and make try to gear the build system to build only what's necessary

Not sure what the use cases for the wasm build really are tbh, besides squoosh... I guess polyfill? But I doubt it makes sense to do polyfill instead of using fallback jpg/png...

well currently me and <@!281115117884801025> are using it to convert jxl to png on the client

using a modified version of libsquoosh

that way we can serve only jxl and have all clients support it

so far the preformance isn't that bad for our application, roughly 400ms on desktop and 800-1000ms on a mid-ranged phone

which is fine, since we're serving only 1 jxl image per page, at most

do you know if that's with wasm-simd?

its without

my main issue with this method is, iv'e seen that jxl has a JXLToJPEGDecoder

libsquoosh doesn't do that

and ontop of that, it decodes directly into a float based buffer

so we can easily hit memory issues

mhhh I see - have to say we never tried to optimize for that in any way, so I wonder how much we could gain there

ah, right, I wrote that code before we had the pixel callback

im thinking of making the default decoder use just uint8 or uint16 buffers

and later on, making it dynamic to image size, if possible

the best thing would be using the pixel callback and writing to a uint8 buffer after calling skcms, I think

because after any given size a loss of quality isn't that dramatic

im hoping to avoid skcms

and returning the result as a text blob

ah you're encoding to PNG right?

probably, i have to dig around a bit more too see

but from what i know, browsers support blobs of png, jpeg and gif

with partial support for webp

then yes, 8bit uint buffers are probably good enough -- don't forget to pass the ICC to the (png/jpeg/...) encoder though!

yup

What are you using for png encode? If it's just to show the image, you could consider doing (almost) uncompressed png

Otherwise the png encode can be more expensive than jxl decode

uncompressed png

libsquoosh converts from RGBA_ffff to RGBA\_8888

before returning it

What is RGBA_ffff? 16-bit?

Ah it's an skcms format enum value, ok

0xf is 15 so that's confusing to me

no, currently libsquoosh converts using float buffers, then converts it 8-bit

then it just pushes the 8-bit data to the underlying ImageData class and returns that.

Ah the f is for float

yup

i would like to avoid this

Full float buffer is a bit large, yes

if you are transcoding to png that's easy yes

if you aren't, you need to use the pixel callback, but since you are... 😛

because not iterating over all the data, and clamping it would add a little bit of speed, and ontop of that ram is a big issue on mobile devices

i still don't know if i will decode to png or jpeg

as it stands i will try and take jpeg over png

because transcoding should be faster, then flat decoding

I mean also if you're transcoding to jpeg 😛

Pixel callback does it in smaller chunks, so you can get float precision to pass to color management and convert to display 8-bit yourself - but I dunno if you can tell what the displau space is

ill add that as a note, and look into it later

IIRC there's no colorspace support in canvas either way

for now I just want to get the build system set up, and the files included correctly

so "transcode to PNG and copy the ICC" is likely the safest bet

Yes

and then a basic decode func and encode func for the time being

We should get dithering in libjxl though, when decoding to 8-bit. Cannot do it at the application level when decoding to 8-bit...

pixel callback and dither there?

Yes, it can be done, but it's less convenient

Also: do we actually return wide gamut in the right colorspace when decoding to 8-bit? Or is it always returning sRGB in the 8-bit case?

no idea... I think right colorspace but not certain

i belive i have the fist working compile

however I had to do what i would call a hack to get emscriptons linker to work. if we update to cmake 3.13+ i could revert this however.

yep got the first part done, the build system can now export emscripton bindings

<@!794205442175402004> could this cause problems with any other builds

its only ran in an include file, which is then only included when JPEGXL_EMSCRIPTEN is true

also i had to disable -fno-rtti when building for wasm now, because emscripton wont allow bindings with it enabled

I have no clue, pinging <@811568887577444363> and <@179701849576833024> who know better than me

I think it should be fine

but not sure

got it working

took around 100ms on a 620x472 to png 8-bit rgba

having the thread fight over the decoder, seems to make 1 image decode roughly 400ms after the first

testimage2 is a 117 byte files, 1000x1000 generated during decode testimage1 is the original 620x472 that's just being decoded

so first time warm up is around 30-40ms

with the understanding that the webassembly is properly compiled after its first use

i'd say thats viable for realtime non-native decoding

I've made a fork, and will continue working on this tomorrow I'm a little burnt out. https://github.com/KoromaruKoruko/libjxl/commit/4b7d5955eb5baccca024f09450ba3af9302a10e4

mind some of the old comments, that seem meaningless to pointless.

will take a look on Tuesday

When I try to encode lossy modular with `-e9 -m -q 90` I get `[Modular, Q93.01, tortoise]` , and when I change -q to -Q I get `[Modular, Q90.00, tortoise]` . In varDCT mode both -q 90 and -Q 90 give me d1. Can someone explain the difference between the q's ? The help docs were unclear.

I suspect in vardct mode -Q anything will give you -d 1 (i.e. it's unused)

-Q applies only to modular, -q applies to both and tries to roughly match the equivalent libjpeg quality IIRC

You're right about -Q and vardct. I still don't understand why modular q is defined differently? does that mean modular Q93.01 matches vardct Q90 (which matches d1 and/or libjpeg q90)?

modular-Q is pretty unrelated to libjpeg-q

-q doesn't actually *do* anything, it just sets either -d or -Q

okay I think I get it, vardct doesn't have Q and Modular doesn't have d, so q tries to map the same quality to whichever method you use? Is there a reason modular doesn't have -d?

> Is there a reason modular doesn't have -d? Because Butteraugli isn't as much baked into Modular as it is into VarDCT (which literally revolves around it).

why isnt butteraugli baked into modular as it is into vardct

Because XYB, the color space Butteraugli operates in, is VarDCT's native color space.

Mostly because of historical reasons: vardct originates from pik, made by the same team that made butteraugli; modular originates from fuif/flif, which was originally made for just lossless (and that's still its main strength), so perceptual optimization was never really done with it

Modular's Q is just a quantization setting, no attempt is made to be visually consistent like in VarDCT's d

Though lossy modular does by default use XYB too now, so it might be somewhat perceptually optimized just by virtue of using that colorspace

much progress

much more to go though

<@!794205442175402004> do you have anything aginst me adding Getter Setter functions to most of the Structs, as emscripten doesn't seem to allow me to substitute the getter and setter, with any function outside of the actual struct itself. it likly depends on a thiscall.

its either, that, or I wrap almost all structs inside another struct. which shouldn't be that bad, but it isn't exactly the best. in short, it would slow down all calls from the js frontend. by effectively making each call ```js let val = MyClass.member ``` into ```c++ struct WasmMyClass : MyClass { decaltype(MyClass::member) member_Getter() { return this->member; } void member_Setter(decaltype(MyClass::member) value) { this->member = value; } } ```

which on that side, isn't bad, but pushing from c++ to js would require me to constantly cast from MyClass to WasmMyClass

which would make maintainability and creating of new structs extremely annoying.

can you use dynamic JS for this?

JS being a dynamic language could allow you to make that work

it's called ECMA6 Proxies

I don't know how that translates to WASM

yes, but then i would have to constantly translate between strict and soft typing

as in i consume emscripten::val on all inputs and push it on all outputs but then have to: manually ensure type safety. manually create constructors, and pesudo class representations. implement further error checking.

where as, I could delegate all of that to Embind. which would allow me to consume strictly typed values. and wouldn't have to provide pseudo representations.

it also means that embind would handle the type checks, and argument validity

Ah, that sounds like it's thoroughly in "not worth it" territory

even if you could let TS handle that

as well as conversions.

I don't mind, I can write up a few macros and quickly hammer it out in 1-3hours but it means future maintainability is botched

yea, that by itself makes it not worth it

and it would mean editing definitions in multiply files.