JPEG XL

Hi guys! Anyone know what "AFV" stands for? I can't find it in the "Abbreviated term" list

it's Alakuijala - Fischbacher - Versari, i.e. <@!532010383041363969> , Thomas and <@!179701849576833024>

basically it's a variant of DCT8x8 where one of the corners is treated specially, so you can have an edge that just shows up a little bit in one of the corners of the 8x8 block without needing lots of high freq coeffs to represent it without ringing

any advice for best JPEG XL pixel art compression? right now i have `-e 9 -q 100 -I 0 -P 0 -g 3`, but it doesn't do as good as the equivalent highest effort lossless webp? am i missing something?

You could try adding --patches 0 and/or removing the -I 0 -P 0

is there a way to specify thread count for cjxl? it always does 2 threads for some reason

avifenc has `--jobs`

`--num_threads`

does it say this anywhere outside the source code

`cjxl -h -v -v`

nice

`--patches 0` helped in some cases, but it still doesn't beat webp for whatever reason

well

not enough testing

i can't be bothered to wait so long for it to finish every time

what kind of pixel art are you encoding?

for NN upsampled stuff, it might be worthwhile if we try to detect that and encode it at lower res with an jxl upsampling filter that does NN

sounds good

i would be happy to see that

Ah, I see. Thanks!👍

link to the reddit thread? <@456226577798135808>

nvm found it

The 95th JPEG meeting is in Asian timezone (to accommodate Japanese/Australian/etc members)

First plenary session starts at 11pm my time

First 'day' ends at 8am my time

Trying to sleep now, can't sleep...

https://c.tenor.com/h4yUDOmTXeMAAAAM/me-squidward.gif

https://c.tenor.com/6SW3q9pfiBgAAAAM/insomnia-cant-sleep.gif

take 5htp and melatonin

dont take em before meeting tho & b aware of how long they last

coffeine and theanine may help staying not too sleepy, or just green tea if you prefer traditional way

or caffee

5htp alone may b pretty useful at restoring proper function & tired-ness after nonsleep

without being forced like melatonin

or traditional way wise, proper food

I guess I will have an easier time to sleep after the first meeting "day"

It's just weird to try to self-impose a jetlag without actually physically changing timezone. Seeing the noon sun and sleeping is not a good combo.

My respect to people working night shifts.

https://tenor.com/view/tom-and-jerry-tom-trying-to-stay-awake-tired-cat-gif-19658579

Gotta join those meetings <a:ElmoHELL:593434575146057728>

~~Wonder what happens when I open those links~~

<@794205442175402004>some of those links have passwords in them apparently :p

oops

shouldn't have shared that then

Inb4 zoom bomb <a:DogeScared:821038589201612820>

they will kick you out fast enough 🙂

but still, better not give people ideas

True probably. At least JPEG meetings aren't really fun targets and guess most people here are more mature than those YouTube Zoom bombers <:KekDog:884736660376535040>

"JPEG raid"

dad i'm invading the jay pedge meeting with my friends 💀

Allowed, yes I guess, as long as it doesn't get too spammy. But pointing out that there's no need to use a website with ads is also allowed 😉

Have you ever see similar error in dmesg? traps: ksplashqml[1820] trap invalid opcode ip:7fffec083252 sp:7fffffffba90 error:0 in libhwy.so.0.16.0[7fffec082000+5000] https://bugs.gentoo.org/841413 I suspect it could be related to CPU Intel Core2 Duo E8400

Most probably it is related.

I realized that any conforming JXL implementation necessarily requires a complete CMS since non-XYB samples might be using an embedded ICC profile

in formats like PNG you can simply delegate the color conversion to the user, if my understanding is correct you can't do so with JXL

pretty sure you should be able to delegate

or.. what exactly do you mean 'to the user'?

the library user would be expected to do the conversion from the color space described in the file to the display space

but in the context of JXL you can't just do that because decoders have to mix colors which might involve a color conversion (again, if my understanding is correct)

They only need to mix colors for frame blending, which they only have to do in enum spaces, not in icc spaces. But if they want to produce output in the original icc space, they do indeed need a cms in the xyb case.

by enum spaces do you mean the ColourEncoding bundle

Yes

I guess my understanding was in fact incorrect (thankfully) then

Alpha blending is supposed to happen in the image space, and is only allowed if that's an enum space.

Well or if it's a non-xyb image, because then the pixels are already in image space.

uh, that non-XYB case was my concern

In the non-xyb case, decoders produce output in the image space so there is no conversion needed. Displaying the image requires cms then, but decoding to png doesn't.

I seem to get it now, after some more (frantic) reading of the spec; I didn't fully understand what save_before_ct exactly meant

Basically patches we want to blend in xyb space, frames in image space.

It's all a bit confusing because xyb means the data is in an absolute space that can be converted by libjxl to any enum space, and non-xyb is in image space, does not need conversion to do the decode itself, but may require the application to do conversion to display it (extreme example: cmyk).

So the output you get can be whatever enum space you want in case of xyb, but in general only image space in case of non-xyb.

That's why I think it would be more convenient to have a default cms integrated in the libjxl decoder (just like we have it in the encoder), so applications can regardless of input: - request the result in any space they want (in particular display space) - request the result in image space.

Currently you can in general get any enum space in case of xyb (but not necessarily image space), image space in case of non-xyb (but not necessarily any enum space), and both in case image space is an enum space. That's how it is when libjxl does not have to do arbitrary icc conversions, which is how we wanted it in libjxl_dec for binary size reasons.

agreed, if you can afford a CMS it should be there

the context was that I tried to make a small JXL implementation from scratch (I believe there are others doing this, but having multiple independent implementations help) and realized that a CMS is nothing but small 😉

Yes, enum only is ok, and it covers 99% of what is in current use, but full icc is quite hairy

I only learned that Skia had its own CMS (skcms) after that realization

Is buteraugli commutative? ie does comparing image A to image B give the same result as comparing image B to image A?

nope

neither is ssimulacra. syntax is [original] [distorted] and the order does make a difference

