JPEG XL

how do i do that

you pass `-fsanitize=address`

in your CFLAGS/CXXFLAGS/LDFLAGS

(address for address sanitizer, memory for memory sanitizer, ...)

hmm i didnt do anything and it just works now

even though i was consistently getting those errors

ohhhh it may be because now im storing the input data

and it was being GC'd before when it stepped out a first time

ah yeah that could indeed give you issues

Congrats on releasing 0.6! 🥳

I would like to try out the lossy progressive/responsive capabilities of jpeg-xl. I looked through the API docs and can’t find anything in the Encoder section about this. I also looked at the source for cjxl but am unable to figure out how it connects the -p option to the API. Can someone point me in the right direction?

Correction - i want to try out the lossless progressive/responsive capabilities

not sure how much of that is exposed in the api yet

we're still in the progress of migrating cjxl/djxl to the api

currently they just call the encoder directly without using the api, so they can set params that aren't exposed in the api yet

(historically, cjxl/djxl are a lot older than the api)

Ahh ok that explains a lot of things thank you

Is it possible to do partial bit stream decoding right now via the API?

E.g. load 50% of the bytes and decode as much of the image as it can

yes, that is possible

you just give it a partial buffer and call Flush when it is requesting more bytes

https://github.com/libjxl/libjxl/pull/606 example code here

Thank you

FYI - I am creating my own WASM build and using it to test performance of lossless medical image compression. You can try out the test harness here: https://chafey.github.io/libjxl-js/test/browser

cool - are you involved in DICOM by any chance?

Yes, WG-04

Sent you an email this morning

ah lol hadn't catched up with my mail yet

regarding encode time for lossless: I suspect that for most medical images, e3 (falcon) should perform quite well

e3 doesn't do a good job at synthetic images, but for sensor data it is quite good and very fast compared to e > 3

regarding progressive: yes, for lossless it is likely not the best idea compared to j2k

for diagnostically lossless, it might be worthwhile to try something like `cjxl -m -C 1 -Q 95` (or some other Q setting) - that will automatically be progressive as a side effect, and since it's not DCT based, the loss can be done with relatively strong guarantees on the max pixel error

Wait - you mean diagnostically lossy?

Where are you seeing that?

This test harness is based on the jpeg-ls test harness so some ratification may still be in there

lossy in terms of pixels, but without impacting diagnosis so diagnostically lossless 🙂

Good catch ill fix that thanks

I mean just very high quality lossy, possibly with some mathematical guarantees of max per-pixel delta

Got it thanks

E3 is much faster without much increase in file size. It is still quite a bit slower than JPEG-LS and HTJ2K by about 4x though

How much room is there for optimizing then decoder?>

how are you measuring speed?

Wasm builds of openjpeg, openjph running in a browser

because wasm != native, and for native things do depend a bit on your platform

Sure - my main interest is wasm in the browser. So no threads and SIMD is a maybe

for accurate speed measurements, try `djxl input.jxl --num_reps=100 --num_threads=0` (if you want to try single-threaded speed)

How am I supposed to use parallel runners from the C API?

like this

https://libjxl.readthedocs.io/en/latest/api_threads.html#_CPPv429JxlThreadParallelRunnerCreatePK16JxlMemoryManager6size_t

It just says "use as the opaque runner"

which is ???

`JxlDecoderSetParallelRunner` requires both a `JxlParallelRunner` *and* an opaque `void *`

why?

i think oneshot_decode has an example of it

otherwise you can check the the many of my implementations

like the firefox one

`JxlThreadParallelRunnerMake` also says "See `JxlThreadParallelRunnerCreate` for details on the instance creation."

which itself is not documented

there are no details

but you would do `JxlDecoderSetParallelRunner(dec.get(), JxlThreadParallelRunner, runner.get());`

this is C

oh...

I'm using the C API

there's no `runner.get()`

how am I supposed to use them from the C api?

i mean, .get() was just for the smart pointer

but it returns a C++ class

which is not helpful in the C API

so for the pointer all you need is JxlThreadParallelRunnerCreate

sure, but what do I *do* with that?

https://libjxl.readthedocs.io/en/latest/api_decoder.html#_CPPv427JxlDecoderSetParallelRunnerP10JxlDecoder17JxlParallelRunnerPv requires two arguments

`JXL_EXPORT JxlDecoderStatus JxlDecoderSetParallelRunner(JxlDecoder *dec, JxlParallelRunner parallel_runner, void *parallel_runner_opaque)`

the second arg is a function pointer

you would do JxlDecoderSetParallelRunner(dec, JxlParallelRunner, runner)

is JxlParallelRunner provided by libjxl

or do I have to define one

you can use JxlThreadParallelRunner

so basically

i think just this ```void* dec; void* runner; JxlDecoderSetParallelRunner(dec, JxlThreadParallelRunner, runner)```

```c runner = JxlThreadParallelRunnerCreate(manager, 4); JxlDecoderSetParallelRunner(decoder, JxlThreadParallelRunner, runner); ```

so something like this?

yeah, well it's the same as in cpp

none of this is well documented

which is very frustrating

just stare at the code

for a couple of hours

that's what i did

