JPEG XL

it did

... why did GH merge it then

they're not listed as required

here's the history on the OOB merge

ah, I wonder why they run then

fwiw the thing that fixed the msvc builds broke clang builds

the problem is that msvc requires a lambda campture

but clang is fine

``` /home/runner/work/libjxl/libjxl/lib/jxl/enc_icc_codec.cc:240:37: error: lambda capture 'kSizeLimit' is not required to be captured for this use [-Werror,-Wunused-lambda-capture] const auto tag_sane = [&tagsize, &kSizeLimit]() { ```

and we have `-Werror=unused-lambda-capture`

this is the problem with Werror IMO

you don't have to convince me to dislike Werror 😛

and this is the part where I say that writing C++ for multiple compiler is a nightmare

`-Weverything -Werror`

we ran into this issue in FFmpeg where ``` struct Foo { int a; int b; }; struct Foo bar = (struct Foo){.a = 0, .b = 1}; ``` this doesn't compile on MSVC for no apparent reason

just yesterday I tried building a project and got an error over the use of int64_t, the file in question missing an include for cstdint. Ain't that something.

well that's an error that should occur

surprised the compiler they used didn't produce one

int64_t isn't a builtin type

it's a typedef

something else was including cstdint indirectly

that depends on the libc, libc++, OS, compiler, cpu arch, and probably phase of the moon too

just depends on header

it doesn't really depend on the OS

oh I mean that sometimes `cstdlib` (say) includes `cstdint`, and sometimes it doesn't

what's funny is the build instructions had steps for like a bazillion different OS and compiler combinations which I guess they just never test

stdlib isn't required to include stdint

so that kind of transitive include assumption is incorrect code

sometimee they are required by spec

stdlib is required to include stddef

I agree, but it's almost impossible to detect

if we had modules or just anything that is not direct textual inclusion, it would be a *lot* easier

On Plan 9, headers never include other headers, and the man pages for each header tell you which other headers you must manually include first for it to work.

yes but almost all code needs stdint so that one is easy

maybe im used to C where things are harder

not sure if that's a lot better xD

but it's bad practice to assume transitive includes that aren't guarateed by spec

eg inttypes guarantees stdint, per spec

Sure they just didn't notice they forgot it because it compiled

oh for sure, it's just hard to notice that you did assume it

stuff such as `iwyu` exists but half of the time it doesn't really work

I noticed that *most* files in the project does include cstdint

Just, a couple were missing it.

though messups do happen

like I accidentally included error.h in one of my projects cause I thought it was the header for errno

but error.h is a glibc extension that I wasn't using tho

nothing makes me add `-w` faster than `-Weverything -pedantic`

lol

Generally there's a few things I Werror

like implicit function declaration

since that tends to be a typo that fails at link time

Werroring it catches it earlier

in other news, DecodeTest.AlignTest is actually failing

which may be relevant

yeah probably

that should just be a hard error nowadays 🤣

currently running the tests locally to see if I can figure out why

I think it is in C++, just not in C

and it might be in C11

yup

do you know how to run a specific test and only that test?

trying to run all 6k tests is taking an exceptionally long time

I know you can do it with ctest, but I usually just `./lib/test/the_test --gtest_filter=...`

makes sense

what's the `--gtest_filter` argument?

C99, actually

ah, figured it out

apparently `AlignTest` is failing because the test is incorrect

``` EXPECT_EQ(expected_line_bytes * ysize, pixels2.size()); ```

that makes sense

I force pushed to the PR, fixing the test

I recently got a compiler warning that it’s been deprecated for a while and will be removed in the next C standard (or something like that)

lmao

it was removed in C99!

Maybe C2y should explicitly mandate generating an error...

sorry, I meant _defining_ a function without declaring it, not calling it

what `-Wmissing-prototypes` warns about

(but testing it now, I’m not seeing the warning I remember seeing about the standard)

I don't think that's against the rules

if it was a lot of code that had `static int helper_func(foo) {` would be invalid

static could very well be a special case

defining a non-static function without having declared it anywhere could be a sign that it should, in fact, be static

I think so, yes

is it worth creating an issue ticket on a file that seems to require a lot of data to initially load? I have an image that requires 271k bytes to start decoding with libjxl stable (havent had the chance to test git yet) and the full file is 408k here is the original file, and output files from djxl and jxl-oxide EDIT: I can also upload the source png if needed