the following code in the section C.2.4 of the spec: ```cpp len = 0; while (len < 3) { if (Bool()) len++; else break; } shift = u(len) + (1 << len) - 1; /* shift <= (1 << 12) + 1 */ ``` ...seems to be redundant because len is in [0,3] and shift is in [0,14]

I suspect `shift <= 12 + 1` is the correct assertion?

yeah, it matches the current libjxl code (where `ANS_LOG_TAB_SIZE` is 12)

ups xD <@794205442175402004>

heh yes good catch

also a small nit: "Indexing D with an out-of-bounds value results in a 0 value" in the section C.2.1 should also mention writes I think

so if len==3, and u(3) is 0b111, then shift could be 14, but the assert says it should be at most what? 13?

4097 😉

yeah the wrong assert is clearly wrong

just wondering what the right one should be when fixing the spec

shouldn't that match with libjxl (13)?

ah right, dec_ans.cc returns error when shift > ANS_LOG_TAB_SIZE + 1

hmm actually C.2.4 doesn't seem to handle out-of-bounds writes to D at all

I guess if out of bounds writes happen to D, it's not a valid bitstream, because spec says D "is a (1 « log_alphabet_size)-element array having elements representing symbol probabilities and summing to 1 « 12"

but probably it's better to clarify that

that makes sense

does libjxl explicitly handle that though? I'm not sure how a simple (1 or 2 entries) or flat histogram is validated against this situation

good question

still working on it, the entropy distribution decoding is probably complete by now

well my hope turned out to be unsubstantiated

so far the Annex C is very hard to comprehend, lots of implicit and/or seemingly unordered definitions

Yes, I can imagine. It was even worse in the 1st edition.

If you want to, I can give you read access to the spec repo, so you can make pull requests there to improve the text (or issues to complain about them)

that's more than welcoming

for the reference I had the following notes right now:

``` 1. read LZ77Params; and also lz_len_conf (C.2.7) only if LZ77 is enabled 2. read clusters (C.2.6): if num_dist > 1 1. if is_simple = Bool() 1. read nbits 2. read (num_dist * nbits) more bits into clusters else 3. read use_mtf 4. read huffman tree with alphabet size = num_dist (presumably) (C.1) - the spec refers to RFC 7932 sec. 3.5, but sec. 3.4 should be also used 5. read num_dist integers (alphabets) with that tree to read clusters (C.1) - this is NOT DecodeHybridVarLenUint! 6. if use_mtf, apply inverse MTF transform to clusters 2. determine num_clusters s.t. for all k = [0, num_clusters) k is in clusters and all clusters[i] are in [0, num_clusters) 3. read use_prefix_code (which is only used for reading distributions!) 4. determine log_alphabet_size (may read more bits if use_prefix_code is false) - each D[i] has 2^log_alphabet_size entries but has to sum to 2^12 (C.2.4) 5. read configs[i] where i = [0, num_clusters) (C.2.7) ```

``` 6. if use_prefix_code 1. read count[i] where i = [0, num_clusters) 2. for i = [0, num_clusters) 1. read huffman tree with alphabet size = count[i] 2. read 2^log_alphabet_size integers to fill D??? else 3. for each i = [0, num_clusters) 1. read ANS distribution D[i] (C.2.4): if Bool() 1. read Bool() then one or two values v1/v2 and set D[i][v1]/D[i][v2] accordingly else if Bool() 2. read one value vmax and distribute probabilities evenly to D[i][0]..D[i][vmax-1] else 3. read shift and alphabet_size (<= 2^log_alphabet_size) 4. read 1- to 7-bit-long prefix code enough times to read alphabet_size numbers later - codes 0..12 are exponentially distributed frequency bins - code 13 is RLE; should read repeat count here, not later 5. determine which entry to omit (implicitly determined from other entries), which is the smallest alphabet 6. read D[i][0]..D[i][alphabet_size-1] with previously read prefix codes - frequency bins read additional bits accordingly; larger shift, more accurate - RLE can't be followed by other RLE but can be the first code (prev is implicitly 0) 4. initialize alias mapping from D[i] where i = [0, num_clusters) (C.2.2) 7. allocate 1MB window if LZ77 is enabled ```

``` 8. call DecodeHybridVarLenUint with explicit ctx and optional dist_multiplier (C.2.6) 1. if there's an active LZ77 len-dist pair, handle that first 2. read a single integer as token from clusters[ctx] 2. read (per-ctx) state if it is not yet initialized (C.2.3) 3. do the usual ANS stuff and alias mapping to return the read symbol (C.2.2, C.2.3) 3. if token >= lz77.min_symbol 1. read the length symbol with the distribution D[lz_len_conf] 2. read the distance symbol with ??? (what's lz_ctx?) 3. adjust length and distance with some special mapping and dist_multiplier 4. activate the LZ77 len-dist pair and handle it first else 5. read required additional bits 4. update the window and return the reconstructed integer ```

has someone a better answer for the question if encoding gif to animated jxl is supported in ffmpeg already https://www.reddit.com/r/ffmpeg/comments/ukjii7/converting_gif_to_jxl/ did only quick test and failed <:okayman:959407078928175174>

unlikely any time soon

it's not

You may use cjxl to convert animated GIF to JXL. However, in my testing, I found out that converting heavily dithered GIFs to lossless JXL isn't worth it. The resulting file is twice the size of the original. Such GIFs are actually already compressed lossily due to dithering. Perhaps the lossy JXL with some tweaks might produce a smaller file, which wouldn't look too bad.

Trying to do effective recompression of GIFs that themselves come from video is kind of hard, since gif optimizers optimize for the specific entropy coding of GIF.

i found that dithered gif still works well in lossless jxl

Often it does, but not always

Those GIFs look like being dithered using white noise rather than Floyd-Steinberg. That's the worst case for any compression. I tried lossy webp as well and it simply blurred the image to remove the noise. I guess it's a natural feature of the video codec. Not sure if this is the right strategy, after all both noisy and blurry versions look pretty bad.

I think some gif optimizers use a dithering strategy that looks like noise but actually compresses very well with gif's lzw. Those would be hard to recompress losslessly effectively.