^ that's not well documented

:)

but who's gonna document it amirite

well if the goal is adoption then someone should

Very true, can you file an issue?

(as a side note, using the ResizableParallelRunner can be more effective on lower-end devices)

Hey, I'm running cjxl 0.7.0 on windows and even at -e 1 it takes ages for compress one 306x299 image

lossless?

No

why? is an animation?

No

`--patches=0` doesn't help?

oh wow it does

what does this do ?

At -e 6 or lower, --patches=0 is default

Can you create an issue for this slow encoding image?

why would --patches=0 change anything at -e 1??

It shouldn't change anything

I already see fun in my future...

I really hope this is not windows-only...

Before posting an issue I'll reboot, god knows this sometimes fixes things on windows

Also check if you're maybe not using a debug msan build or something

It helped <:kekw:758892021191934033>

I hate windows so much

why does libjxl use cpuid asm instead of querying the os for non-mac, non-haiku systems? is the idea that asm is portable cross-os (more or less) and not portable cross-arch, whereas os queries are portable cross-arch and not cross-os?

I assume it's because it needs to know the exact simd instruction set, not whatever abstraction the OS provides?

> is the idea that asm is portable cross-os (more or less) and not portable cross-arch this is correct, unless the asm needs to make a syscall (which it'd probably do just by delegating to a function written in c) it's entirely portable cross-os

er, i dropped this: "for topology detection"

<@!794205442175402004> i don't think libjxl uses any asm other than that though? it's all through highway, or at least that would be the proper implementation (layering violation etc)

Topology detection, probably that shouldn't really be part of libjxl either, since I guess it is only used to pick some default number of threads

actually, on that train of thought, why does libjxl try to ignore hyperthreading anyways

I know very little about those lowlevel perf things

<@806098177983643658> knows all about that

Also <@179701849576833024> and <@456226577798135808> know more about it than me

first - it's not libjxl, but the tools, which makes it make slightly more sense

tbh I don't really think we should be doing anything else but `std::hardware_concurrency` for # of threads

ah, yes, i wasn't so clear there. i meant it is in the libjxl repository :p

but HT doesn't always help (in particular it was actively reducing performance on our workstations, and in other systems the improvement was marginal) so we went with that

hm, i'm surprised that it would reduce performance. in theory i guess it's supposed to be at worst neutral (if you ignore synchronization?)

ehhhh it's complicated

interactions with memory bandwidth are hard

and synchronization, and licenses, and thermals, and cache, and...

but I really think we just ought to default to whatever std::hardware_concurrency says

if you feel like measuring performance on your system and opening a bug it might help...

Probably things will even not necessarily be the same between vardct decode and modular decode in terms of where the bottlenecks are

(I mean with `--num_threads=` with/without HT cores)

i think for linux it would be nice to do sched_getaffinity, since it's quite common to run docker/lxc with limited cpus

i guess there is also a question of numa, but hopefully anyone with a real numa system knows how to handle it themselves

what kind of workstation did you experience performance reduction on?

Hey, Is there any ways to speed up the encoding at the cost of compression without hurting quality ?

I'm running a generation loss test

eh not really

not at the current state of things at least, and unless you're willing to poke at the code

(also the non-quality-affecting part is a small fraction of the runtime, so...)

1. Enable `-march=native -O3` at build time. It provides an almost negligent, but consistent speed boost. I've never tried LTO with CJXL, so 🤷 2. If you have many images, you can dedicate 1 thread per image to reduce CPU-time as much as possible.

already doing this, also when testing generation loss I can't really do things in parallel

shouldn't you test multiple sample images and not just one?

I could

But then I'm just running different scripts

also, since you said you are using windows, a program linking against libjxl will probably be much faster than a batch script

I'm running this on linux, the windows issue is unrelated

Generation loss is likely going to be somewhat different at different encoder speed settings too

ah. could still be worth it to try, but linux process creation is pretty fast for small programs

At e3, vardct jxl is basically just jpeg in XYB

True, I have no idea if I can even do this in powershell or whatever scripting environment I know how to use

Ah, so should I run -e 4 to get a more "jpeg xl"y result ?

wait what the hell

-e 4 is faster than -e 1

For lossy, it could be that e<3 is broken

Does jxl can encode an animation with flac audio

I don't think so

If something includes audio, then it's a video.

~~Cursed~~

There might be some way to put jxl as the visual stream inside of a container like MKV, but at that point you have a video.

it would still be faster on Linux too - there is some nontrivial initialization going on in the first encode in a process

Well its not too slow, I'm at 44,000 out of 100,000 iterations right now

This is so dumb the original image is already super compressed

that's a big number 😛

its for a meme

not even a good one

What kind of iterations?

How are you varying encode parameters?

The lazy way `$q = Get-Random -Maximum 97 -Minimum 93`

you can read it but please close your eyes ```powershell $framerate = 60 $refreshrate = 10 "WEBVTT`n`n" > loss.vtt ffmpeg -y -i image0-24.png "imgs/1.png" $q = Get-Random -Maximum 97 -Minimum 93 for ($i = 2; $i -le 100000; $i++) { $j = $i-1 # ffmpeg -hide_banner -v error -y -i "H:\loss\$j.webp" -metadata q=$q -q:v $q "H:\loss\$i.webp" cjxl "imgs/$j.png" -q $q -e 4 "imgs/$j.jxl" djxl "imgs/$j.jxl" "imgs/$i.png" $g = "$i".PadLeft(6, '_') if ($i%$refreshrate -eq 0) { $t = [timespan]::fromseconds($i/$framerate) $nt = $t.Add([timespan]::fromseconds($refreshrate/$framerate)) $h = "$($t.hours)".PadLeft(2, '0') $m = "$($t.minutes)".PadLeft(2, '0') $s = "$($t.seconds)".PadLeft(2, '0') $ms = "$($t.Milliseconds)".PadLeft(3, '0') $nh = "$($nt.hours)".PadLeft(2, '0') $nm = "$($nt.minutes)".PadLeft(2, '0') $ns = "$($nt.seconds)".PadLeft(2, '0') $nms = "$($nt.Milliseconds)".PadLeft(3, '0') "$h`:$m`:$s.$ms --> $nh`:$nm`:$ns.$nms`nGeneration : $g`nQ : $q`n" >> loss.vtt Write-Output "$g $q | $h`:$m`:$s.$ms --> $nh`:$nm`:$ns.$nms" $q = Get-Random -Maximum 97 -Minimum 93 } else { Write-Output "$g $q" } } ffmpeg -y -r $framerate -i "imgs/%d.png" -vf "subtitles=loss.vtt:force_style='Fontname=Sydnie,Fontsize=10,Alignment=5'" -crf 32 -r $framerate loss_captions.webm ```

Random is fine, if you compare multiple codecs just make sure the range is similar (bpp of a fresh encode at min and at max is similar in all codecs), and the number of effectively different settings is also not too different (e.g. some codecs take integer q settings and others float; if there are only 3 effectively different params in the range then it's "easier" to resist generation loss than if there are 3000)

Also, decoding to 16-bit png is a bit more representative of what would happen if you e.g. do a transcode with a default imagemagick (which would have 16-bit internal precision)

Ahh, yeah

I guess I could select a random float between 0 and 1 and then multiply it to whatever max Q value an encoder accepts

What I mean is percentages kekw

Huh, after the first few thousand iterations it sort of settles and doesn't get much more deteriorated

That's nice, if it reaches a somewhat idempotent state

i did a quick benchmark of cjxl -e 1..9 --num_threads=0,1,nproc/2,nproc with both jpeg reconstruction and jpeg to pixels on my intel somethingsomething laptop and ryzen 1600 desktop, and it looks like HT is 5-10% faster but uses twice the cpu. is it really that heavy on memory bandwidth?

i guess i should check perf stat, i only looked at perf report so far (about the same %s for both, more HT spends a little more time in malloc)

"50.31% backend cycles idle" well i'm not a cpu optimization pro but that sounds bad

I think things might be a bit different if we would use more 16-bit buffers and less 32-bit ones

that was for 6/12, 12/12 is 37.35% backend cycles idle. so for my machine too, it's all waiting on ram

hm, does that mean that running 12 threads on one image will actually be faster than 12 images at once, because the cache will be hotter? idk anything about libjxl internals or really that much about modern image compression in general beyond "something something DCT blocks delete high frequency components something"

and also, is it possible to speed this up with some scheduler tricks, like putting threads processing the same parts of the image on HT siblings?

A typical worker thread will be working on a 256x256 pixel region

Likely scheduling horizontally adjacent groups on the same HT siblings would be a good idea for cache reasons

I think

Though it probably depends on whether you do decode to full float buffer or do an optimized case to decode to uint8 or to pixel callback

djxl uses full float buffer

Firefox uses uint8 buffer iirc

Chrome uses pixel callback

These will all behave a bit differently, I expect

I think that's because we filled up the execution units of the CPU, but not certain - anyway HT likely improves the total # of backend cycles that get executed

our measurements come from (a) older versions (b) decoding and (c) 28-core CPUs, so the results may be different there... if I run decoding on my 32-core threadripper, I see speed stops to increase even before 32 cores IIRC, lets' not even mention 64, but on my laptop HT definitely helps

would you be willing to file a bug with your findings?

sure. i

'll take a look at decoding first

thanks 😄

i think even if HT is faster, it might still be better to skip it because then the user can run some other programs at the same time

that's an argument for not doing MT at all by default 🙂

HT makes JXL decoding aprox. 10% faster on my laptop. Not using HT cores won't allow other process to use it. HT works only inside one process, isn't it?

no no

to the OS HT is not different at all from just another core

although linux 5.15 will have core scheduling for doing it as you describe. it will be optional due to resulting significant performance drop for some workloads

well i think it depends on how much the speedup is? e.g. if HT can double encoding speed, then maybe i want to prioritize that, but if it is only a 10% increase then maybe i want to prioritize other programs. or maybe i really want jxl to be fast and the 10% is worth it even if it slows everything else down. unfortunately i don't think there is a programmatic way to determine this preference

if there's a system() function for calling the system, why isn't there a user() function for calling the user

that's what argv[] is for, no?

JXL with Parallel Runner has similar decoding speed as single frame 10bit AVIF YUV444. That's good. Unfortunately, I will probably avoid the runner for stability reasons, performance of my plug-in will drop significantly. JXL in Google Chrome is also slow, they use single thread JXL for the same reason?

I don't know why chrome uses single thread, maybe it's convenient in their architecture to do it like that?

could be seccomp

I think it's more that we never got to implementing multithreading 😛

> performance of my plug-in will drop significantly <@!886264098298413078> How bad is it in numbers?

20% to 100% increase in decoding time, it depends on image. In some apps you will not notice because of various parallel procedures and/or pre-loading.

I have a bunch of 150 MP images, so that could be hurtful, I guess. Maybe I should stick with v0.3.0 for now.

I think we are looking into the issues you might have found - and please file bugs for any new ones 😛

if i wanted to deconstruct a jxl file (lets say it's just 1 frame) into all pieces required to reconstitute it, would it be sufficient to read the toc & partition the bytestream according to those offsets?

or is it more involved than that to split it up?

Not sure if I understand what you want to do

Those are indeed the 'chunks' that can be decoded in parallel (they each start their own ANS stream etc)

The decoder still needs to know which one it is (it knows that from its position in the toc), and there are dependencies, e.g. the AcGlobal group has info that all the AC groups need, and AC groups can come in multiple passes, and they also need the decoded data from the DC group they are part of.

ah, was just curious if my understanding was correct: if i have offsets + size of: -the header -the toc -all sections -whatever is left after the last section if i could implement a paused + serializable + restartable decoder

I suppose so, maybe depending on what exactly you mean by those things

Maybe as a proof of concept we should make a simple chunked encoder that can encode gigapixel images without needing huge memory

And then also a cropped decoder that can decode regions of interest without having to decode the full image

As well as a chunked decoder that decodes the full image but does so one tile at a time and uses bounded memory regardless of the image dimensions

that would be awesomee!!

I need that.

does cjxl do its own processing with the sensor information in png images? When i convert a png image to jxl with sensor imformation the output i get is completely different brightness and saturation wise.

cjxl uses the color profile of the input

Or assumes sRGB if there is none

Likely your png viewer does something different (ignores the color profile, or assumes pixels are in display space if there is no profile)

im viewing both via the same viewer in this case imageglass on windows

discord embeded looks to be somewhere in between lol

They look the same to me in Chrome.

Same for me in Edge, but I see a difference in explorer or the windows photos app depending on if I decode to PNG or JPG

ahh so it does vary viewer to viewer. So i guess it would be better for me to no include the senseor information or atleast not the color profile that way its consistent? I guess the question is does it look super dark for you <@!263300458888691714> or is it bright and noisy

I see the output on the right

I see closer to right as well

yeah im a skip the sensor information copy in my post processing just so the results are consistent across all viewers

Not too shabby

without the super resolution

Is compiling for x86 different from x64? Used vcpkg+VS2019 instructions, and replaced x64 with x86. It complains about `libjxl\lib\profiler\tsc_timer.h(107,17): error : use of undeclared identifier 'CLOCK_MONOTONIC'`

On a technical level, yes, but I don't know enough about C compilation to know if that's related

Thanks to who put more work into the docs

but you removed the reference in the docs to `#include <jxl/thread_parallel_runner.h>`

so I had to hunt for it

I figured it wasn't needed anymore cause it was gone, but it still is

also I appear to have a hard time linking it now

What is super resolution? Is it a upscaling algorithm?

superresolution is just a fancy name for fancy upscaling, yes

(I suppose it kind of implies that it's doing more than just a simple upsampling filter but there is something more advanced being done, like AI)

who tried this? luigi311?

Yup upscaling using AI with the algorithm ESPCN

Yes sir

``` 898/898 Testing: conformance_tooling_test 898/898 Test: conformance_tooling_test Command: "/usr/bin/bash" "/home/anon/.cache/yay/libjxl-git/src/libjxl/tools/conformance/tooling_test.sh" "/home/anon/.cache/yay/libjxl-git/src/build" Directory: /home/anon/.cache/yay/libjxl-git/src/build/tools/conformance "conformance_tooling_test" start time: Oct 20 17:54 EEST Output: ---------------------------------------------------------- + CLEANUP_FILES=() + trap 'retcode=$?; { set +x; } 2>/dev/null; cleanup' INT TERM EXIT + main /home/anon/.cache/yay/libjxl-git/src/build ++ mktemp -d + local tmpdir=/tmp/tmp.KzdrmODgd3 + CLEANUP_FILES+=("${tmpdir}") + python3 -c 'import numpy' + local build_dir=/home/anon/.cache/yay/libjxl-git/src/build + [[ -z /home/anon/.cache/yay/libjxl-git/src/build ]] + local decoder=/home/anon/.cache/yay/libjxl-git/src/build/tools/conformance/djxl_conformance + /home/anon/.cache/yay/libjxl-git/src/libjxl/tools/conformance/generator.py --decoder=/home/anon/.cache/yay/libjxl-git/src/build/tools/conformance/djxl_conformance --output=/tmp/tmp.KzdrmODgd3 /home/anon/.cache/yay/libjxl-git/src/libjxl/tools/conformance/../../third_party/testdata/jxl/blending/cropped_traffic_light.jxl usage: generator.py [-h] --decoder DECODER --output DIR --peak_error PEAK_ERROR --rmse RMSE JXL [JXL ...] generator.py: error: the following arguments are required: --peak_error, --rmse + retcode=2 <end of output> Test time = 0.31 sec ---------------------------------------------------------- Test Failed. "conformance_tooling_test" end time: Oct 20 17:54 EEST "conformance_tooling_test" time elapsed: 00:00:00 ---------------------------------------------------------- End testing: Oct 20 17:54 EEST ```

test failin

<https://github.com/libjxl/libjxl/issues/758> plz fex

``` cjxl 0.jpg -j JPEG XL encoder v0.7.0 0c3c093 [SSE4] ./lib/extras/packed_image_convert.cc:125: JXL_ASSERT: io->metadata.m.color_encoding.IsGray() == (frame.color.format.num_channels <= 2) ```

Can't encode these images

Works fine in 0.6.

So, I assume that something was broken after

Works fine on 0.7.0

What commit?

can you open a bug?

Sure

I have old one. cdd3ae6

I think I found the commit ``` cjxl 0.jpg -j JPEG XL encoder v0.7.0 c2266c4 [SSE4,Scalar] No output file specified. Encoding will be performed, but the result will be discarded. Encoding [Container | VarDCT, d1.000, squirrel | 14-byte Exif], 4 threads. Compressed to 1842485 bytes (2.368 bpp). cjxl2 0.jpg -j JPEG XL encoder v0.7.0 86eed13 [SSE4,Scalar] D:\a\libjxl\libjxl\lib\extras\packed_image_convert.cc:125: JXL_ASSERT: io->metadata.m.color_encoding.IsGray() == (frame.color.format.num_channels <= 2) ```

It's all here https://github.com/libjxl/libjxl/issues/764

ah

that one

yay...

Seems like any colorful jpeg after `jpegtran -grayscale` will produce this error

> >>also probe still fails > >>Failure of jpegxl_pipe probing code with score=51 type=0 p=6B0 size=32 > >What file causes it to fail? > Look at tools/probetest.c its just 3 pages of code. > A feature to dump the failing data to a file would likely be usefull > to others too, if you have time to add that. Thanks, michaelni

<:Thonk:805904896879493180>

Added this to the issue

New commits in v0.6.x branch mean that 0.6.1 is coming?

likely 🙂

would you ever consider adding a jpeg xl format description to kaitai struct? https://kaitai.io

that's... huh... probably a significant undertaking

That's an interesting thing...

Released!

Is there a reason JPEGXL_MAJOR_VERSION JPEGXL_MINOR_VERSION and JPEGXL_PATCH_VERSION are not exposed in an installed jxl_version.h file (or is there another way for code depending on libjxl to cope with the current frequent API changes) ?

you're supposed to call JxlDecoderVersion / JxlEncoderVersion

That's not accessible at compile time

getting it from the .h would only work at compile time, which doesn't help if people upgrade/downgrade their libjxl version

I suppose for the major version we should have something in the .h file, in case you want code to compile for different APIs

For example JxlEncoderOptionsSetInteger was recently added, however at compile time I don't know if I can actually use it as I have no way to now if the installed libjxl is 0.7+ or not

yes, in 0.x the API is still unstable so that's kind of annoying

What's worse is I can't even print out a warning message saying you need to install v0.7+

could you maybe open an issue about this and ping deymo and lode in it?

it's probably something that should be discussed and we need to find a good approach

It would be good to have version number in .h so preprocessor can use #if conditional compilation libavif has it and I can make code which builds across multiple versions.

I understand once 1.0 is out this theoretically becomes a non issue. But in practice incompatible API signatures are pushed, or new functions are added and that needs to be known at compile time

I'll open an issue/pr on github with a proposal to generate a jxl_version.h from a jxl_version.h.in

I suppose even after 1.0 we might still want to add new functions and do other non ABI-breaking stuff

but we need to think about what things should be tested at compile time and what things at runtime, and how to avoid the problem that application devs might test everything at compile time and then there might be unnecessarily strict library version dependencies for packagers

thanks for the insights, I'll submit to github tomorrow as it's now kid's pickup time

I noticed libjxl always tries to clone submodules

is there any way to make it just use system brotli, for example, and skip cloning it?

Hello, where can i find a very simple exemple in c to compresse a image (a char RGB) in jpeg XL?

https://github.com/libjxl/libjxl/blob/main/examples/encode_oneshot.cc

That one is for float RGB, but uint8 is pretty similar

thanks

this is a C++ example

someone posted this to HN and it is getting some comments https://news.ycombinator.com/item?id=29197083 btw: the document has public suggestions turned on... so maybe turn that off for now... getting defaced...

Turning off public suggestions also makes it impossible for ppl to sign - I wish there was an option to only allow non-anonymous comments...

IMHO <#794206087879852106> channel would be more suitable for such things in the future (since it's not directly related to libjxl and its technical issues), but thanks! And thankfully no one has defaced this letter... yet.

Another GitLab issue that can be closed, I've just verified it that it's fixed by a recent PR! 😃 https://gitlab.com/wg1/jpeg-xl/-/issues/212

By the way is there any tag in <:JXL:805850130203934781> to mark a file as 360° (since it's render-impacting data) or do we have to resort to Exif (like in good old JPEG)?

360 is signaled in JUMBF I think, and yes it is not quite following our philosophy that it is not codestream-signalled, but we don't want to force all viewers to be able to handle that...

(since it is not something like orientation that the decoder can hide, but it requires extra user interaction options)

Yeah, it'd be a bit problematic for a decoder to be able to support decoding e.g. user-selected crops, because that'd require implementing actual 3D sphere → 2D plane converter. Like if there wasn't enough math and logic there already. You've got a point...

JUMBF is how 360 jpegs are signalled afaiu, and adding JUMBF to a jxl is just a matter of adding a `jumb` box to the container

re: this message

https://discord.com/channels/794206087879852103/848189884614705192/908649772771078154

I also get about 3M "possibly lost" when I encode a JXL

`possibly lost: 3,158,336 bytes in 1 blocks`

I get the *exact* same amount lost when I `djxl`

`possibly lost: 3,158,336 bytes in 1 blocks`

`lenna.png` is 512x512 3-byte RGB

`512 * 512 * 3 * 4 = 3145728`, which is only 12608, difference, or `64*197`

which leads me to believe that some buffer is being leaked here

``` ==92833== 3,158,336 bytes in 1 blocks are possibly lost in loss record 4 of 4 ==92833== at 0x483E7C5: malloc (vg_replace_malloc.c:380) ==92833== by 0x459607: hwy::AllocateAlignedBytes(unsigned long, void* (*)(void*, unsigned long), void*) (third_party/highway/hwy/aligned_allocator.cc:77) ==92833== by 0x1F0D01: MakeUniqueAligned<DefaultMatrices> (third_party/highway/hwy/aligned_allocator.h:108) ==92833== by 0x1F0D01: jxl::DequantMatrices::Compute() (lib/jxl/quant_weights.cc:1146) ==92833== by 0x124CDD: jxl::DequantMatrices::DequantMatrices() (lib/jxl/quant_weights.h:384) ==92833== by 0x124259: jxl::PassesSharedState::PassesSharedState() (lib/jxl/passes_state.h:37) ==92833== by 0x122FF4: PassesDecoderState (lib/jxl/dec_cache.h:31) ==92833== by 0x122FF4: jxl::DecodeFile(jxl::DecompressParams const&, jxl::Span<unsigned char const>, jxl::CodecInOut*, jxl::ThreadPool*) (lib/jxl/dec_file.cc:137) ==92833== by 0x119251: jpegxl::tools::DecompressJxlToPixels(jxl::Span<unsigned char const>, jxl::DecompressParams const&, jxl::ThreadPool*, jxl::CodecInOut*, jpegxl::tools::SpeedStats*) (tools/djxl.cc:178) ==92833== by 0x116C1E: DecompressMain (tools/djxl_main.cc:164) ==92833== by 0x116C1E: main (tools/djxl_main.cc:197) ```

this is what valgrind reports

is this just a bug in highway?

I think it's the default quant matrices which get computed when initializing the library and they never get freed

Dequant matrices get kind of big for big transforms: dct256x256 has 64k coeffs, so that's 256 kb worth of dequant constants already

And I suppose we have 3 such tables per transform (for x, y and b)

We probably shouldn't precompute the ones for bigger than 64x64, just compute those only when needed (which currently is never, since the encoder does not use those)

I guess I've just found a *de facto* standard for that sort of thing... https://developers.google.com/streetview/spherical-metadata

...which turns out to be the standard used by a bunch of manufacturers, like Google (GCam panorama and 360°), Samsung (panorama) and Nikon KeyMission 360°. I know because I've just checked them all in ExifToolGUI.

Is there anyone that actually uses official JPEG 360 (ISO/IEC 19566-6)?

No idea

I shouldn't have gone to sleep keeping suggestions open, lol

The document had become similar to the '90s website rotten.com

Might be best to close suggestions for a while.

That's what I did.

FWIW, the couple of times I've made an open letter, I've had good success with creating a GitHub repo with just a README. Then people add their names as a pull request. That's enough of a barrier to dissuade vandals.

Ah, that would work. Now they have to request access to the doc, that also works

hello

i would like to add libjxl to our toolkit, so I play a bit with the API, and more preciselt with jxlinfo.c example that is in the git repo

i've looked at the jxlinfo.c example and i have a question about the infinite loop afaiu, the infinite loop is to load more image data to get basic info (because fread() is used)

but if i have the whole file which is already mmap'ed in memory, there is no infinite loop to do, right ?

the infinite loop is also because there might be more than one frame, and jxlinfo gives info on all frames

hooo, ok

like for animated file, i guess

thank you

Yes, like for animated file, but also a non-animated one with multiple layers.

For those, the current decode api only returns one frame atm - though I am trying to add a non-coalesced decode option

if the jxl image is in grayscale, can libjxl render the image in RGBA, or must I do it ?

i think that's the only supported conversion

The decoder will turn gray into RGB and add a trivial A channel if needed

and how canI add this A channel ? The toolkit manages only BGRA colorspace

you mean when encoding?

i noticed that converting a jpeg with --strip -d 0 (not -j) then decoding it to ppm produces a slightly different result from libjpeg-turbo djpeg. is the jbrd actually storing some image data, or is the difference due to different IDCT implementations?

Isn't -d 0 just jxl lossless mode?

i think thats default on jpeg without -j

is different way of quantization jxl uses float32 when you see an image on you pc

anyways yes different (more precise) idct impl

and along those lines, why does libjxl need the jbrd to reconstruct a jpeg? why can't it make a jpeg using the image data (but obviously with different segments)

but on smatphone they use idct fast

but is not implemented this at momenet

is fo arm achitectue

is jbrd actually required or is this feature just not implemented yet

i think not required

idct is only if you do decoding on djxl arm

and not sure for lossless jpg transcode

``` --jpeg_transcode_disable_cfl Disable CFL for lossless JPEG recompression ``` i think this is this

also dont listen to anything fab says

for lossless jpg transocde on x 86 the only thing that exists is lossless vardct tanscode

so based on eight pe eight

8x8

ah. no. actually `--strip` already excludes reconstruction data

``` --strip Do not encode using container format (strips Exif/XMP/JPEG bitstream reconstruction data) ```

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

irrelevant.

yes because he had a lossless error with a comparison

What about exif and other meta data?

honestly i have not exif in my jxls images maybe i encoded too ealy i lost all metadata

o maybe the viewe don't ead them

i heard nomacs is capable to read them but not sure

but i don't advice nomacs to watch jxl

i wonder, who actually prefers the exponent notation for max bytes in use?

jbrd is required if you want to get the exact same jpeg file. If you only want to have _some_ jpeg file that has the same image data, we could do that without jbrd, but we haven't implemented that (yet). All the actual image data (including the icc profile and exif orientation) is in the jxl codestream, the jbrd only contains things like the scan script, the huffman tables, restart markers, app markers without render impact, padding bits, etc.

I would prefer a pretty printed 1853 KB, 45.87 MB, 1.23 GB etc, but I don't care enough about it to implement that

mm. thanks

as highway is out, will we see a new libjxl release soon ?

what are the pro and cons of skcms and LCMS2 regarding libjxl ?

Afaik, skcms is faster and lcms2 tends to be system-installed

Maybe there are other pros and cons, <@604964375924834314> do you know?

also, i have seen in decode_oneshot.cc, or in the gdk pixbuf plugin, that the FLOAT pixel format is used. Why not using an integer format ?

Float is more useful for hdr and wide gamut

Int means you have to use a transfer curve, and you cannot have out-of-range values so gamut clipping is happening implicitly

also useful for a toolkit ?

If you're going to display the image (i.e. still have to convert it to display space), having things in float linear rgb is slightly more efficient and more accurate than having it in e.g. 8-bit ints

ok, thanks

sorry, i have other questions...

in decode_oneshot.cc, why isn't the decoding done in JXL_DEC_FULL_IMAGE ?

the doc says that in JXL_DEC_FULL_IMAGE indicates that the full frame is decoded

yes, if you want the first frame, you could stop at that point

decode_oneshot decodes all frames and shows the last frame

and for an animated jxl, where should I decode the frame ?

note that there is a jxl file in github repo which seems to be animated, but there is only 1 frame...

which one?

anyway, JXL_DEC_FULL_IMAGE happens for every animation frame

https://github.com/libjxl/libjxl/blob/ec30ce72cdb7e4d05e204ff20ed824b00bc9fda1/doc/color_management.md#cms-library says that "The other popular open-source CMS is LittleCMS. It is also used by color-managed editors (Krita/darktable), which increases the chances of interoperability. However, LCMS has race conditions and overflow issues that prevent fuzzing. We will later switch to the newer skcms. Note that this library does not intend to support multiProcessElements, so HDR transfer functions cannot be represented accurately. Thus in the long term, we will probably migrate away from ICC profiles entirely."

what if you decode to 24bit packed rgb

not ppm

then sha1sum it

that's what I do

I run `convert imagefile RGBA:- | sha384sum - | xxd -r -p | base64`

you'll get different results with different jpeg decoders

`djpeg -dct int` and `djpeg -dct fast` and `djpeg -dct float` all produce different results and they're likely all conforming decoders

libjxl produces slightly different results compared to default libjpeg-turbo, mostly because 1) it has a different DCT implementation (float, and different from libjpeg-turbo's) 2) in 4:4:4 jpegs, chroma from luma can be used, which leads to somewhat different dequantization 3) DC dequantization is fancier in jxl than in libjpeg-turbo 4) upsampling and YCbCr to RGB is done with floats (instead of doing everything with 8-bit ints like in libjpeg-turbo, which creates more rounding error), conversion to int is only done at the very end

<@!794205442175402004> cropped_traffic_light.jxl <-- info.have_animation is true

And isn't that an actual animation?

<@!794205442175402004> tps: 100/1

num loops: 0

time codes: 0

that's what my program detects

<@!794205442175402004> it does not seem to be an animated files if num loops is 0

Num loops 0 means infinite looping

but how many frames are they ?

imho, there should be both the number of frames and a bool to say if it's infinite

<@!794205442175402004> what do you think of this ?

i've openedan issue for this

The number of frames is not signaled

The number of loops is for feature parity with gif/apng/awebp

Can non-core-devs review PRs like this? https://github.com/libjxl/libjxl/pull/866

(it's just been merged, but I'm asking for the future)

Woooooow, that's **a handful** of merged PRs, thanks <@!532010383041363969>! 😃

Anyone can review pull requests and input from anyone is welcome

But it needs approval from someone who has write access and other than the one who opened it

tried to get some issues and pull requests closed today since we had over 100 open issues and over 40 open pull requests

still quite a lot to go

Legend

Such changes are most welcome!

wondering whether https://gitlab.com/wg1/jpeg-xl/-/issues/215 and https://gitlab.com/wg1/jpeg-xl/-/issues/216 have been fixed

could test but lazy

If someone can test, that would be good (if it's gone, we can close the gitlab issue, if it's still a problem, best to open a github issue for it too, so we don't forget about it)

in decode_oneshot.cc, in JXL_DEC_NEED_IMAGE_OUT_BUFFER event, I can see : if (buffer_size != *xsize * *ysize * 16). Why *16 and not *4 ?

nvm, it's because of float in format

i'm still trying to understand the api and other feature. In gdkpixbuf plugin, it seems that they use a float pixel format, then set a callback, and in that callback, uses skcms to convert float pixel format to bgra, using skcms_Transform

what is the difference between doing so, and using JXL_TYPE_UINT8 in pixel format ?

is there a difference in quality ?

or in speed ?

The difference is that you can do color management and have wide gamut

If you immediately get uint8 from libjxl (which is an option and could be good enough), then if the image colorspace and display colorspace don't match, you lose precision

In terms of speed, it depends on the platform: on ARM we have fast paths to produce uint8 output so that will be faster; on x64 probably the float callback is fastest

<@!794205442175402004> so i should follow what the gdk pixbuf code does ?

(for the toolkit)

That's certainly an option

actually, gdk is more or less like our toolkit

actually, i want the best option

🙂

our colorspace is BGRA

<@!794205442175402004> so, is there a better option ?

Not really, afaik. What are the main use cases for your toolkit?

<@!794205442175402004> it's the EFL, similar to QT or GTK

i want my pet project ( simple image viewer written with the EFL) to support jxl files

Then it's probably a good idea to follow the gdk-pixbuf example, yes

<@!794205442175402004> thank you

<@!794205442175402004> do you know if there will be a release of libjxl soon ?

I think it might take a while, it could be that the next release will be immediately a 0.99 or 1.0rc1, but we're not there yet

ok

<@!794205442175402004> there is still this problem of lcms2/skcms

<@!794205442175402004> is it possible to know, at runtime, if lcms2 or skcms is used ?

By whom?

Libjxl itself uses neither

with a libjxl API

Cjxl/djxl can be compiled with either

You can just pick one and use it

ho, the cms libraries are not linked against libjxl ?

No, libjxl does not use cms, it has its own limited cms to synthesize icc profiles and do conversions between enum colorspaces, but it does not do arbitrary icc conversions itself

(we try to keep dependencies minimal in libjxl)

We may at some point add a highlevel layer around libjxl that does link to a cms so you get an api where you can pass arbitrary colorspace input to the encoder and get arbitrary output from the decoder (i.e. not just "preferred" colorspace but just a guarantee that you get what you ask for)

But atm we only have the lowlevel api where the application gets pixels and an icc profile and has to do its own conversion

<@!794205442175402004> and having the less dep for such a library is good, imho

it's the most flexible approach, e.g. in chrome they are already using skcms so it would be bad if libjxl would introduce a dependency on lcms2, while in many linux distros lcms2 is already system-available so it makes sense to depend on that there for cjxl/djxl.

it'snormal, skia is now a google thing

is it possible to split jave wrapper outside libjxl tree ?

I know some people, especially archlinux ones, that are reluctant to install libjxl because it installs java stuff

That's optional, no?

If there's no compile flag to disable that, then such a flag should be added

but archlinux packagers always install everything

https://github.com/archlinux/svntogit-community/blob/packages/libjxl/trunk/PKGBUILD#L13

I think from a packaging pov, the stuff in the libjxl repo has to be split in multiple packages, e.g. libjxl, libjxl-debug, libjxl-dev, jxl-tools (cjxl, djxl), jxl-extra-tools (benchmark_xl, jxl_from_tree, etc), one for each plugin, etc.

unfortunately, it's not the way the packagers in archlinux are following

it would be nice if highway dependency could be dropped

doing like libjpeg-turbo

i'm still wondering what I have to do in the JXL_DEC_FULL_IMAGE event

if i'm not mistaken, i should call JxlDecoderSetImageOutBuffer in the JXL_DEC_NEED_IMAGE_OUT_BUFFER event

but in the JXL_DEC_FULL_IMAGE event, I don't know, especially for animated jxl files