(note that jxl-oxide doesn't wait for a complete progressive scan)

I think the behavior of jxl-oxide here is generally preferred, I tested using the attention center demo https://google.github.io/attention-center/ and the image doesn't show up until around 70% of the file is loaded.

ah I forgot to mention, jxl-oxide produced this image with 4kb of data loaded (tested with `head -c 4000 input.jxl > partial.jxl`)

I think a hybrid approach is possible. Wait until progressive scan if the stream is not ended, render as much as possible if stream is ended early.

yeah 66% is a lot to need to load for a progressive image IMO. Honestly im not sure it *really* matters on a sub 400kb large image, but IMO it would still be nice

that and the accursed public wifi, I swear sometimes it feels like dialup

~~until you walk the the wrong side of a building~~

Odd, it seems to wait until the entirety of the image is available before actually rendering it. The polyfill I was working on was hard to capture it loading progressively because they loaded so fast, but even slowing down the bitrate I think it would start rendering at about 20%. That was with lossy though. Is that image lossless? Might work differently with lossless. https://discord.com/channels/794206087879852103/1036951308294434857/1045481067664134154

Also could be that the browser code itself waits until all the blocks are available so it doesn't show individual blocks loading with a bunch of white space.

sooo lossless streaming on huge images seems to be a whole lot faster than non-streaming

``` JPEG XL encoder v0.10.0 5ed84a80 [AVX2,SSE4,SSE2] Encoding [Modular, lossless, effort: 7] Compressed to 48235.9 kB (9.881 bpp). 7216 x 5412, geomean: 5.014 MP/s [4.92, 5.02], 4 reps, 8 threads. 227.59user 1.83system 0:31.33elapsed 732%CPU (0avgtext+0avgdata 386908maxresident)k JPEG XL encoder v0.10.0 8803b203 [AVX2,SSE4,SSE2] Encoding [Modular, lossless, effort: 7] Compressed to 47974.1 kB (9.827 bpp). 7216 x 5412, geomean: 0.406 MP/s [0.28, 0.46], 4 reps, 8 threads. 391.78user 85.60system 7:08.85elapsed 111%CPU (0avgtext+0avgdata 5571068maxresident)k ```

and parallelizes better too

I didn't expect things to improve so much

Is JXL normal to have more compression artifacts than normal JPEG?

JXL seems to have more DCT squares

The JPEG screenshot on the left: DNG -> Lightroom -> export 90% quality JPEG -> Lightroom -> Set Sharpening to 150

The JXL screenshot on the right: DNG -> Decode to RGB -> libjxl conversion with 0.19 distance effort 4 -> Lightroom -> Set Sharpening to 150

Why the sharpening? And are the two compressed files the same size?

Size are almost the same, the jxl one is 7.4mb and the jpeg one is 8mb. I just tried to use sharpening to check the image quality visually.

I'm not so sure that that is a valid method

sharpening an image to check is quality is not a good method

it's a weird method — but if you do it, then you should compare to the sharpened original, not just see which one looks smoothest after sharpening

I wouldn't use sharpening though, maybe contrast stretching or something but sharpening seems weird to me

yes, sharpening distorts structurally, not good

I usually create a diff then crank the contrast, not a great method but it works xD

also: I wouldn't recommend effort 4 lossy encoding. Effort 6 should be fast enough for any normal use cases, and it gives significantly nicer results imo.

I know. But increasing the brightness can also show the artifacts.

I’ve tried 7

I can't judge artifacts if you don't show me the original to compare against

If you can't seee the difference by just zooming in then I suppose the lossy codecs have done their jobs

All right. I’m actually building an app to compress DNG to JXL DNG, but with even 0.1 distance, some post processing can still show some artifacts which may reduce the usage of jxl dng. So I just want to check if it’s normal.

do keep in mind that JXL is a visual codec that's tuned for the content being displayed

so doing things like amplifying distortions can cause differences that the codec (correctly) determines to be not noticeable

the encoder makes decisions based on how the image is going to be presented

as it stands, distance 0.1 is very low

and it should be extremely hard to tell the difference between it and the original

yes, but it all depends on viewing conditions. Distance 1 is supposed to be 1 JND unit when viewed at ~1000 pixels distance and on a 200 nits or so display in normal indoors conditions. If you're going to view 3x zoomed on a 500 nits display in a dark room, then that might be equivalent to 5 JND units or so (I dunno how it scales but you get the point)

One thing that might be worth doing for a use case where further processing is expected, is to bump up the intensity target, i.e. pretend that the image is 1000 nits or even more (by default libjxl assumes it is 255 nits for an SDR image). This will cause the darks to be preserved better, i.e. as if exposure was two stops higher.

Thank you for mentioning this. I feed the raw linear 16bit RGB data to libjxl, and the primaries is set to `JXL_PRIMARIES_2100` and the transfer function is set to `Linear`, so should I use 10000 nits? How can i choose the proper intensity target for such input?

https://github.com/libjxl/libjxl/blob/main/lib/include/jxl/codestream_header.h#L138

if you have HDR data, then intensity target is already important metadata that you should know

is it actually HDR or just wide-gamut SDR?

Ideally I guess for raw images where the goal is to preserve the scene light, the intensity target should be set to something that corresponds more or less to reality. Reality is about 5000 nits for a typical sunny-day outdoors scene but peak intensities from specular reflections or direct light sources can be much higher than that (e.g. 600k nits for the sun at sunset/sunrise). Setting it to 10000 nits should be fine to allow further processing without having to worry that the darks will get artifacts when brightened in postprocessing. (you'll end up producing a jxl file that will be very bright and painful to look at though, when displayed on an HDR screen) Or what do you think, <@604964375924834314> ?

10,000 nits shouldn't be bright and painful to look at

that's pretty typical of PQ content, for example

if you have an actual 10k nit display, and are in dim surropundings it could produce a mild headache

well most displays cannot do more than 1000-2000 nits. Professional mastering monitors can go to 4000 nits typically.

flashes could be legitimately painful though

but 10k nits is also the typical intensity target for PQ-HDR content

that's all I meant

so it's not like you're setting it unnaturally high by doing so

the content is typically mastered to 1k-4k nits, 10k is the signal limit PQ can do but it's not the actual content peak that is typically used, since there are no displays that can do that anyway

~~just don't tell that to people producing HDR demos~~

10k nits is pretty bright — of course our eyes can handle it, it's just a bit brighter than a clear sky, but compared to the usual SDR white that is 100-300 nits, 10k nits is pretty blinding

thank you guys, I've tried 1000nits. It already works. Although the size is a little bigger, but the result is awesome even with effort 4 and distance 0.45

The intensity target seems to have a huge impact on the encoding quality for non SDR inputs.

What was the memory usage looking like? Because I'd have guessed the blocks used for streaming encoding might be running on separate threads entirely, but that would also raise the memory usage considerably too. Or at least that's my thoughts from peeking at the code the other day and those timings

400 mb or so? The main difference is that we learn 64 trees in parallel, as opposed to a global one 😛

Ahh right

PQ content is not supposed to be painful to look at

well, the Dolby demo files are, though

yea, but 10k nits is a typical intensity target

most (non-demo) content doesn't use that range

but that's the *target*

PQ by definition has a 10k nits maxval. For HLG it's not defined in an absolute way, the maxval is 12 times whatever SDR white is...

does it make sense to extend streaming up to e9? also maybe different group sizes might be better/faster for some cases and as I mentioned, it would be nice to have it for e1 <:KekDog:805390049033191445> lossy might be faster too, because it's more linear threading and less memory, so memory bandwidth is not a bottleneck

E1 has been able to do streaming for a while 😛

Also different group sizes works too

Lossy vardct can do streaming too, but only up to speed 6

IIRC

Not sure if streaming e9 lossless would make sense, perhaps we need to add a e10 too

i mean different group sizes for e1 <:Poggers:805392625934663710>

And move current E10 to E11 😛

?

have e10 exhaustively choose all options including various values of group size shift?

previously it was not possible to choose group size for e1

Ahhh, yeah, It doesn't do that still

That's already there, but we could do streaming up to e9, E10= non streaming E9, E11 = current E10

¯\_(ツ)_/¯

I have no real opinions on exhaustive searches anyway since they're mostly toys

and not for real production use

but, if streaming is not going to be the default for efforts higher than e7, does it make sense? or because it is much faster, it would be better to make it default for all efforts? <:Thonk:805904896879493180>

I've said it before and I'll say it again, really exhaustive stuff should be called something like e99, just to make sure people understand how bad it is.

Maybe e1000

I'm in favor. Currently there is too big a mismatch between lossy and lossless effort, and that would help fix that.

It Is behind a --allow_expert_options

So basically e1-e9 become streaming by default, e10 becomes the old e9, and e11 is locked behind --allow_expert_options and is the old e10

Maybe we could have an e11 and e12, where e11 is something like the current e10 but less exhaustively (say, try 4 things or so, so it's only 4x as slow as the current e9), and e12 is the crazy exhaustive thing that we want to lock behind a toggle because it is too crazy

Having e1-e11 available to the general public is satisfying in a Spinal Tap sense

maybe it's better to squeeze some efforts or is their arrangement most optimal currently?

I think having more fine grained control over effort is nicer. Makes us more complete in covering the Pareto front...

If you can make the PR you'd make me happy 😛

Not now, maybe later this week though

and then we need the opposite, to inform in cli when it's a non-streaming encoding mode <:KekDog:805390049033191445>

and even faster e0, with some settings from fjxl <:kekw:808717074305122316>

e1 is basically just fjxl keep in mind

but in libjxl

yeah, but without access for some more specific settings

Right, there is fjxl effort too, like trying palette or not

actually this, we need a way for people to know that e10 lossless is significantly slower than e9 lossless if it's not hidden behind expert options i also thought about just keeping e1-9 but adding a flag to disable streaming (and note its tradeoffs), but maybe that just adds complexity?

or maybe just document somewhere what each effort level does (i swear we had this before?) i think i really only know what they do since i've asked and read a lot about cjxl 😛 would be useful to new users who don't yet know which effort to pick and their pros and cons

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

right, thanks for finding it! but maybe add notes when there's a significant drop off in speed (e1 to e2 lossless, streaming vs non streaming, etc.) or just highlight the differences between each effort (e.g., e2 is decently slower than e1 for decent compression gains)

or e9 is slightly better than e7 for significantly slower speed

i think because speed is something that is not constant and can be optimized, it is not something that needs to be noted in cli or documentation, maybe just links to some benchmarks

Benchmarks are already run at various qualities and efforts when density or speed changes are made in PRs, so it could make sense to have one with each release too. Also show improvements across versions that way too

The sitch with e10 (e11 preemptively) is quite plain: don't use it. It's very dumb and very bad. If you absolutely _must_ waste some cycles, using a combination of e9 settings can yield a better result.

<:monkaMega:809252622900789269> `if (cparams.speed_tier == SpeedTier::kTectonicPlate)` https://github.com/libjxl/libjxl/pull/3248

that's just the old effort10

with a more appropriate name 😛

(<@794205442175402004>'s idea from some time ago)

I love these names lol, I thought "Glacier" was great but now we are gonna have "Tectonic Plate"

man. I just finished figuring out what settings I wanted to use for manga T.T

for streaming mode larger group size can improve compression or is it almost the same as for normal mode (just for some specific images)?

it can improve yep

which settings ? I'm curious 🙂 manga scans ? or directly from the creator file ? There is a lot of preconceived opinions about the performance of AVIF for mangas, but I would prefer to convince the world jxl does it better

ngl streaming mode sounds really exciting, i can finally encode many large images without using 20GB of RAM <:BlobYay:806132268186861619> and ofc the speed improvements are amazing too

with streaming png support, memory usage would be even somewhat lower <:YEP:808828808127971399>

I think the main killer will be chunked int to float for 8bit images, since that alone quadruples memory usage when run all at once IIRC

probably the encoding speed for streaming mode can be higher even for single-threaded mode, because there is less memory usage <:Thonk:805904896879493180>

Considering how often people were hitting the swapfile due to low system memory, yeah it could make quite the difference haha

For those who missed the key point - what is tradeoff for streaming mode vs non-streaming?

mangascans, anything png I get ill use this, I just use `cjxl Untitled.png -d 1.5 -e 6 -m 1` I don't use yuv444 wtih avif since I also read a lot of colored comics. This is very comparable with avif yuv444, a wee bit larger for the same quality, but since I get stuff like progressive decode and what not, its worth it for me

A multiplication of speed, a large reduction in memory usage, but marginally increased filesize

Thank you!

with streaming the encoder does not have access for the whole image at once, only for a individual block/tile, so compression can be a slightly worse

oh if you do modular lossy then streaming mode is going to do pretty much nothing

Current > Encoding [Modular, lossless, effort: 7] > Compressed to 47974.1 kB (9.827 bpp). > 7216 x 5412, geomean: 0.255 MP/s [0.25, 0.26], 5 reps, 72 threads. > 847.79user 141.99system 12:48.70elapsed 128%CPU (0avgtext+0avgdata 7066772maxresident)k Streaming > Encoding [Modular, lossless, effort: 7] > Compressed to 48235.9 kB (9.881 bpp). > 7216 x 5412, geomean: 10.826 MP/s [10.47, 11.02], 5 reps, 72 threads. > 609.18user 138.46system 0:19.57elapsed 3819%CPU (0avgtext+0avgdata 1003488maxresident)k

but also because `72 threads` <:KekDog:805390049033191445> with less threads, there will probably be less difference

So 50x faster, 7x less memory and 1% larger filesize (Assuming you have enough cores)

it's plenty fast even with 8 threads or so 🙂

Assuming 1 thread per group, I'd be surprised if it fully utilised that many threads

it's a *big* image - but it should do up to 64 threads only

``` Encoding [Modular, lossless, effort: 7] Compressed to 48235.9 kB (9.881 bpp). 7216 x 5412, second: 4.058 MP/s [4.00, 4.06], 2 reps, 8 threads. ```

with 8 threads

Mind doing 16 threads? To see how it scales

``` Encoding [Modular, lossless, effort: 7] Compressed to 48235.9 kB (9.881 bpp). 7216 x 5412, second: 7.026 MP/s [6.84, 7.03], 2 reps, 16 threads. ```

So fairly linear, nice

and if you bump up group size... ``` JPEG XL encoder v0.10.0 796c1439 [AVX2,SSE4,SSE2] Encoding [Modular, lossless, effort: 7] Compressed to 47805.9 kB (9.793 bpp). 7216 x 5412, second: 5.642 MP/s [5.51, 5.64], 2 reps, 16 threads. ```

(`-g 3`)

need some heuristics for the best group size for resolution and number of threads <:YEP:808828808127971399>

If larger groups were always better, then that alone would offset the size increase of streaming

they aren't

they are in streaming mode if the image is pretty uniform (which tends to be the case for photo)

Yeah, hence the if. It was a few months ago I had a file that was almost 10x smaller with -g 1 than it was with any other. Or something similar, I know I talked about it here at the time

Discovered it when e 8 was much smaller than e9 which had me scratching my head for a while

whelp I pulled the latest libjxl before starting to play with jxl_from_tree's code, but now builds fail because of a problem with libpng

Not bunding PNG solves that I guess 🙂

FORCE_SYSTEM_ETC. flags should all be enabled on linux if possible

is there a convenient way to build the bare minimum needed for jxl_from_tree? I don't know a whole lot about CMake

maybe doing unclean builds is fine when bisecting...

`cmake --build build_dir --target jxl_from_tree` and `ninja -C build_dir tools/jxl_from_tree` both seem to work, in that they only link that tool, but they still build a lot of stuff not needed by jxl_from_tree.

Strange, did we remove anything?

https://github.com/libjxl/libjxl/compare/v0.9.0...v0.9.1 I would have expected that it just works, but perhaps one of those commits is causing a breakage? I plan to try to build chrome and make patches for v0.9.1 (and the upcoming v0.9.2)

at first glance, I don’t see any removal in there that can’t be expressed in terms of what remains

(which is presumably why we removed it)

patchset 8 is rebased on today's chrome with v0.9.1 is here: https://chromium-review.googlesource.com/c/chromium/src/+/4255409 builds fine, there were only minor merge conflicts, because stuff in chrome changed a bit... Will upload patchset 9 with v0.9.2, but I expect that bump to be trivial

Patchset 9 with v0.9.2 is now also there

could zlib be switched out with [zlib-ng](https://github.com/zlib-ng/zlib-ng) in libjxl? I assume zlib is only used for PNG handling in the tools but it should have noticeable benefits for people batch converting folders of PNGs and such. there's some small benchmarks people have done in the past here https://github.com/opencv/opencv/issues/22573

There's .161 now too

I would rather like libdeflate https://github.com/ebiggers/libdeflate instead, if it's a major concern

never heard of this before, it seems cool! although it doesn't seem to work as a drop in replacement for zlib and the reason I sent zlib-ng is because it can function as a direct replacement for zlib and zlib seems to only really be used by libpng in libjxl's tools so it wouldn't make sense going through all the effort of making a fork of libpng just so it can use libdeflate

i guess then it would be looking at <https://github.com/chromium/chromium/tags>

or better <https://chromium.googlesource.com/chromium/src/+refs>

is effort 6 *that* much faster than e7 where it'd be worth using for this?

e6 is considerably faster than e7, yea

there's minimal diference in quality tho between e5 and e6

gotcha

so I don't particularly see much reason to use e6 over e5

at least atm, e3 and e4 are very similar in speed, so e4 ends up being better most of the time

e5 and e6 end up being very similar in quality, so e5 ends up being better most of the time

it's nonlinear

huh, interesting

ye, it changes which features are enabled

this is what I was able to test before 0.9.0 was released

for example, e3 uses only 8x8 dct blocks, but e4 enables the algorithm that calculates the block layout

that algorithm is fairly inexpensive, so it doesn't improve compute time much

it's why e4 is the default in mpv for screenshots

vardct floors at e3

so not sure why this is giving different numbers for e2 and e3

e1 and e2 are only interesting for modular

it is such a tiny number that it is probably run to run variance

¯\_(ツ)_/¯

maybe

vardct e3 is essentially glorified xyb jpeg

although it is the average across 20 runs with 5 warmups

since it only uses 8x8 dct blocks

it's still better than xyb jpeg because it can take advantage of JXL's entroy coding

yeah but you get JXL entropy coding features right? so its still gonna beat xyb jpeg

but it's similar

ye

lol yea u got it b4 me

ig I considered e5/6/7 much closer to each other because I was looking at them relative to e8/9

yes, especially when doing parallel encodes

if jxl benefits from streaming even for non-streaming input formats, just by encoding with tiles and streaming output, is it possible to use this in mpv/ffmpeg? <:Thonk:805904896879493180>

ffmpeg's structure buffers entire AVFrames and AVPackets

so streamed decoding and encoding for a single AVFrame is not going to be useful in the FFmpeg context

how long does it take to encode your entire corpus

no idea, but a while ago I was testing on my phone anyways. Im waiting for streaming mode to be enabled by default before doing any more testing

ah gotcha

e3 as is today should be e2, and probably there should be an e1 like fjxl

e3 probably should do adaptive quantization like jpegli does

the end result would likely be somewhat better than jpegli and still quite fast

the main difference between e7 and e6 performance-wise are things like dots and patches, which IMO are not that useful below distance 3 or so... which is why cjxl main disables them in that case since a few commits ago (well, enables streaming, which is effectively the same thing)

how does AQ work in libjxl?

Nobody knows 😛

what does that mean

like, is AQ adjusting hf_mult based on the varblock's data basically?

well, it's setting the quantization field, which does change the hf multiplier

ah, I have a static quant table in hydrium and a static hf multiplier

but how it chooses to do so is... well, we have code, it seems to work, and it seems to do sensible stuff, but that's all I know

I used to adjust the HF multiplier based on content but it was too slow and didnt' affect visuals much

so I dropped it, now hf_mult is constant 5

may make sense to redo my HF quant tables so I can raise that number a bit

cause atm I do `hf_quant_table[i] * hf_mult` and if I bake that number into the quant table, I can then calculate it in higher precision

like there's a 7 in there

which just becomes 35

changing it to 8 would be -> 40 effectively

but what if 37 is correct? etc.

although I don't remember exactly how I calculated them in the first place

cjxl seems to set bitdepth to float32 when converting from vardct jxl image. is this intended or a bug?

Probably not intended.

I'll file a bug when I have time

I mentioned this in the past iirc

it was supposedly fixed in https://github.com/libjxl/libjxl/pull/2591

but looks like not entirely

what's the difference between ssimulacra2 in libjxl and v2.1 from this repo? https://github.com/cloudinary/ssimulacra2

it's the same

👍

would it be possible to have `ssimulacra2` from libjxl installed with the rest of the base tools without all the devtools?

I don't want `exr_to_pq` and the like installed when I run make install, but I do want ssimulacra2

is there a way to adjust that with cmake?

No idea, but maybe it would make sense to have metrics, hdr tools, and "rest of dev tools" behind different build flags instead for some more fine grained control...

yea, cause ssimulacra2 is useful for testing other things

(I use it when tweaking hydrium for example)

It doesn't take long to compile everything...

The problem is I don't want them installed

to the best of my knowledge, the only way to control this within cmake is to have our own variable like `JPEGXL_INSTALL_EXR_TO_PQ` and then `if (JPEGXL_INSTALL_EXR_TO_PQ) install(TARGETS exr_to_pq) endif ()`

if using a PKGBUILD or equivalent, though, there is also the option of: ```bash package() { # ... make install DESTDIR="$pkgdir" rm "$pkgdir/usr/bin/exr_to_pq" } ```

ooh, I was wrong, the cmake `install` command has a concept of “components” that we might be able to take advantage of

“the best of my knowledge” has been upgraded

I like when this happens

`doas cp build/tools/ssimulacra2 /usr/local/bin` is my install procedure

if you build the devtools they'll be installed by make install

so you need to build with devtools off, make install, turn it on, build again, copy

or: build with devtools on, copy, turn them off, make install

How much work is left for a version 1.0?

https://github.com/libjxl/libjxl/milestone/1

what's the timeline on officially releasing jpegli?

I wonder if libjxl conversion tools and jpeg decoder will be able to make use of HDR JPEG files on android 14. https://developer.android.com/media/platform/hdr-image-format

Ideally decoding them as HDR image data instead of treating them as a SDR JPEG

Looking at it, it looks worse than just a regular JPEG file with a HDR color profile attached.

But libjxl should ideally at least be able to read and interpret this new android thing correctly.

Looks like it encodes a downscaled gain map image as an XMP metadata object

Instead of just using a color profile like a normal person would do

The gain map is not inside the xmp, it's tail data of the first jpeg iirc. It's basically a messy hacky reinvention of JPEG XT.

Weird that they went with such a dumb reinvention instead of literally anything else

they needed to because nothing else actually does what they want,

except jxl but shhh

Quack, couldn't they have just used an ICC profile and floating point encoder/decoder?

and you know, jpeg-xt

You know, like how libjxl/jpegli does?

strictly speaking about android and only android which is a bit disingenuous IMO but worth it, this may be true in 3-4 years from now. A large part of their new HDR stuff is that it will work fine on old and legacy stuff where HDR is unavailable or inconvenient, which is still the vast majority of devices out there. This is a massive win since content creators can now actually make HDR images without messing up SDR viewers. This is a major issues with "General use" HDR adoption which was very much a chicken and egg problem, that google essentially solved. So gainmaps themselves are necessary regardless of the image format itself. A10 devices are still common let alone A11 devices. and it was only with A12 or A13 that the media codec pipeline in android has become upgradeable without flashing a new rom. it will still need the gainmap + extra data ofc. And there needs to be *some way* of decoding that. so A12+ (or maybe A13 can't remeber) this would be possible

so it's trying to do a HLG?

as in being backwards-compagtible

In the end, supporting both SDR and HDR **with good quality on both** is the key issue, when doing any kind of mapping, you can make it "usable but not great"

HLG on steroids

then use avif with hlg? /sarcasm

[dogelol](https://cdn.discordapp.com/emojis/867794291652558888.webp?size=48&quality=lossless&name=dogelol)

Is there something wrong with just encoding HDR JPEG? So the gainmap is only there so that it can subjectively look better when viewed on a crappier monitor?

the gainmap is there so you can have a good SDR experience

so yes

HDR pictures actually have a **very low** base that actually consumes them

and "General use" hdr is kinda... well very few people are actually pushing for it because windows' implementation is garbage, Apple's impl on ios and osx is... fine, but a small userbase would actually appreciate them. Wayland is doing some impressive work that may be ready 10 years from now. Android has been actively pushing for it for a long time and it's finally ready

but now that it is a thing, hardly anyone actually wants to make HDR images because they look like trash on SDR displays which is most people

google"s HDR stuff actually solves this issue out right

But apparently there was already a standard for embedding gainmaps and they had to invent yet another one for android?

was there ever a "standard" for it?

at least one somewhat agreed upon.

https://jpeg.org/jpegxt/index.html

ISO/IEC 18477-2:2016 does exactly the same thing as UltraHDR, except with different syntax (instead of putting the gain map just concatenated to the SDR jpeg, it embeds the gain map in app markers inside the SDR jpeg).

isn't jpeg-xt patent encumbered though? i remeber seeing s licencing program for it, well considering it was from sisvel, its probably bogus lol

Nope, it isn't. I assume the folks who came up with UltraHDR just didn't bother to check if it already existed.

or they thought their approach provided some form of advantage

(it’s just unclear what that is)

interesting. I thought it was encumbered, then yeah, best guess I have is that the current format allows them to expand support to any other format fairly easily I guess

JPEG XT's reference library being GPLv3 may have played a part in Google's decisions.

Also it being very unsupported everywhere.

eh, it changed “reimplementing JPEG XT” into “implementing something else”

Can jpeg xl have a gain map?

Technically, probably docx could have 😜 . But, yeah: `https://helpx.adobe.com/content/dam/help/en/camera-raw/using/gain-map/jcr_content/root/content/flex/items/position/position-par/table/row-io13dug-column-4a63daf/download_section/download-1/Gain_Map_1_0d14.pdf#%5B%7B%22num%22%3A60%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C69%2C226%2C0%5D`.

There's a proposal by Eric Chan (Adobe), we're discussing it.

Apple has been using heic for a long time. It's strange that android is still using JPEG for HDR instead of jpegxl

The big advantage of the UltraHDR approach is that it gracefully degrades with any old software. That's also its big disadvantage though imo, since it puts little incentive on old software to actually support it.

Agreed it seems to be both a blessing (if base is SDR only, though) and a curse (these maps left there unrotated by apps which didn’t even bother to strip them when rotating the base…). But leaving this, hairy, argument, it also promises something that I understand is uniquely better (?) about this approach. How beneficial are these (esp. local adaptation)?

Unrelatedly, this went from “proposal” to production in no time. Only the other day, a friend asked me why his Pixel 7 “lights up” specular highlights in Photos app a split-second after it shows the base pic 😁 .

In my opinion, I think the better approach is to standardize a good tone mapping algorithm (can be local tone mapping) and not signal the tone mapping weights explicitly. Yes, in principle it allows artistic control over the tone mapping when they are signaled, but in practice I assume that in 99.9% of the cases people will just go with the default, which will be something algorithmically generated. To me, it breaks too many assumptions if you have one image that is actually two images: an SDR one and an HDR one, which can be completely unrelated in principle. Things like rotation and cropping are one thing, but I don't see how to implement generic image processing pipelines in a way that operates on both the HDR and SDR image in a way that somehow preserves the artistic intent.

If you really want full control over the SDR rendition of an HDR image, just make two images and use css media queries. Just like you can have different images for e-readers or for the printed version of a website, if you want. But for the typical case, I would prefer if we can just serve an HDR image, and standardize how it will be rendered on less capable displays so there is consistency and predictability.

The difference between a jpeg encoder and a jpegxl encoder is just the header, and the entropy coding, essentially, yeah?

XYB, the predictors, the variable-size DCTs

modular subimages...

But how viable is this really to standardize how tonemapping is done? There are "Standard tonemapping methods" for various industries, but even these aren't actually standard and keep changing. We used to use Aces, then some people started using reinhardt, and now a lot of people are using "Blender filmic" or tonymcmapface (I still chuckle at this name btw) which requires luts too. Game engines are constantly changing which tonemapper is used. It feels like the whole "tonemapping as a solution" is one of those things that sounds good in theory, but will always be significantly limiting in implementation. On the otherhand gainmaps are pretty much already tried and the results from them have been legitimately great.

I'm thinking something like ICC rendering intent could be used to signal a few options, possibly more could be added over time. The main issue right now is that everyone does something different so there is no way to have consistency of the SDR rendition. Consistency is the first step imo, and then you can decide if the default option(s) are good enough, or if something specific is still needed and you have to send an inverse gain map (or just two different images).

well, consistentcy in SDR isn't something we even have today because of sRGB vs gamma2.2 lol

The thing with gain maps is that it works as a delivery format, but what to do with it in a processing pipeline is much less clear. How do you apply sharpening or a text overlay to such an image in a way that makes sense?

Also, isn't it a bit more complicated than SDR vs HDR? If something was mastered on a 3000 nits display that has a certain very wide color gamut, but I'm watching it on a 1000 nit display with a narrow but still pretty wide gamut, well, the SDR gainmap version won't be right, but surely the HDR version will also require some kind of mapping, right?

Yes, the current gain map approach just interpolates between the two images in that case, which is a reasonable thing to do I guess

I do understand the potential issues for sure. I think discarding the gainmap is necessary if processing an already processed video. That or "Prerender" each photo so you have no choice but to work on either the SDR or HDR at a time, from there you could remake the gainmap I guess

with something like PQ we can rely on absolute luminance for tonemapping, but yes, you need to tonemap a video with a peak 3k nit down to whatever your display is

thankfully tonemapping within the same transfer is a lot easier then changing transfers

If the gain map contains artistic intent that was manually created (say, local tone mapping decisions), then you cannot just regenerate it after an edit/processing step. If it is automatically generated, then why signal it? It's better to signal how it was generated than to signal the result of the algorithm, because then the choice of method can be preserved across editing.

(then again, signaling the result of the algorithm is future proof in the sense that it allows current decoders to render the result of future tone mapping algorithms)

If you have both the rendered HDR and the pre-rendered SDR couldn't you recreate the gainmap using that?

I suppose it may not be so simply hmm

If you overlay, say, a logo on an image, this is well-defined if both layers are in the same colorspace, but say you do the actual alpha blending in the HDR space, how do you then decide what the SDR image is supposed to look like? You have the original tone mapping choices, but clearly they will have to be revised to take the editing into account. But in what way? Basically all image processing operations would need to get extra parameters for conveying how the operation should affect tone mapping choices.

It's a mess if you really embrace the concept that the SDR image and the HDR image are both important, are not necessarily algorithmically related to one another, and both need to be preserved in a processing pipeline.

So I would suggest not embracing that concept 🙂

well worst case scenario, it's more likely the editor will only work with either the SDR image or HDR image at one time, it's not super likely that an editor will allow editing "in place" and not mess up the gainmap, unless the editor itself supports gainmaps and stuff, at which point you are back to the standard gain map process. I don't really think that is too massive of an issue. the real issue would be if you were to edit an image, and export a SDR + HDR image without knowledge.

So if they have some super special hdr jpeg encoder they could probably make it output jpegxl with a better entropy coder and more efficient container format. Then designing the perceptual model around XYB would be another win, and then adding other features like variable block sizes can be added too...

Sorry, I posted this late. I mean if Google has a super special HDR jpeg encoder

Basically it would not require a lot of changes to turn a jpeg encoder into a jpegxl encoder, since jpegxl is a similar format

What do you mean by super special HDR jpeg encoder?

I believe google calls it "ultra hdr jpeg"

They probably thought "super special" would be too much

Well, there was meant to be a jpeg compatible version of JXL, as seen in the middle of the 'cloud' https://res.cloudinary.com/cloudinary-marketing/image/upload/w_700,c_fill,f_auto,q_auto,dpr_2.0/Web_Assets/blog/transition_path.png

The more benefit you would want from JXL over jpeg, the more work making that JXL encoder would be.

No existing encoder uses all of the available features of jpegxl format, and encoders can always be improved later, over time, to take advantage of more jpegxl-specific tricks. You would get immediate returns just by using better entropy coding.

I think if you used jpegli and then did a lossless conversion to JXL it would be basically that.

Yeah, pretty much

But what does them having a jpeg encoder have to do with it? They're probably just using libjpeg-turbo anyway.

If they wanted to use JXL, they'd just use libjxl

They need something to add the HDR gainmap to the jpeg, therefore they must have either a custom or forked encoder

The whole point of ultra HDR jpeg is that it works on all devices that already exist, and all software

It's just tacked on at the end, isn't it? And most encoders allow you to tack on whatever metadata you want.

Until you want to edit it. I. e. it "works" just for viewing untouched HDR jpeg out of phone

Yes

Hi! A quick question about JxlEncoderSetExtraChannelDistance - does it really work? I am trying to do lossy encoding (Distance 3.0) of the same file with JxlEncoderSetExtraChannelDistance(settings, 0, 0) and without it and get the same result...

trying to do this to improve the decompression speed, as decoding lossy with alpha is really slow (6 times slower than webp, two times slower than without alpha)

If I recall Alpha is now Distance 0 by default already

yes, looks like this is the case. Not that it helps much, though. Decoding is like 10% faster, while the file is 80% larger 😦

I assume you've tried the faster decoding flag?

it makes little sense as well. file size is much larger with marginal decoding speed improvements

for now the best size/decoding speed combination for my data is default setting with 3.0 distance with 0.8.2 library

the biggest surprise is how much slower it is comparing to webp

Oh, we're on 0.9.1, with 0.10.0 coming out in around a week. For 10 especially encoding speed is improved, haven't checked decoding actually...

I find encoding with 0.9 something like 50-80% slower compared to 0.8, but encoding is not very important for me, as it is done once. Decoding speed really is important, will try 0.10 when it is out... Thanks!

Made an issue for it, since apparently it's stopping me from trying the streaming https://github.com/libjxl/libjxl/issues/3303

the code has some (in my opinion) lowkey funny lines ```c++ const int bit_depth = std::min(input.bitdepth, 24); ```

seems like it would make more sense to just do something like

```c int bit_depth = input.bitdepth < 24 ? input.bitdepth : 24; ```

this can be accomplished with a cmov, whereas `std::min` is a function call

C++ compiler may optimize it out tho

it usually does yep

what I find funny that is that greater than 24 bits is allowed (since it apparently isn't an error) but it just silently gets reduced.

24 bit ought to be enough for everyone

Just like 640 kb of RAM

my family computer in the early 2000s had a second drive that was 4.5 GB and I remember thinking "there's no way I we'll ever fill that up"

in hindsight that's kind of a strange drive size

But seriously, even at 14 bit the least significant bits are pretty much noise, I cannot really imagine use cases where you really have 24 bit data that is worth storing losslessly (i.e. not just 12 bits of real data plus 12 bits of noise)

higher bit depth is relevant for TRC tho

like linear -> sRGB etc.

Ah sure, while processing you need more bits

uhh maybe if I have details near zero nits that I need to preserve, as well as details near 500000 nits that I need to preserve. maybe not.

You can always define a weird sigmoid transfer curve and encode your images with that 🙂

that would take quite a bit of bracketing (not sure many cameras can even do the amount of bracketing required), or a synthetic image

for reference, 600k nits is “solar disk at horizon” according to wikipedia

7 million nits is “filament of a clear incandescent lamp”

hm

actually

I wonder what the nitcount was of voyager I looking at the sun

5 nits is roughly where colour vision starts to transition into “mesopic” (mixture of colour and night) vision

https://science.nasa.gov/wp-content/uploads/2023/09/PIA00450_320.jpg

this one

I've seen HDR photography of welding, that just tonemapped immediately to something useful, but I wonder if the full range data could be stored...

(0.005 nits, roughly where “scotopic” i.e. night vision takes over)

welding can EXTREMELY bright, like sunburn in seconds levels of bright

ye, that's why you have that welding mask

~~me looking directly at the torch when welding~~

my younger brother is a welder and he took some welding protective glass from work with him when we went to go see a solar eclipse

I got sunburned on my eyelids when I did a quick weld without the mask

that sounds painful

welding is weird, it's one of those odd things you can actually get used to, well pain wise. it's never good for you, but the amount of times me and the guys would just weld with the mask up and just not caring is not small

I guess there might be astronomy data that has huge range — but I dunno what kind of precision they can get from their instruments, maybe it's basically just data with a very steep transfer curve

ye, especially when you're looking at images of deep space that may have a nearby star

with astronomy you sometimes have many exposures, possibly with different filters

so the level of precision can be much larger than in typical photography, though to what degree I'm not sure

https://cdn.esahubble.org/archives/images/screen/opo9601c.jpg I imagine an image like this one is modified with some sort of tone mapping

the stars are probably extremely bright compared to the galaxies in the background

I guess if anyone needs that many bits they'll continue using J2K?

38 bits ye

I just find it funny/odd that it's allowed but not actually supported in JXL to use a value greater than 24 bits. Does the standard actually say 32 bits, but libjxl only supports 24? I don't recall.

Level 10 allows 24 bit uint, or float with up to 23 mantissa bits (plus one implicit mantissa bit), 8 exp bits and 1 sign bit, i.e. anything that fits in a single precision float.

We drew the line there because then you can just use float32 buffers for everything and it will work

Header syntax allows up to 64-bit but that's outside current profiles/levels and libjxl does not implement that.

mm. And using floating point math for everything works well? I know it's supposed to, but still.

I dunno how j2k ended up with a weird limit like 38-bit, it makes little sense to me tbh.

... define well

I mean, we do use int32 for the modular parts and only translate to float32 when converting to the generic frame format (where frame blending and spline drawing etc happens)

as precise as an actual 24-bit integer implementation, when you have 24-bit integers?

depends on what you do

But yeah, float32 does represent 24-bit ints exactly

if you do EPF, probably not

things like DCT also will likely mess up some of the lower bits

(but then an integer DCT would need more bits)

Conceptually, VarDCT works on reals anyway though, right? While modular is specified in terms of integers.

Yes

yup

Well everything is specified in reals, but within the modular parts those reals happen to be integers 🙂

😄

30 years from now, JPEG XXL will allow for up to 113 bits, to allow the use of binary128 buffers...

dicom requires full byte coded entries and it's coded as 40

iirc the two bits are lost in an RCT