In such cases, the damage was already done, and keeping the original file seems to be the optimal option. Anyway, JXL works pretty well for GIFs with cartoon content, producing files about halt the size of the original.

if the original GIF wasn't pixel art or some other content with few individual colors, then I would simply delete the GIF and forget that it ever existed. :D (or go and find the source material used for the GIF and make it directly into a video)

Yeah, gif is basically like a crappy old VCR tape. You don't make a blu-ray version of a movie by just digitizing the VCR tape...

From an endusers point of view, I'd wager that if you have a lot of hard to compress lossy GIFs you are probably best ensuring you have GIF decode capability. If you only have them as rare special cases you are probably best off just taking the efficiency hit just for the uniformity.

Nobody seems to use APNG, althogh using APNG to produce barely compressed 24bpp animation from video is a similar level of insanity as using GIF for that purpose. However APNG would have a better chance to be recompressed to some video codec and don't look like garbage.

I think a lot of what people wanted APNG for has been subsumed by things like Lottie-js or WebM, there's more ways to have high quality animations now

APNG also took ages to be adopted widely right?

APNG was IMO designed quite poorly, it doesn't even support all features of GIF like local palettes. I have GIFs with cartoons, that make use of local palettes. In this case APNG produces a bigger file just because it has to use 24bpp instead of 8bpp. So it can't be considered as GIF replacement and it can't be optimized very well.

Nearly 10 years for Chrome to support it

Firefox got it in 2008, Chrome in 2017

Considering how versatile standard PNG is with the variety of supported bit depth options and color/grayscale modes, the limitations of APNG look like a lost opportunity. At the moment, webp looks like a much better alternative to APNG, it allows using mix of lossy and losslkess frames as well and it's easy to make. Of course, JXL looks very promising as well. JXL can do everything that webp can and much more.

well initially they wanted to make MNG the motion png

MNG is quite complex, see http://www.libpng.org/pub/mng/spec/mng-1.0-20010209-pdg.html

so complex that they defined a subset called MNG-LC that is easier to implement

and then a subset of that called MNG-VLC (for "very low complexity")

and APNG is even simpler than MNG-VLC

I remember that spec, it is sort of an attempt to (re)do SVG + animation in a binary format

plus also the half-baked movie format

well MNG kind of predates SVG and it's raster only

yeah, but that's my impression (especially after knowing SVG)

thinking about that it can be more accurately described as an SWF format but without vector shapes 😉

yes, maybe

and SWF (most probably) only got popular due to the proper authoring software, of which MNG had none

I think that kind of stuff (animations described using some kind of drawing instructions) is now better done using CSS animations, which browsers will render smoothly

that's basically what SVG currently is, right? animated svg is pretty much css animation, no?

MNG doesn't seem to be widely supported at all. APNG is extremely limited. As I found out, APNG even doesn't support commonly used GIF features. No wonder people continued using GIF. The last nail to APNG's coffin for me is Gimp even doesn't support APNG out of the box. It does support animated GIF and WebP though.

recurring theme: the success of a format doesn't depend that much on its technical strengths, but more on availability of (good) tooling

GIF still exists in 2022 because it is so well-supported by everything

JPEG 2000 and MNG failed to get traction because they lacked good implementations

most of the hate for WebP and the reason it took so long for non-chrome browsers to implement it is also the lack of support in common tools

but of course that's a chicken and egg problem

That's true. Cteating GIFs is easy. Webp has quite usable command line tools. Creating APNG is kinda painful, but doable. However if I wanted to create a MNG, I guess I would have to use my favorite hex editor.

implementation-wise probably, but SVG has a different (XML-based) syntax for animation

talking about the implementation availability... I kind of seem to keep finding issues from the JXL specification (oops)

is mine the first reimplementation besides libjxl and jxl-rs?

SVG can do anything, but it got kinda too complex. To render SVG properly, you need a web browser engine. It's not a big problem for web use, but it makes SVG kinda awkward to be used as a general purpose vector format.

yeah, I recall attempts like https://github.com/google/iconvg/

Yes, afaik it is. So it's great that you're doing this, it's the best way to find spec bugs and discrepancies between libjxl and the spec

if you are interested in the current state of implementation, it's here: https://gist.github.com/lifthrasiir/137a3bf550f5a8408d4d9450d026101f

my best guess is that this is about a third or quarter of the entire decoding process?

I kind of feel like doing something like that, with good entropy coding, and then maybe have it as a jxl extension at some point.

Yeah, you have mostly header parsing there, still have to do the actual modular and vardct stuff

the main reason is that, of course, we need to implement about every entropy coding stuff before doing the _actual_ frame decoding 😉

I recommend starting with modular, so you can get some decoded images at some point, which will be a nice milestone

Vardct needs modular but not the other way around

I thought ICC's `enc_size` can be used to skip the ICC data, but it is the number of entropy-coded bytes so I can't skip the ICC decoding process

Yeah that and permuted TOC using entropy decode was a bit of a mistake with hindsight, since it prevents making a simple parser

For now you can just work with jxl files without explicit icc profile though

that's true, though entropy coding is something I would eventually have to implement so I'm trying that first

Yes, makes sense

when i tried doing my own decoder some time ago i kinda just stopped at ICC part because ive realized that i can't care at that point that was a bit too much lol

not to mention that i was doing it in golang & there aint that much of ICC processing stuff done there, it aint exactly language used for image processing

golang is fine enough I think, there is no fundamental issue preventing an efficient decoder in Go

I'm writing it in C (haha) only because i) I wanted to make it small and C is probably the best language to do that and ii) I like stb_image's overall selling point despite of its enormous shortcomings

it feels very different to write things in C and in other languages, as in C you're gonna very aware of memory uses

because otherwise you will either leak it or risk memory unsafety

C is fine, tbh. I've done quite a lot of stuff in it so manual deallocation just feels natural when you get used to structuring code the right way

well the manual deallocation itself is not bad, just annoying, but a logic bug in C can manifest itself as a memory unsafety

