JPEG XL

python is such a mess. I hate it and everything that uses it

aur time

Python2 is gone

python2 is in the aur still :D

The last version is 5 years ago

It's dead Jim

well, there is a reason why python is detested for making applications

I thought it was loved

It's Python after all

https://tenor.com/view/wheeze-wheeze-laugh-nikkal-kundhal-nikkalkundhal-gif-23223780

update: it's a known bug still (haasn is busy) but now it has this: https://code.videolan.org/videolan/libplacebo/-/issues/331

u might be able to compile the C implementation using a wasm target? idk

I don't want to have Node.js bindings, only vanilla ESM ones

(why Élevé and not Élevée?)

what's the context for this question?

<@814115494021300285> 's name

oh. Right, it's la lumière...

I misread it as élève tbh

well I'm not a girl, so I purposefully chose that...

~~honestly you're the first person to ask that at all, wonder why others hadn't yet~~

right, but adjectives in French agree with the grammatical gender of the noun they apply to (here, lumière, which is feminine), regardless of the gender of the underlying person that the noun might be referring to

« une grande personne » refers to a tall person, who might be a man

(using this example reminds me of https://youtu.be/nc5LaNcTAfU?t=22s)

This is easy for me to get confused about, since in Dutch and English it's different (although Dutch/English have less grammatical gender than French). In French you say "sa barbe" even though the owner of the beard is male, while in English you say "his beard" (and in Dutch "zijn baard").

oh, yes, only the gender of the possessed thing and not the possessor

(in German, you need to take _both_ into account…)

although as far as adjectives are concerned, I believe it’s the same in German as in French

ein grosses Mädchen

~~I'm too tired to correct pronoun usage XD~~

hence purposefully breaking the grammar to perhaps make the assumption go away, which worked mostly flawlessly so far

wonder if it's viable to use Emscripten, then write my own glue layer to get rid of any Node.js dependency ~~SSIMULACRA2 feels like the current best to both consider speed and result neutrality~~

Woah ur in the fosstoast server lol

i wish the singular 'hen' in dutch was more commonly used as a gender neutral pronoun (e.g. "hen loopt") <https://nl.wiktionary.org/wiki/hen>

it sounds wrong, but i've slowly been adopting it into my vocabulary and i'm getting used to saying it now

now i'm using it when the gender of the person that's talked about isn't clear. it already sounds passable in cases like "ik ken hen niet" but in "hen is onbekend" it still sounds fairly awkward to me

gotta love the wrong and the right pronouns both feeling wrong but for different reasons 🥲

at least in english it works out with 'they'

"die" is a good gender-neutral or nonbinary pronoun in Dutch. It works without requiring grammatically awkward plural-for-singular constructions. "Ik ken die niet" and "die is onbekend" both sound just fine.

Fucking Romans had to ruin everything with their grammatical genders.

ohh yeah that's a good one

never thought of that

Hebrew is my favorite because verbs also have gender conjugation

So past and future tense actually care about gender, number, and person

and present tense cares about gender and number, like adjectives, but not person

Unless it's first person. Then gender isn't a thing

still is in present tho

JPEG X Language XD

btw is jpegli still in a separate repo?

Yes

Still? It's probably gonna stay there, and still needs to properly separated from the JXL project...

in case you think it was always like that and are suggesting it be merged into the libjxl one: it was originally part of the libjxl repo and was separated into its own thing a little while ago. if you knew this and i misinterpreted your message feel free to ignore :p

~~I know that it was split into a separate repo a while ago~~

Nixpkgs still hasn't get round to package `jpegli` in a standalone process yet

When encoding floats to JXL, is `--intensity_target` the only way to avoid crushed blacks with cjxl? I suppose there's also `--disable_perceptual_optimizations` but from what I recall it severely increases filesize as expected

messing with intensity_target can royally bung up decoding for users so that would be not great

Yeah

Really? Are there broken JXL decoders that don't consider peak intensity metadata and just assume some intensity target when decoding XYB?

Because otherwise that should be no issue at all as long as source colorspace is SDR.

Or did something change across decoder versions?

Yet it's much easier to use cjpegli and djpegli via the libjxl release on Windows

I can't build successfully from the jpegli repo on Windows

im not sure I follow, `intensity_target` in jxl specifies how bright the luminance value of `1.0` is. I don't know how decoders handles this, but each colorspace reasonably expects a general value for this. if you encode an sRGB image with an intensity_target of `1000` the decoder when tonemapping should try to make this reasonable when decoding

imo anyways

this is doubly important when doing sdr->hdr or hdr->sdr

i just realized `intensity_target` could have interesting uses when targeting colorspaces like scRGB

for instance this is jxl-oxide when decoding an image normally, and one with a target_intensity of 2000

note in occulante the image is explicitly being requested to tonemap to sRGB

tho this isn';t what I think it would look like

maybe jxl-oxide should ignore intensity_target when decoding sdr to sdr (I thought it already skips it though), not sure around intensity_target of sdr transfer

it's hard to say, realistically, SDR and HDR aren't persay all that different here. In fact I would argue using terms like HDR and SDR here is overcomplicating the situation by using poorly defined terms

it would be ideal for a program to know the "intended reference brightness" of various colorspaces

that being said, doesn't jxl have a boolean that specifies whether a transfer is relative to display max?

I vaguely remember there's something like that

What's your float workflow? One thing to be careful with is assumptions about transfer functions, e.g. if you just use ImageMagick to convert between PPM and PFM, it will use the sRGB transfer curve for both, while libjxl interprets PPM as sRGB by default and PFM as Linear sRGB by default...

That would explain why I was getting much darker images in Irfanview. I'm using a 16bit EXR Blender render, converted to PFM with FFMPEG. Though, I had seen the low quality dark areas on a sample EXR and an 8bit PNG input too. I'll try setting it to sRGB tonight and see what happens

when working with exr I use oiiotool

or really whenever I need more accurate conversions

I think If it is true, don't do tone mapping if false then do it since the pixel would logically be nits

unless I am misinterpreting it ofc

I need to open an issue for Blender, the render buffer is only f16, so none of the 32bit export options actually work properly. Just increase filesize for 16bit content

oof

ffmpeg doesn't default to linear for pfm, but you can always linearize first

Used FFMPEG directly but still got the same issue. As soon as it's a JXL, the image decodes far darker and using lossy doesn't seem to take into account the wider range, so anything dark gets set to a single value instead

if the image is darker it may be a TRC issue

like linear light is being interpreted as sRGB or something

It seems to be a few issues compounding. FFMPEG is encoding the EXR files to 16bit int JXLs and IrfanView doesn't color manage above 8bit. Importing the EXR to Krita and saving it as a lossless JXL, then viewing in either Krita or Waterfox works

Ah... The dithering is a little... Eager, too

```Input #0, exr_pipe, from 'C:\Users\jonat\Downloads\16F.exr': Duration: N/A, bitrate: N/A Stream #0:0: Video: exr, gbrapf32le(unknown/unknown/linear), 2048x2048 [SAR 1:1 DAR 1:1], 25 fps, 25 tbr, 25 tbn Stream mapping: Stream #0:0 -> #0:0 (exr (native) -> jpegxl (libjxl)) Press [q] to stop, [?] for help Output #0, image2, to 'test.jxl': Metadata: encoder : Lavf61.9.100 Stream #0:0: Video: jpegxl, rgba64le(pc, gbr/unknown/linear, progressive), 2048x2048 [SAR 1:1 DAR 1:1], q=2-31, 200 kb/s, 25 fps, 25 tbn JPEG XL image, 2048x2048, lossy, 16-bit RGB+Alpha```

Main annoyance is PFM doesn't support Alpha, so I can't use the 0.9 cjxl to get the correct bpp

```JPEG XL encoder v0.11.0 0185fcd [AVX2,SSE2] Encoding [Modular, lossless, effort: 5] Compressed to 19394.5 kB (36.992 bpp). 2048 x 2048, 1.274 MP/s [1.27, 1.27], , 1 reps, 16 threads. PeakPagefileUsage: 448.5 MiB Wall time: 0 days, 00:00:03.365 (3.37 seconds) User time: 0 days, 00:00:00.796 (0.80 seconds) Kernel time: 0 days, 00:00:05.531 (5.53 seconds) JPEG XL encoder v0.9.1 b8ceae3 [AVX2,SSE4,SSSE3,SSE2] Encoding [Modular, lossless, effort: 5] Compressed to 12349.3 kB (23.554 bpp). 2048 x 2048, 0.757 MP/s [0.76, 0.76], 1 reps, 16 threads. PeakPagefileUsage: 416.6 MiB Wall time: 0 days, 00:00:05.609 (5.61 seconds) User time: 0 days, 00:00:01.031 (1.03 seconds) Kernel time: 0 days, 00:00:24.765 (24.77 seconds)```

```JPEG XL encoder v0.9.1 b8ceae3 [AVX2,SSE4,SSSE3,SSE2] Encoding [Modular, lossless, effort: 9] Compressed to 9010.5 kB (17.186 bpp). 2048 x 2048, 0.006 MP/s [0.01, 0.01], 1 reps, 16 threads. PeakPagefileUsage: 989.4 MiB Wall time: 0 days, 00:12:31.794 (751.79 seconds) User time: 0 days, 00:01:14.406 (74.41 seconds) Kernel time: 0 days, 00:11:39.718 (699.72 seconds)``` Seems like a bit of tuning for floats could be done. `-g 0` performs best because of group palette`

are there tools that try out difference image encoders to find out which is best at losslessly compressing a specific image

from my experience it's not always the same

when testing around with jxk avif png webp

not the same according to what factors, do specific encoders not generate actually lossless images ?

this? https://github.com/WangXuan95/Image-Compression-Benchmark

do note it seems to not have the latest versions of codecs (libjxl at 0.9 - 0.10 was a massive improvement), but you could swap in your own

so, random question: why is the standalone 🧈 tool is called `butteraugli_main` and not just `butteraugli`?

is it to distinguish google's from libjxl's implementations?

afaik libjxl's butteraugli is more updated than google's butteraugli

google's butteraugli was problematic on my last try

hi

Yeah, but I mean, where did the `_main` suffix come from? Any interesting backing story? That's my question basically.

_main could just be the branch name

or well main

_(branch)

Yeah that's probably the most likely story

I think it's just because it has a main() function, i.e. a standalone command line tool, as opposed to a function used internally in an encoder or benchmarking tool, or a library API.

interesting, that makes more sense

IIRC butter predates the master -> main branch renaming effort

Glad effort is being spent where it really matters

few steps away from XP

<@794205442175402004> Have you ever thought of adding intensity_target to ssimulacra2? I believe it would be a great way to make the metric a lot more flexible in harsher viewing conditions.

if you want to increase intensity_target beyond default, it would need to extrapolate, though, like butteraugli

for lower you could also just lower exposure...

I assume the goal is to increase the weight for distortion in dark areas of ssimu2?

Actually, does ssimu2 even take luminance directly into account? Or is all luminance weighting done by the XYB transfer?

I think that XYB transfer is modifiable, though.

XYB luminance is perceptually much closer to sRGB and other traditional SDR transfer functions than to PQ, or Oklab luma: https://www.desmos.com/calculator/jsseulfqad

PQ overdoes it, however, because it assumes no environment light. But still, it is much more perceptually uniform than sRGB or Gamma 2.4 in my experience, I use it for a lot of processing.

Like, 1% vs 100% luminance means factor ~50 for 100 nits PQ for contrast perception relative to linear light, while for XYB it's only factor ~17.

Here relative to Gamma 2.2 instead of linear: https://www.desmos.com/calculator/yanochba5n

Yes, changing the intensity target has an effect on the effective tf

The way it is now, it looks like ssimu2 is giving lower scores than it should on HDR images. Also cjxl has a similar behavior where d1 is a higher quality on HDR input than on SDR images, at least that is how it looks to me.

I am not sure what ssimu2 does on PQ input, it may be that just like cjxl it sets the intensity target to 10000 automatically

people complain that ssimu2 gives good score on low luminosity when the image looks really bad

You mean dark images?

pretty much yes

that is why blue was asking I believe

I think it may assume 255 nits for SDR white, so if you have a dark image but view it on a 500 nits display in a dark room, there will be more artifacts visible than what ssimu2 assumes will be visible

It's also quite possible that there just weren't enough dark images in the corpora I used to tune ssimu2.

~~ssimu2 custom tunes for luminance when~~

if someone give me a formula to plug somewhere

there can be a vship version fast

Well-mastered still images usually utilize the full dynamic range, while dark scenes in movies don't. And bright areas make detail in neighbouring dark areas harder to see.

Right, effectively in a dark movie scene, if it takes long enough, your eyes readapt to a lower overall brightness which makes artifacts much more visible than if the dark frame would be only a part of a larger image that goes brighter in other parts.

libjxl also has the same problem of disproportionately blurring and messing up darker regions. https://afontenot.github.io/image-formats-comparison/#pont-de-quebec&AV1=m&JPEGXL=m

for a laugh, check out JPEG XR on that image

(any bitrate)

does intensity target just modify the psychovisual modelling?

I believe for butteraugli it just changes at what peak brightness content is mapped into LMS colorspace.

right, an sRGB image with `[(0, 0, 0), (118, 118, 118), (255, 255, 255)]` will be mapped to luminances of `[0, 18, 100]` if intensity_target is 100, or to `[0, 36, 200]` if it’s 200

for PQ input, it makes no difference (it’s always the absolute luminance that the PQ signal implies)

That makes sense why setting it to 1000 stops crushed blacks. The values are mapped from the 0-20 range to 0-200, so they get quantized more like the bright areas without intensity_target.... I think

Oh so it’s how many nits full-scale translates into?

strictly speaking, in the jxl spec, it’s just “an upper bound of the luminances found in the image”, to guide tone mapping

but yes, cjxl also uses it to interpret SDR input, mapping (1, 1, 1) to that

Why doesn’t it just do max(image) to find the upper bound?

Or is it like the upper bound of what *could* be in the image?

it’s ideally the actual maximum in the image (so that the viewer doesn’t have to compute it on the fly), but it’s allowed to just be an upper bound estimate (so that the encoding process doesn’t have to involve computing it either)

So a SDR image that only goes to 0.5 should ideally have it set to 127 nits?

yes, theoretically

although current djxl, when decoding this to sRGB, would then remap such an image to use the 0-1 range in the output

SDR transfer functions are relative...

I think so

right, the exact function would be max(luminance(linearise(rgb)) for rgb in image) – is that what you mean?

I understood max(image) as a figurative simplification

there is the cubic root compression in JPEG XL XYB and log compression in Butteraugli XYB, depends which one you use

Didn't know that...

both are biased: cbrt(energy + C) and log(energy + C)

they fit not so badly until few hundred nits

then JPEG XL is kludged to follow log through manipulation of the adaptive quantization

but computation is cbrt (or two multiplications in expansion)

https://github.com/libjxl/libjxl/blob/52aaea503e5e8ec25094472377aab4b2cde96652/lib/jxl/enc_adaptive_quantization.cc#L148C7-L148C49 shows this kludge that makes cbrt and log the same

it is some additional entropy in the adaptive quantization map, but speeds up the decoding

what part of the encode process would you say is "adaptive quantization"? are you referring to the HFMult?

or rather, determining it?

The code in libjxl that resides in enc_adaptive_quantization.cc

would baugli or ssimu2 be appropriate metrics for comparing color quantization + dithering algorithms on a dataset?

PNGquant uses MSE internally I think

Worth trying but at least for ssimu2 it was not tuned based on datasets including such images (or not much at least, iirc TID2013 does have some of that)

I'll be comparing the original images with versions quantized down to 256 colors. MSE/PSNR is the most common metric in the literature, but I figure probably not the most appropriate to test error diffusion dithering. You're trying to create the illusion of a higher color resolution, but the per-pixel error will always be worse than just mapping every pixel to the nearest colour in the palette

Dithering and noise are notoriously difficult things for any metric...

AI metrics when

There already are quite a few

~~ok yeah but good ones~~ [av1_dogelol](https://cdn.discordapp.com/emojis/867794291652558888.webp?size=48&name=av1_dogelol)

av1_dogelol...

I've just rebuilt `ssimulacra2` and `butteraugli_main` (from `libjxl`) and they don't work with JPG (XYB) images and I am 100% sure that I have been using them with XYB images.

What can be my potential problem?

Tried building everything statically. Tried using `libjpeg.so` from `google/jpegli` Tried `libjpeg.so` from `libjxl`

Tried `lcms2` or `skcms`

Maybe git upstream problem. Tests fail: ``` 99% tests passed, 5 tests failed out of 8169 The following tests FAILED: 2819 - CodecTest.TestRoundTrip (Failed) 2833 - JpegliTest.JpegliSRGBDecodeTest (Failed) 2834 - JpegliTest.JpegliGrayscaleDecodeTest (Failed) 2835 - JpegliTest.JpegliXYBEncodeTest (Failed) 2836 - JpegliTest.JpegliDecodeTestLargeSmoothArea (Failed) ```

Yes, another version worked.

Hope this info is helpful for the devs

I will try to pinpoint the exact commit with the problem

Detect codec by signature. ([#4268](https://github.com/libjxl/libjxl/pull/4268)) This is the problematic commit

``` ssimulacra2 ref.jpg dis.jpg -5.08811768 ``` ``` ssimulacra2 ref.jpg dis.jpg Could not decode distorted image: temp.jpg ```

Only breaks JPG with XYB, standard JPG is not affected.

I'll try to fix it. I guess it doesn't check: ```C {0xFF, 0xD8, 0xFF, 0xE2}, // JPEG with XYB ICC ```

all XYB files I checked, show this signature.

I am trying RN. I'll open a PR

The last two values signify an APP2 marker/ICC profile

Yes

I learned it, and it's indicated in the `xxd` output

``` xxd jpg_q99.jpg | head -n 4 00000000: ffd8 ffe2 02e0 4943 435f 5052 4f46 494c ......ICC_PROFIL 00000010: 4500 0101 0000 02d0 6a78 6c20 0440 0000 E.......jxl .@.. ```

``` ssimulacra2 test.jpg temp.jpg -5.08811768 ``` Yes, fixed it

I used butteraugli for helping to compare dithering of the delta palette design, and to automatically find candidate solutions that produced low pnorm*bpp values

https://giannirosato.com/blog/post/oavif/

let me know what u all think – esp <@794205442175402004> , I’d be interested to hear how Cloudinary does TQ (I’m sure u have models that are much better)

Looks interesting, I think we did similar things (though probably a bit dumber, and some things differently) before we started switching to an approach where a simple AI model is directly producing the q setting that is predicted to hit target metric scores (that is, it produces predicted metric scores for all q settings given an image as input)

In any of these approaches though, the weak spot remains having a metric that avoids any content bias. With AIC-4 we want to try to make such a metric or at least understand better which of the existing metrics is best at that, but it is hard and we just started.

I didn't know there was a SSIMU2 fork with half the memory usage, wonder if we could port any of those improvements back to the libjxl version

that sounds super smart to me, I'm sure that model is giving very good results

yeah I wrote it based on another older (slower) Zig implementation so let me know if you have any questions

it ditches some ssimu2 features but it is 99.97% accurate according to my testing so I think it is decent for TQ

The error will be much smaller than the error between ssimu2 and actual subjective quality, so I wouldn't worry about it.

Honestly the zig implementation is far from what s achievable in memory usage

Using some tricks for my hip implem I was able to reduce vram usage from 32 planes to 12 by changing to a tile based computation

Reducing the memory bandwidth needed at the same time which sped up computation

But it's a nice start already to ditch useless things and leads to great savings already

Basically 12 planes represents the source, the distorted and a single temporary image (3 plane) all multiplied by 4/3 due to preloading the multiscale

what you've done with vship is truly amazing; im really inspired by it. if you have documentation for any of this outside of the code, I'd be very interested in implementing pretty much everything you've done

honestly it might just be time for me to look at the vship code

The new code with this optimization is quite convoluted but not unreadable either It would great if I could create a research paper detailing everything that I did for vship

that would be genuinely awesome

I've defaulted to blog posts for everything, I think even that may suffice

Truue though I dont have a fancy website like yours ^^

zola was really easy and fun to set up, highly recommend

now I can just write Markdown and press publish

same here, I set up a blog with Hugo and push it to GitHub Pages

same, use it for www.olimpiadi-informatica.it and it's a pretty good experience

I think I'll be writing my new blog using Typst's improved HTML output in v0.14.

(feels like we are going a bit off topic, but I am very excited about typst's html output too)

May be interested in <https://github.com/Glomzzz/typsite>

indeed!