which doesn't always crash and can become an exploitable bug (in fact, if you can guarantee crash for any such case it's probably okay)

you also gotta be careful about myriad of ways compiler misinterprets undefined behavior as allowance to optimize out checks

but, again, if you structure it in the right way it usually doesn't manifest itself

i personally like freedom from bound checks, but you gotta keep your brain flexed in certain ways to avoid doing errors

which is sometimes kinda tiring

I think this is not very true, I've just restructured jxsml in the way no implicit integral conversion should occur for example

because I realized that u(31) will cause an UB under the current impl

note that we don't actually have u(31) onwards in the spec, but we still need to make sure that u(31) never occurs

enabling all warnings & then some also helps

for stuff you described, `-Warith-conversion` should help

yeah I did end up enabling `-Wconversion` (which doesn't seem to be enabled when `-Wall`, which is a lie)

off-topic: lol on `-Weverything`

don't do that lol maybe only to find some extra flags to add in but definitely not for actual use

that's usually wayy too noisy

yeah `-Weverything` is not recommended, is `-Wextra` usable by now?

I do use it for one project of mine so probably

but then i also manually deactivate some warnings too

actually, `-W` is a synonym for `-Wextra` (didn't realize that so far) so it's just fine

and I've found yet another curiously named option `-Wmost`...

(which is a subset of `-Wall` by the way)

`-Wmissing-prototypes -Wstrict-prototypes` are some of flags that improve quality of codebase, if enforced, and I think aint included in `-Wall` or `-Wextra`

``` ctx=0 byte=0x41 A ctx=0 byte=0x44 D ctx=0 byte=0x42 B ctx=0 byte=0x45 E ```

kind of relieved to see this log

A little curious, PR1395 heuristic probably can identify some non-photo features(like pixel art) and use modular patches process those non-photo features on non-DCT lossy method? > https://github.com/libjxl/libjxl/pull/1395

those images have alpha, which atm kind of ruins the heuristics because by default in vardct mode we change invisible pixels to some blurry mess that compresses better with vardct, causing the heuristic I have there to not be very effective

if I turn the images into ppm so no alpha channel, it does do something: ``` Encoding kPixels Bytes BPP E MP/s D MP/s Max norm pnorm BPP*pnorm Bugs -------------------------------------------------------------------------------------------------------------------------- jxl:d0.5:no_more_patches 8057 3827508 3.8000262 2.523 24.258 1.60146487 0.40673860 1.545617357804 0 jxl:d0.5:more_patches 8057 3924483 3.8963049 1.641 12.429 1.60146487 0.36146831 1.408390756813 0 jxl:d1:no_more_patches 8057 2743640 2.7239405 2.569 23.389 2.60309267 0.67690235 1.843841691805 0 jxl:d1:more_patches 8057 2879987 2.8593085 1.683 13.612 2.28676367 0.60322047 1.724793400146 0 jxl:d2:no_more_patches 8057 1877509 1.8640283 2.614 23.201 4.18940258 1.10066881 2.051677866936 0 jxl:d2:more_patches 8057 2002257 1.9878806 1.751 14.471 3.41511583 0.99260559 1.973181445061 0 jxl:d3:no_more_patches 8057 1445875 1.4354935 2.515 24.347 5.78894663 1.48654022 2.133918846267 0 jxl:d3:more_patches 8057 1616553 1.6049460 1.582 16.985 4.45794296 1.35440503 2.173746978943 0 Aggregate: 8057 2383855 2.3667388 2.061 18.433 2.94360591 0.77641388 1.837568844778 0 ```

not sure if it's doing something good, but it's doing something

(quality improves but size also goes up)

Thank you for your reply, This heuristics is really flexible, 🙂 if force keep lossless alpha channel, probably can preserve alpha channel? > --keep_invisible=1 > force disable/enable preserving color of invisible pixels (default: 1 if lossless, 0 if lossy).

yes, that would help, or what would also help is if we would do the modification of invisible pixels in a different way

Thank you for your work, I appreciate your help very much 🙂

i get these results now on average for a manga set

Cool <:BlobYay:806132268186861619> , That improvement is really great.

probably more can be done still, this only produces rectangular patches where the four corner pixels have identical colors, so it can replace things like lines or text with Modular when they're on a solid background, but not things like hard edges between two regions of different color, or backgrounds that are not solid but e.g. a gradient

the tricky thing is if the background is not solid, how do you extract a patch without messing up the remaining vardct image _and_ without introducing extra entropy in the modular patch

Maybe <@532010383041363969> have some idea?, I remember `Jyrki Alakuijala` mention something different lossy method on `encode.su` comment.

you can ping him, btw <@532010383041363969>

devs don't mind getting pinged

they are only polite and don't complain about our constant annoyance. But you should be careful to not spam people like <@532010383041363969>, <@794205442175402004>, <@179701849576833024> or <@604964375924834314> else we might never see 1.0.

why warn me not to spam them in the same message where you literally ping all 4

<:KekDog:884736660376535040>

<:Spam:806628077656473650>

I’m fine with being pinged

it’s generally interesting

https://c.tenor.com/ZeNcyTscKGIAAAAM/generally-jade.gif

```c #if UINT64_MAX >= SIZE_MAX typedef uint64_t jxsml__size64_t; #else typedef size_t jxsml__size64_t; #endif ```

I hate C's integer handling (again).

this is stupid why not just alias to long unsigned int or uint64_t all the times

so the issue is that the buffer size comes from the outside so it has to be size_t (or you can convert beforehand, but that's only moving the conversion point)

while you have uint64_t sizes in the container format

so somewhere you need to compare size_t against uint64_t to prevent overflow

now, the integer promotion rule means that you can do that just fine, but `-Wconversion` prevents that 😉

(for the good cause)

so I needed a type that is no smaller than both size_t and uint64_t, and it turns out `-Wconversion` doesn't really matter in preprocessors, so here we go

I think there is no legal way to do this without at least one such comparison, at least before C23 (where you'd get `inttype_WIDTH` macros)

id just manually case it to uint64_t in places where i do checking

because this feels kinda too hacky

I'm wary of such casting in general

the only time you can't just treat both as uint64_t is if the size_t buffer size is greater than UINT64_MAX

so you can just check for that case and whine

as far as I'm aware -Wconversion should not whine if you are seamlessly promoting unsigned integers

in a comparison

if it does then you can safely ignore it

really? I would have to check this again

well the whole point of -Wconversion is to warn about potential loss of precision due to conversion, right?

``` Warn for implicit conversions that may alter a value. ```

from the GCC manpage

which means comparison of unsigned integers with `>` should not cause -Wconversion to fire

since whichever is smaller will just be promoted upward

indeed, I'm not sure why I had an impression that the warning is fired without a reason

maybe I have mistaken other warnings

did it fire anyway when you tried it?

there was some warning prompted me to work around that, but I don't recall which

anyway I've removed that workaround type and everything seems fine, so I'm happy

except for this new one: ``` jxsml.c:121:24: warning: comparison is always true due to limited range of data type [-Wtype-limits] JXSML__SHOULD(size32 <= SIZE_MAX, "bigg"); ```

Are there any systems where size_t will be larger than uint64_t?

Even the current 128bit stuff I've seen still uses a 64bit size_t

I doubt

anyway, that happens because `sizeof(uint32_t) <= sizeof(size_t)` here, which is the case for most current platforms, but the warning is not always true

what's this?

that checks for a premature end of the container file, but only makes sense for size_t smaller than u32

wait, thinking about that I can also get rid of that line

yes I can totally do that, that code was the step 1 for the EOF check, since the box length was first written to size_t (possible overflow here) and then compared to the provided buffer size, but I don't need the first step anymore

better off not writing the box length to a size_t

if it could possibly overflow

yeah, as said above I originally thought that we need size_t vs. uint64_t comparison is inevitable anyway so I overlooked that line

imo u shouldn't limit to something machine dependent like SIZE_MAX

as that leads to implementation-defined behavior

if something should be limited to something like SIZE_MAX then it's likely that it'd be better limited to 4GB

or even less

but it seems in this case it wasn't exactly for that purpose

I'm aware of that, probably I need to elaborate my current design more accurately

I do expect that jxsml eventually has to support an on-demand input source, that is, essentially unable to load into the memory beforehand

but writing that code right now complicates the source code, so I didn't implement that while being aware of the possibility

that's why this sort of code only occurs in container parsing codes, cause I've been more cautious in the bitreader 😉

(I assumed the container parsing code will remain small enough that I can easily fix for other input sources later)

Is this how DCT works? (10:06-10:42) https://youtu.be/Q1bSDnuIPbo

No wonders, the GIFs are too noisy. You can't recompress that losslessly efiiciently.

Also, there is a program called GIFSICLE. It's designed for optimize GIFs to the smallest possible file size. It also provides some kind of lossy encoding. That instroduces more noise in the image, but it's also hard to recompress to anything else.

i want to see a big youtube channel like linus tech tips/tech quickie make a video about modern image formats, maybe video codecs

they'd probably fuck it up, tbh

Linus Media Group *sucks* at basic research.

how?

They misrepresent, probably not maliciously, tech stuff all the time. Since I don't think they're malicious, the only explanation is incompetence.

it would be great if you gave examples, especially "all the time"

There have been a few times. Some of their stuff on colour profiles while covering HDR stuff ifs a little iffy.

Generally they are OK, given they pump out the content quite fast.

naturally with hundreds of videos there are bound to be mistakes

Most of the cases I have notices are where they miss caveats.

LMG is good entertainment and makes tech stuff approachable for those who don't care otherwise

Yeah, on the whole they are quite fun.

Yeah, but they would need someone like me to be a media consultant for them to check the exactitude of their script and statements <:kekw:808717074305122316>

> it would be great if you gave examples, especially "all the time" But then I would have to actually go back thru and find the videos I've watched etc, which would require effort... One example I remember perfectly though, is when Anthony reviewed one of the recent Mac models (I think the Mac Studio?) he brings up Hector Martin's findings about the poor performance of Apple's SSD solution when flushing to permanent storage. But he completely misunderstands what Hector is saying. He implies that Apple is doing fucky stuff to create false and misleading numbers, but a) everyone advertises non-sync write perf, not just Apple, it isn't weird. b) the different behaviour for the fsync command from what most Unices does is annoying, but not some trick Apple cooked up to make their newer home-grown SSD solutions look better. Back in the day, all Unices had that behaviour, and Apple was simply adhering to the norm. They documented that behaviour, created extensions for people who do not want that behaviour (the POSIX standard is rather lacking in this area). c) Hector literally straight up says right in that tweet chain that Anthony quoted that it was probably just a bug, and that Apple will most likely be able to improve sync-write performance with an update. So he either didn't understand what he was reading (technical incompetence), or he did but was intentionally misleading (malice), or he just took a quick glance and included it without reading it properly (research incompetence). Another one I recall quite clearly, but don't know much about myself: I'm in a discord with a lot of FOSS developers, and I remember one time when a dev there vented about how Linus had just released a video covering a project they contribute to, and the video was full of misinformation about the project. Apparently, LMG hadn't even bothered to contact the project devs to ensure accuracy. They just wrote some nonsense and called it good enough.

i'd like to know which project

or is that too hard

TIL people aren't allowed to have opinions on the internet without spending time sourcing everything.

no i'm curious

I'll have a look later.

Shouldn't be too hard.

TIL i don't allow people to have opinions

I allow everyone to have opinions but the likelihood that they will influence my opinions is generally proportional to the evidence provided.

I just find it annoying to have the expectation of sourcing everything for my opinions in casual conversation. It's one thing if we're having a debate, or trying to find the best solution to a problem, but I just wanted to chat, not sway anyone.

I think that's perfectly fine. Besides, you did give examples. It would also have been fine if you said "no" when asked to give examples :)

that

`no, too much effort, i just want to chill`

sorry, `it would be great if you gave examples, especially "all the time"` felt very strong to me, I might have misread.

i understand

tone can be hard over text

yea

❤️

the best stuff that comes out of lmg are the videos where they mess around and do dumb stuff

Their information videos are often garbage and makes me want to go down to their office and punch someone

a recent obvious one is their windows android one

they did 0 research

I would trust them to do a video on image/video codecs very wrongly

Yup, their mess-up stuff videos can be great but not so much for informational videos

Today in jxsml: I've found that ANS distribution was decoded properly but decoding into some unexpected symbols. There were two problems: 1. I've mistakenly put `offset` in place of `cutoff`, so some zero-probability symbols were decoded. 2. I've copied clustered distributions back to non-clustered distributions. That meant the initial state was decoded multiple times even when a single clustered distribution (mapped from multiple non-clustered distributions) is used. D'oh.

not sure if the problem 2 needs a clarification in the spec though

The ans state is global for the entire ans stream, it's not one state per cluster (let alone per non-clustered distribution)

oh

the spec definitely sounded like that there are states per each clustered distribution, but in hindsight yeah that's needless

time to file yet another issue!

When you are making a spec from an implementation, these things are too obvious to even realize it should maybe be clarified. Only when you actually try make an implementation from the spec it becomes clear that some things can be ambiguous.

fun fact: if my reading of the spec is correct, the largest number of clustered distributions possible is 495 * 2^21 for level 5 and 495 * 2^30 for level 10

How did you arrive at those numbers?

You can have at most 2^22 MA tree nodes in either level (depending on the image dimensions), so that's an upper bound on the number of non-clustered distributions

In case anyone here looking for webcomic artworks as 2D test images with suitable licence, Pepper&Carrot (an excellent FOSS webcomic in my opinion) has a dedicated artworks page, to access source material (in JPG and KRA (Krita) formats) click an artwork and then click `source & license` button (for most original P&C artworks, the licence is CC BY 4.0 with attribution to David Revoy) https://www.peppercarrot.com/en/artworks/artworks.html

P.S. This wallpaper is what I used as source material in libjxl command-line screenshot in Wikipedia 😄 https://www.peppercarrot.com/en/viewer/wallpapers__2017-12-13_The-micro-dimension_by-David-Revoy.html

HF (AC) coefficient histograms; `495 * num_hf_presets * nb_block_ctx` distributions will be read, where `nb_block_ctx` is bounded by an arbitrary limit (16) but `num_hf_presets` is only bounded by the number of groups which can get very large.

assuming the minimum `group_dim` of 128, max # groups = max # pixels / 2^14 = 2^14 or 2^26 depending on levels, so that's how I ended up with those numbers

Ah for vardct hf ctx, I see

Well group_dim is always 256 when there is vardct

Only in modular mode it can be changed

ah

then it'd be 495 * 2^19 or 495 * 2^28 respectively, still quite larger than 2^22 😉

Yes, you do need a quite large image to reach those numbers though :)

it does mean that for a very large image you need a lot of memory upfront even if you are decoding only a very small part of it (well, one group worth of pixels)

If num_hf_presets is large, yes

you may need, yeah

In the current libjxl encoder, that number is always 1 iirc 😆

after that calculation I threw out an idea to pre-permute cluster arrays at all, it's simply not worth

(pre-permutation meaning shallow-copying alias tables etc. so that you can save one indirection)

modular patches can apply VarDCT and XYB? this behavior conform spec? I just thinking maybe can apply delta palette(XYB) + modular patches VarDCT(XYB)?

I think at -s 9 it might be >1

Patches can be encoded in any way, you can just take decoded pixels from an earlier frame, so you can e.g. have one modular frame (of type kReferenceOnly so it is a "hidden" frame) and one vardct frame (of type kRegularFrame) and then use Patches to draw pixels from the modular frame on top of the vardct frame

Which makes me realize: I should probably try using kReplace patch blending instead of kAdd. Downside is that vardct can no longer correct errors in the modular patch, but advantage is that you can just put some blurry mess in the vardct location that will get patched.

btw who manages matrix integration?

i tried to join on matrix but couldn't :<

also would be interesting to try making use of spaces

I set that up at some point but never checked if it still works

oh somehow i now joined. matrix is sometimes flaky

idea would be to make jxl matrix space, then re-create room for each channel in here

& then link-up bot for each discord channel - matrix room

i dunno whether one can convert room into space though. or maybe just make something like <#794206170445119489>-space, separate from <#794206170445119489> which would remain standalone room on its own, but also be part of <#794206170445119489>-space

doesn't seem like one can convert room into space even if technically space is kind of room but that shouldn't be an issue, can just make <#794206170445119489>-space

That would be neat, sometimes I do use Matrix 😄

Thank you for your reply 🙂 Look like modular patches is a flexible image codec features. > Downside is that vardct can no longer correct errors in the modular patch, > but advantage is that you can just put some blurry mess in the vardct location that will get patched. I guess probably put some blurry mess behavior(increase appeal) is beneficial for really non-photographic non-photo features?

the blurry mess would be just what is in the vardct image, since it needs to have _something_ in the image even if there's later going to be a patch that overwrites those pixels

putting a blurry mess there instead of, say, just a black rectangle, is to avoid border artifacts at the patch boundary

Is there a recent cjxl.exe build somewhere? All builds after ``2022-02-22T15:54:09Z_057ad6b4559fa69e7b393b4b76d0b8bae45b2d9d/`` here https://artifacts.lucaversari.it/libjxl/libjxl/ don't seem to work for me. Outputs no file with slower speeds <:Cheems:884736660707901470>

that seems to be a common issue

Hoped it would just be the latest build, but got that issue with the 7 latest builds there and also some random ones that come after the working one :/

did you bisect the builds?

I *think* this is the same issue as https://github.com/libjxl/libjxl/issues/1282

I just took the builds from https://artifacts.lucaversari.it/libjxl/libjxl/ and tried cjxl.exe separately and also in the folder with all other components. Both caused the same issue

Surprised it didn't cause an error or anything. Got confused at first and thought I somehow lost the file <:KekDog:884736660376535040>

that's a segfault

windows just doesn't say anything xD

Tbh, no idea what that even means <:KekDog:884736660376535040>

Segfault is an ancronym of segmentation fault. Also known as access violation. It means that the software attempts to access a restricted area of memory.

Yes, but other stuff can also cause segfault

Like using simd instructions that the cpu doesn't support

that kills with SIGILL, not SIGSEGV

it's a separate signal

(On unix, at least)

Right

could it have to do with alignment?

I have vague memories of getting segfaults when using aligned (well, non-unaligned) loads on unaligned memory

Yes, that produces segfault too iirc

yep, it does

<@604964375924834314> did you ever get avx2 working on windows?

I believe it works on my machine

but I build with clang on msys2/mingw64

not sure if it has any impact

``` $ tools/cjxl bench.png bench.jxl JPEG XL encoder v0.7.0 a444260b [AVX2,SSE4,SSSE3,Scalar] Read 500x606 image, 11.7 MP/s Encoding [VarDCT, d1.000, squirrel], 32 threads. Compressed to 119663 bytes (3.159 bpp). 500 x 606, 16.53 MP/s [16.53, 16.53], 1 reps, 32 threads. ```

can you try the github artefacts? 😄

``` Thread 1 received signal SIGSEGV, Segmentation fault. 0x00007ff7feaa0d91 in cjxl!JxlSignatureCheck () (gdb) where #0 0x00007ff7feaa0d91 in cjxl!JxlSignatureCheck () #1 0x00007ff7feaa145b in cjxl!JxlSignatureCheck () #2 0x00007ff7feac3c59 in cjxl!JxlSignatureCheck () #3 0x00007ff7feb9c2ab in cjxl!JxlSignatureCheck () #4 0x00007ff7feac5284 in cjxl!JxlSignatureCheck () #5 0x00007ff7fe9ed303 in cjxl!JxlEncoderVersion () #6 0x00007ff7fe930252 in ?? () #7 0x00007ff7fea0447a in cjxl!JxlEncoderVersion () #8 0x00007ff7fea07b36 in cjxl!JxlEncoderVersion () #9 0x00007ff7fe941dfc in ?? () #10 0x00007ff7fe90c569 in ?? () #11 0x00007ff7fe912d3d in ?? () #12 0x00007ff7fec1a32c in cjxl!JxlSignatureCheck () #13 0x00007ff83d9d7034 in KERNEL32!BaseThreadInitThunk () from C:\Windows\System32\kernel32.dll #14 0x00007ff83f242651 in ntdll!RtlUserThreadStart () from C:\Windows\SYSTEM32\ntdll.dll #15 0x0000000000000000 in ?? () ```

i just built with vcpkg and it seems to work too

somehow I didn't see this message before... Well, that's interesting.

so the CI compiler is br0ken?

ffmpeg devs were getting segfaults on windows too

I don't remember the details

weird that it says JxlSignatureCheck - that's a bogus error, right?

Unless we did a lot more recursion than we should in that function, it's probably broken debug symbols lol

Guess we should try and see what's different between CI and Sami's setup

does valgrind report the same location as gdb?

there is no valgrind on windows, unfortunately

do you use gdb inside msys?

yes

how do you use gdb to test a binary? i.e. what's the syntax?

`gdb --args command arg1 arg2...`

then `run`

so `run` runs it until it exits/crashes, then what?

then `where` as you typed earlier?

yes, that gives you a stack trace

thanks, that's what I'm looking for. lemme build it and then see if I can produce one.

and you can go to a specific frame with e.g. `frame 4` and then print local variables

When they're not optimized away that is

I asked the Midjourney AI to imagine the JPEG XL specification

looks about right

yeah I think we can just send that to ISO and call it the second edition

It got the formatting right at least

wtf

free jxl spec <:Poggers:805392625934663710>

If you can't read that it's your own problem

this was something I got with the query "next-generation image codec J X L"

query was "the battle of the codecs, flemish primitive style"

that stuff is fun to play with, lol

I wonder if https://en.wikipedia.org/wiki/Mesopic_vision should be taken into account more — we tend to focus on photopic (daytime) vision, i.e. > 5 nits where the rods are irrelevant and only cones are used

of course during daytime when using 200+ nits screens, photopic vision is all that matters

but what about when you use a phone in the dark with its display set to minimum brightness?

is that still bright enough to make rods irrelevant?

in mesopic vision things become more like scotopic vision (night vision), i.e. there is a so-called Purkinje shift towards blue since rods are sensitive to lower wavelengths (more blue) than the greenish L/M cones

in XYB we model luma as avg(L,M), with X being L-M and B being just S (or in practice typically S-Y)

I wonder if we shouldn't take R into account somehow too, in dark regions below 5 nits or so

probably only for very low frequency signal since the fovea does not have any rods

let's keep that in mind for JXL2 ;)

well it could perhaps also be taken into account by the encoder somehow, I dunno

reading up a bit on human perception

> Peak cone density varies highly between individuals, such that peak values below 100,000 cones/mm2 and above 324,000 cones/mm2 are not uncommon

I didn't know that "eye megapixels" are that variable between humans

i mean at the level of cone count

of course people have all kinds of lens issues too, but that's something else

but XYB is fixed in the spec?

XYB is fixed but 1) non-default matrix coefficients can be signaled by the encoder to make it effectively use variants of the default XYB, and 2) an encoder could make decisions differently, like e.g. what adaptive quantization weight to use in dark regions

that's what the Opsin Inverse Matrix is, right?

Yes

I think issue <https://github.com/libjxl/libjxl/issues/1432> should probably be closed. That user is deliberately wasting time of maintainers and contributors by involving them in long, contrived and sometimes nonsensical discussions about somewhat trivial but technically valid points, see: <https://github.com/obsproject/obs-studio/issues/4520#issuecomment-819923534>.

ugh, we got ValZapod too

he got banned from the mpv bug tracker

seems like someone that feels like being spammy

oh, you were referring to Elfring

yep

we haven't been hit by him yet at mpv

> https://encode.su/threads/3397-JPEG-XL-vs-AVIF?p=74395&viewfull=1#post74395 > But in general I think rasterization should just be avoided as much as possible for this type of image content, > just like I think the text on a website should be rendered using html and fonts, > not raster images. Of course there will be circumstances / use cases when rasterization cannot be avoided > (e.g. when scanning printed versions of such images), ... I think only some specific anime type suitable svg, structure complex anime type(like 2d drawing, manga content), for those type image, I think the best method is flexible use libjxl features and bitstream, combine VarDCT, Modular patches, Modular delta palette(XYB implement) in same image. av1 codec use blurry process(prediction) avoid some artifacts, I believe jxl can use better method to process those issue. 🙂

Agreed, and of course svg can only be used if the artist used a vector editor in the first place, like Adobe Illustrator

is everything all right here?

today in jxsml: I've implemented most predictors and properties (sans self-correcting ones), and realized that fjxl-encoded images somehow uses alpha channels even though the input image doesn't have ones and I'm yet to implement extra channels

I'm not sure my observation is entirely correct (the image I tested was indexed, maybe that's why) but I think there is no real performance impact as there is nothing to compress anyway

well actually, I didn't exactly look at the bit contents of the original PNG file

uh, so they were not indexed, they were just 8bpp RGB (I misinterpreted an ImageMagick output)

and that's strange, fjxl apparently detects alpha by counting the number of channels, which should be 3 in this case and should not cause alpha channels but apparently outputs do have them

ah crap

fjxl correctly handles PAM, but it always assumes RGBA for PNG

I guess lodepng (that fjxl uses) actually has no way to determine the input bpp & channel configurations?

as it was meant to be an one-shot decoder that the caller knows what to want

for now I'm just going to patch fjxl to avoid alpha channels and proceed

fjxl assumes rgba input, yes. We never bothered to also do rgb and gray only - in compression, it doesn't cost much at all in jxl to have channels that are all-zeroes...

It does have to check if the alpha channel indeed has nothing to compress, I believe Kotono meant this

We could add ppm (rgb) input to fjxl so there's nothing to check, I guess...

Just practical to use rgba buffers because 4 is a nicer number than 3 if you try to do things in chunks of 16

it does, but it doesn't really have a *convenient* way to do it last I checked

A little curious, what's roadmap for libjxl delta palette improvement? I read some delta palette comment from Jyrki Alakuijala, (webp near-lossless limitation, and some delta palette good point), I think delta palette probably can bring more density and quality improve for PR1395 more patches. > https://github.com/libjxl/libjxl/pull/1395 > One of the best-case behaviors is when the image is really a 1-bit image (or close to it) with only hard lines. > In that case the heuristic will just encode the whole frame as one big modular patch > and obtain way better compression and quality than what vardct can do on such images. I really like this behavior, I think this behavior can avoid apply DCT for some not suitable DCT features, and can increase density and quality.

Hiya. Are there newer versions of the codecs somewhere? https://storage.googleapis.com/demos.webmproject.org/webp/cmp/index.html Or is there a reason they are not updated any more?

Yes, there are much newer versions

https://artifacts.lucaversari.it/libjxl/libjxl/ for jxl (note that if you're on Windows most if not all of the builds of last few months are broken for lossy transcoding)

Oh yay, seems like they might actually work now <:thinkies:854271204411572236>

Thanks bunch! I was actually being my usual lazy-can’t-code and mant the nice comparison thingies.

https://github.com/libsdl-org/SDL_image/commit/092cdc9 haha

(Root mean) square error (i.e. basically the same thing as PSNR) is not very useful as a perceptual metric, so the jxl encoder is not trying at all to optimize for that (e.g. quantizing in XYB will introduce pretty large error in sRGB space, in particular in high freq blue, but since humans basically have no S cones in the fovea, high freq blue is not visually important)

Other encoders end up basically optimizing for PSNR, which makes them look very good on PSNR plots (and other metrics like VMAF that are not very different from PSNR), but not when you actually look at the images.

I have seen cases where the simple metrics say jpeg 2000 and heic are great, then webp, then avif, then jpeg, and jxl is the worst of all.

Then you do a subjective evaluation on the same image, and the results are almost exactly the opposite, e.g. jxl is best, then avif, then heic, then webp and jpeg, then jpeg 2000, or something like that.

legacy jpeg beats jpeg2000? that's interesting

Well not in general

But mozjpeg can certainly be better than openj2k

Or than kakadu configured non-optimally

Somehow I missed SDL incorporating JXL. <:PepeOK:805388754545934396>

first ever partial image from jxsml (not yet transformed)

(an fjxl-compressed version of https://upload.wikimedia.org/wikipedia/commons/c/ce/PNG_demo_Banana.png)

it took me an eon to map out the general code path (how to manage all the data structure and whatnot), and I think there are some edge cases as well

I suppose you're not doing inverse YCoCg yet, or what are we seeing here?

And I guess this is just the first group?

Major milestone though, first pixels being spit out by a non-libjxl jxl decoder!

yes, no YCoCg yet, because this was a quick check (I wrote a big chunk of code and it somehow worked fine, so I wanted to see the actual pixels!)

banana

here have a spline banana

https://embed.moe/https://cdn.discordapp.com/attachments/794206087879852106/978854959124709477/banana.jxl

Lol that has an interesting look

is it from some sort of raster to svg vectorizer

yeah, I've got the banana.jxl fully decoded and matching with the original

jxsml currently prints an uncompressed PNG file in the fixed location, with a lot of assumptions, but at least this is working (for a very small set of fjxl-encoded files of course)

time to revisit extra channels

Yay, first image fully decoded with a non-libjxl codec!

https://c.tenor.com/v4FpeS4fxBUAAAAM/celebration-celebrate.gif

at this point jxsml weighs 2500 lines of code 😉

Now of course there's a lot of stuff that still needs to be implemented, but you can add one thing at a time

Doing the rest of modular shouldn't be that much extra work, it's mainly getting extra chans right, unsqueeze and palette. The channel list changes they introduce may be a bit funky though. Oh and the self-correcting predictor will also be a bit of a pain.

And then the vardct fun can begin :)