JPEG XL

(also svg exists)

Yes and for logos and things like that, squeeze is going to be less effective

yea, basically the people who want to progressively render tend not to be the same people as those that want lossless images

if you happen to want both you can turn it on

but that's the reason it's off by default

Lossless is mostly used in authoring workflows where files are local and progressive rendering is not that useful (except maybe for a preview thumbnail or something, but that can usually be done in other ways)

i think im doing something wrong

here are the files

nope, Squeeze is extremely ineffective on this sort of image

Could also be that libjxl is making some bad choices, we haven't really been looking at lossless + squeeze

that being said, if you consider a photographic image, like The Gecko

But yeah this is the sort of image that benefits a lot from things like patches and palette

``` -rw-r--r-- 1 leo leo 1.3M Mar 3 16:44 eating-insect-big-1080x720.png -rw-r--r-- 1 leo leo 879K Mar 3 16:44 squeeze-off.jxl -rw-r--r-- 1 leo leo 1.3M Mar 3 16:44 squeeze-on.jxl ```

you end up with 1.3M vs ~900k

which is still more, but not such a dramatic difference that you are seeing with your test image

(`-d 0 -e 7 -R 1` vs `-d 0 -e 7`)

-d 0 -R 1 -e 10``` JPEG XL encoder v0.10.0 ab47708d [NEON] Encoding [Modular, lossless, effort: 10] Compressed to 130.9 kB including container (1.123 bpp). 1290 x 723, 0.063 MP/s [0.06, 0.06], 1 reps, 14 threads. ``` -d 0 -R 1 -e 7``` JPEG XL encoder v0.10.0 ab47708d [NEON] Encoding [Modular, lossless, effort: 7] Compressed to 1388.0 kB including container (11.906 bpp). 1290 x 723, 1.652 MP/s [1.65, 1.65], 1 reps, 14 threads. ``` something in e10 does something big

(with my image)

I'm using -e 7 since I think that's a good way to measure real world stuff

yeah i mainly also use e7 for most things

Not entirely sure what e10 is doing here

that said, 1.123 bpp for your test image is okay

but `-e 7 -d 0` without `-R` is still 0.473 bpp

at least on my build

same

so that's still more than 2x the size. the image you provided is an example of where squeeze does very poorly, losslessly

`-e 10` then gives 0.373 bpp

squeeze is best at photographic content and worst at synthetic content like screenshots of text, or logos with hard edges

it's based on a modified Haar transform

basically it uses wavelets

but is Squeeze used in the modular section of lossy jxl?

I don't believe it is, but I'm not sure

it could be, but if you need stronger responsiveness, you're better off using LF Frames

LF frames?

the 8x8-downsampled image is encoded as a modular image

but the JXL bitstream allows you to encode it as a vardct image instead

using something called "LF Frames"

and then that vardct image then has another LF frame?

so you have 8x8 then 64x64 or someting?

in theory you can have 0-3 LF levels but more than 1 is rarely important

ig you probably wouldn't need 512x512 downsample :/

basically, instead of encoding the LF-image (i.e. the 8x8 downsampled image) as an inlined modular bitstream, instead, the VarDCT frame says "use another frame for that"

that frame itself could be VarDCT encoded

you can do this up to 3 layers

512x512 is two layers

so you can have up to a 4096x4096-downsampled version

this is possibly useful for enormous astronomical photos, like say a full-resolution hubble ultra-deep field

the LF Frame itself can be VarDCT-encoded, and its modular sub-bitstream can have its own LF Frame

that's the gist of it

makes sense

it's a more useful technique for super responsiveness than squeezing the modular bitstream

this format is way more variable than i thought when first starting using it

yea, a lot of it is like putting legos together

for example, the encoder I wrote called hydrium, achives ultra-low-memory usage by encoding one 256x256 tile as its own image frame

and tells the decoder to just tile them together

what if the decoder doesn't support multiframe images?

it has to by specification

they're used in frame blending

apple jpeg xl only supports 1 frame

I'm not talking about animated JXL

like animations don't play

multiple frames are a core part of even still-image JXLs

can you send a test image just to make sure apple decoder is compliant?

it uses libjxl internally so I'd be surprised if it doesn't work

LF Frames, Patch frames, and alpha-blended frames are all coding tools that are core to compliance

here's an example, if you'd like one

test this on an apple device

it looks like a lizard or something

that's what it's supposed to look like

here's the jpeg

discord should render it

i think it's working

yea, the image tiles themselves are fairly small

if rendered only one tile, you'd know pretty clearly

fwiw, that lizard in a lot of my test images are photographs I took of my gecko

I'm giving anyone explicit written permission to do anything with them with or without attribution

his name was George in case that's relevant

(he died in september 2021)

CC0?

sorry

well not explicitly but yea

basically, some countries like the United States, where I live, have a concept of public domain where you can irreversibly give up copyright to something

this happens by default for things old enough. like Thomas Jefferson's diary is public domain

(death + 70 years)

isn't CC0 public domain?

it does say it's public domain in places where it exists yea

some countries, notably in the EU, don't have this concept, so you just say "you can do anything you want with this for any reason" and that serves enough of a purpose

not quite, it’s “whatever is the closest possible locally”

The Ants on a Dandelion is another photo i took that I explicitly CC0ed

my understanding is that if you were to just say “I put this in the public domain” in a country where you can’t just do that, the net result is that you end up granting no rights at all (since your declaration is invalid)

yea

https://commons.wikimedia.org/wiki/File:Ants_on_a_dandelion.jpg

that's why images like this are CC0ed instead

this is the purpose of e.g. this segment from the licence: > Should any part of the Waiver for any reason be judged legally invalid or ineffective under applicable law, then the Waiver shall be preserved to the maximum extent permitted taking into account Affirmer's express Statement of Purpose.

so basically "if you can't do public domain, do the closest possible"

?

yea that

only thing with CC0 is im guessing you can't say it's your own work can you?

yea basically when I publish this photograph I took under CC0 I'm saying it's public domain in places where that's a thing and I grant anyone the legal right to do anything with it, without my knowledge or consent, for any reason, in places where that's not a thing

like say "hey i took this"?

there's actually no restriction on that

oop

"you can do anything you want with or without my knowledge or consent, for any reason" means that

if someone else claims to have created that photograph that I took, I have no legal right to tell them to stop under copyright law

I have given that right up

however, if someone is making that claim and it's *fraudulent* that may trigger fraudulent sales laws but it's not my say or responsibility

like if someone tries to sell a photograph I took and CC0ed, and claims they took it themselves, that's fraud. but it's not copyright infringement

it's just lying about the product you're selling, which is an unrelated part of the legal system

so its like you say "everyone and nobody owns this"?

public domain does not mean everybody owns it

it means nobody owns it

someone else can sell it, and if they don't defraud someone, it's not illegal to do that

so no copyright infringement?

that's correct, that's not copyright infringement

lol

also that was a dm to an alt so i didn't actually do that

this was actually a legal case where stock photograph websites were selling this photograph

https://upload.wikimedia.org/wikipedia/commons/thumb/9/9c/Lunch_atop_a_Skyscraper_-_Charles_Clyde_Ebbets.jpg/1024px-Lunch_atop_a_Skyscraper_-_Charles_Clyde_Ebbets.jpg

It's a famous photo taken in 1932

https://en.wikipedia.org/wiki/Lunch_atop_a_Skyscraper

there's an article about it on wikipedia, etc.

were they allowed to sell it?

there was some controvery where shutterstock was selling it

they're allowed to do that, provided they don't make false claims

so as long as they don't say they took it or something its fine?

"you can do anything" means "you can do anything" provided that thing isn't illegal. obviously I can't grant someone the right to break the law

ok

so don't use the image as part of a malicious exploit chain or something

https://www.gettyimages.com/detail/news-photo/while-new-yorks-thousands-rush-to-crowded-restaurants-and-news-photo/515612650

you can buy it from getty images for 500 USD

even though you can also jsut get it on wikipedia

lol

it's not illegal for them to do this provided they do not lie about it

that would be fraud

Well, you still probably do under most EU jurisdictions. Even with CC0.

(pedantically, rather than copyright we have "author's rights", which encompass a lot more than just economic rights.)

🤔 well it seems to have a 0 or near-zero effect on file size then

We designed it this way so we can be sure that all compliant decoders can do those things. As opposed to the usual approach where the core codec just encodes samples and it is left to the application layer to make sense of it, which often doesn't end up happening and then you cannot rely on it if you want full interop.

Really funny if you did

With lossy modular is it the residuals that are being quantised or is something about the tree quantised (leaf trimming or something?)

Residuals

So kinda like a vardct layer?

not sure what you mean

Like VarDCT quantisation

that works in completely different ways

why is https://github.com/libjxl/libjxl/issues/3348 tagged as unrelated to 1.0

the library crashes when you request sRGB from an HDR image

I don't see how defering that bug fix makes sense

agreed if the issue is in libjxl (which I assume it is). If it would be only some issue in djxl, maybe it's less urgent, but still it should probably be fixed for 1.0

what is it supposed to do in that situation, tone map?

at the very least, gamut map

libjxl doesn't run peak detection but it should gamut map

I generally take it that all issues get set as unrelated unless proven serious and pointed out

Streaming output shouldn't have any effect, as far as I understand it. It just writes the file a group at a time instead of all at once, with the same data in the end

ah okay... well, streaming input seems to have almost no effect either (except on speed at e 10)

That's because it does essentially the same but for the input, with e 10 loading the entire image at once instead

yeah but e 10 gets locked to like 2 or 3 threads without forcing streaming

Yep, which is why it's also called 'old e 9', because it's the same as normal e 9 but without streaming (I think)

well it's still different from the new e 9, even if you force streaming on it

i think im doing something wrong, using `--progressive_dc=1` makes it so that i need to load **more** of thie image before `djxl` finds a preview image

How does the filesize compare to without?

150kb vs 160kb

No, I think it's libjxl being not as progressive as it could be. It waits for the main frame's DC groups before showing any DC, while it could already start showing stuff while decoding the DC frame... Maybe open an issue about it, it won't be a high-priority bug but it is something we should eventually fix.

maybe libjxl is ignoring pass information of LF frame

Issue has been open a while https://github.com/libjxl/libjxl/issues/3296

C++ is wild sometimes

```c++ std::vector<std::vector<float*, std::allocator<float*> >, std::allocator<std::vector<float*, std::allocator<float*> > > > const&, ```

```cpp template<typename T> using allocating_vector = std::vector<T, std::allocator<T>>; allocating_vector<allocating_vector<float*>> const& a; ```

yea, it makes sense

it come from a crashlog from libjxl, I just thought it was amusing

fair enough, its a funny type name

Unfortunately this one is still pretty tame

yea, recursive template substitution can produce some cursed types for example

my favorite one is Java enum types

```java public abstract class Enum<E extends Enum<E>> implements Comparable<E>, Serialable { } ```

im glad i stopped working with java years ago

all java enums are actually subclasses of `java.lang.Enum`

so if I do something like

```java public enum Planet { ```

it's actually `Planet -> Enum<Planet> -> Object` in the compile-time hierarchy

(generics are erased at runtime due to Type Erasure so at runtime it's just `Planet -> Enum -> Object`)

just wondering what program is used to generate the images on the left (like find the vardct blocks)? https://www.youtube.com/watch?v=sflaIZ29e_Q

benchmark_xl

jxlatte can also render varblocks if you decode with `--draw-varblocks`

though i believe this was done with benchmark_xl

for example, like so

I am curious about something. I keep seeing demos of generation loss in JXL’s lossy mode compared to other formats, and it seems very minimal. How does it do that? Is the encoder just really good at noticing the compression artefacts of the input image and recreating the same process that led to them instead of doing something different? Does it become “stable” in a way?

<:JXL:805850130203934781> is far from perfect when it comes to generation loss; it's more that other formats are just particularly bad at it

it's still a welcome improvement though <:BlobYay:806132268186861619>

What makes a format good or bad at it though? Does a format which is good at avoiding it fall into a local minimum or something?

I just run tests be encoding an image, decoding that, then reencoding, etc., usually up to ~100 times or so and then look at the results and see how they compare to the first encode

JXL is definitely better than others, but there are still spots in images that can degrade substantially

If you're looking at Jon's old videos, they are very optimistic and not representative of current libjxl (see https://discord.com/channels/794206087879852103/803645746661425173/1197491887393755136 or `in:benchmarks has:video` in general). You can probably make an encoder with low generation loss disabling some tools which propagate distortions across the image, or generally tune loss to accommodate reencodes, but current encoders aren't doing anything magical.

yeah it's basically test, tune, repeat

here's an encode I did with an old libjxl, first gen: https://cdn.discordapp.com/attachments/673202643916816384/917339173625675786/bunnies-00001.jxl?ex=65f8022e&is=65e58d2e&hm=a1831520cc3173db7c82525af52cb500bc5acbd1256a303d579d28e4f3f4ddb6& ...and 120th gen: https://cdn.discordapp.com/attachments/673202643916816384/917339341456564274/bunnies-00120.jxl?ex=65f80256&is=65e58d56&hm=e566f242447d31f7e6bf095fc67516a1f3e0481a04e092ebd9cc127736ff2c92&

I mean, considering that is 120 gens of encoding, that's certainly not bad 😅

libjxl being perceptually optimized may play a role here, not sure

Encoders which apply filters across the whole image, rather than keeping distortions to some locality, can degrade particularly quickly.

https://github.com/libjxl/libjxl/blob/main/tools/demo_vardct_select.sh

in modular mode block weight might be preserved since the first encode and leveraged in future passes

man, I have some weird files... not only is webp's lossless smaller than all levels of jxl, but its smallest is at `z 3` <:WTF:805391680538148936>

~~643~~ 670 images ``` Pareto front for user+system time and size |Pareto front for real time and size mean Mpx/(user+system s)||included in 'all' mean bpp mins unique mins mean Mpx/(real s)best of 4.39958847 100.00% ···· 0.2100912 0.2100484 UR· all 4.40349437 79.70% 78.81% 0.3051652 0.3050352 URA cwebp_1.2.4_z9 4.49514314 9.25% 6.12% 3.74702 3.74811 URA cwebp_1.2.4_z8 4.52124923 6.57% 3.13% 6.63647 6.63570 URA cwebp_1.2.4_z7 4.53955333 2.24% 0.75% 7.70769 7.71461 URA cwebp_1.2.4_z6 4.55472840 2.69% 0.75% 8.72237 8.69632 URA cwebp_1.2.4_z5 4.57174140 2.84% 1.04% 9.02545 9.02809 URA cwebp_1.2.4_z4 4.57620796 2.69% 1.64% 9.23825 9.23381 URA cwebp_1.2.4_z3 4.72031097 3.58% 2.69% 11.3586 11.3572 URA cwebp_1.2.4_z2 4.89731172 1.19% 0.45% 14.4591 14.4299 URA cwebp_1.2.4_z1 5.59301326 ····· ···· 30.772 30.444 UR· cwebp_1.2.4_z0```

sure, but did you compare them to jxl?

``` Pareto front for user+system time and size |Pareto front for real time and size mean Mpx/(user+system s) ||included in 'all' mean bpp mins unique mins mean Mpx/(real s) best of 3.97564906 100.00% ···· 0.058516653 0.067390140 UR· all 4.08271079 68.06% 67.76% 0.1702559 0.1835379 URA cjxl_0.10.1_d0e10 4.19361574 3.73% 3.43% 0.4661693 0.9185732 URA cjxl_0.10.1_d0e9 4.25978872 1.34% 1.19% 0.7629193 1.525089 URA cjxl_0.10.1_d0e8 4.37865952 0.60% 0.60% 1.68391 3.50931 URA cjxl_0.10.1_d0e7 4.40349437 18.96% 18.36% 0.3051652 0.3050352 ··A cwebp_1.2.4_z9 4.49514314 2.39% 0.60% 3.74702 3.74811 URA cwebp_1.2.4_z8 4.52124923 2.54% 0.60% 6.63647 6.63570 URA cwebp_1.2.4_z7 4.53955333 1.49% 0.45% 7.70769 7.71461 URA cwebp_1.2.4_z6 4.55472840 1.19% ···· 8.72237 8.69632 UR· cwebp_1.2.4_z5 4.56345308 ····· ···· 1.97572 4.25842 ··· cjxl_0.10.1_d0e6 4.57174140 1.64% 0.60% 9.02545 9.02809 URA cwebp_1.2.4_z4 4.57620796 1.19% 0.45% 9.23825 9.23381 URA cwebp_1.2.4_z3 4.66748403 0.15% 0.15% 2.26227 5.01991 ··A cjxl_0.10.1_d0e5 4.72031097 2.84% 2.09% 11.3586 11.3572 URA cwebp_1.2.4_z2 4.89731172 0.60% 0.15% 14.4591 14.4299 URA cwebp_1.2.4_z1 5.03576491 0.45% 0.45% 3.26335 7.50953 ··A cjxl_0.10.1_d0e4 5.42554725 ····· ···· 5.67879 21.207 ·R· cjxl_0.10.1_d0e3 5.59301326 ····· ···· 30.772 30.444 UR· cwebp_1.2.4_z0 5.72045380 ····· ···· 8.5257 24.701 ··· cjxl_0.10.1_d0e2 6.30480646 ····· ···· 41.425 48.159 UR· cjxl_0.10.1_d0e1```

I had f'd up a few timings (10 images), so I fixed that. z0 didn't find any mins after all.

new e8, even with `Revert palette transforms` almost the same as the old non-streaming e7, even a little worse on photo-like images <:Thonk:805904896879493180>

and sometimes the difference is about 1% on average on a large set, so i even thought i did something wrong, but nope

weird that you got so many wins with e 10

but I'm assuming you weren't using streaming input/output?

how many threads is this? 4?

interesting that webp is still on the Pareto front — what kind of images are these? nonphoto, judging by the bpp...

without graphing it's hard to say it's actually on the front

on average, in my testing, it wasn't even close

but cjxl was also using ~2200% CPU while webp (at best) was 200% 😆

I say it every other week, but I wonder how much is pallete sorting

We should get a corpus of images where webp does better and basically check what it is doing to see what we need to do differently in libjxl... There isn't much that webp can do but jxl cannot, but there are some differences (like planar vs interleaved, tiling vs nontiled, etc). In general we should be able to do whatever webp is doing (and more), but probably the current jxl encoder is still making some bad decisions (like using a palette when it shouldn't or not using it when it should, etc)

I want to play 🤘 but do you have an existing repository of difficult images to which people can contribute?

<#1187313089612369991> has some stuff

yeah, webp palette ordering probably also more efficient for such images

this also fixes some, but still not much and only for e8+ https://github.com/libjxl/libjxl/pull/3373

I'm happy to upload all of my images where lossless webp does better

will take me a while to upload (as some of them are quite large res), and keep in mind I only tested with streaming I/O on

The new -e 10 is sometimes worse than the speed enhanced -e 9

because streaming sometimes gets better results than non-streaming

I kept the default streaming settings.

It's basically greedy local optimization vs greedy global optimization. Cannot say which will be best.

Default is to use streaming up to e9, no streaming at e10

So that explains it. -e 9 also seems to better utilize CPU threads.

yeah, but you can force streaming with e 10 (which is the only way it's remotely practical IMHO)

What is the actual difference between streaming and not streaming?

Is that the streaming mode better uses the available resources?

streaming is encoding in independent blocks, non-streaming is the whole image

So in non-streaming mode, the encoder has access to more information to work with, right?

yeah

Maybe I'm too cautious, but I always verify the losslessly encoded files by decoding them and comparing with the input.

has anyone else noticed very large sizes when using faster_decoding={1,2} with lossless? faster_decoding={3,4} seem to work fine `cjxl -e 6 -d 0 --faster_decoding=$FASTER_NUM png/{0} jxl/{1}.jxl`

i did around 0.9.2

folder of original pngs with alpha: 679mb jxls no fast decoding/0: 360mb (expected result) jxl fast decoding 1: 1390mb (!) jxl fastdec 4: 614mb

yeah im testing something similar, im still encoding fasterdec3 but in 75% of the way through and it looks normal ```ps jxl-sequence dua 2.48 GiB jxl-nofast 4.51 GiB jxl-fast4 7.41 GiB png 25.65 GiB jxl-fast1 40.89 GiB total ```

oh no... not having streaming input support for image types other than ppm/pgm is a much bigger deal than I thought

as there's no way to use streaming input on images with alpha then <:FeelsSadMan:808221433243107338>

yeah

speaking of which, is there an easy way to identify if an image has an alpha channel or not? (without looking at it, i.e. with a CLI utility)

I'm sure imagemagick has a way but I don't feel like wading through its documentation again

okay, `identify -format %A <image.foo>` will do it, with `Blend` meaning it has an alpha channel, and `Undefined` means no alpha

open in xnviewmp (crossplat), in 'image' it shows the option to remove or alpha channel only if one exists. in 'view', you can hide or display the alpha layer

isn't imagemagick pretty cross platform? <:Thonk:805904896879493180>

Issue #2995 highlights the need for example files with all the edge cases like that, so programs can be reliably tested

edge cases like what?

large boxes

Hmm, this seems like a very fun bad idea

is it ppm? <:Thonk:805904896879493180>

also is that openttd?

Either BMP or PNG, and yes

Ironically the game actually has a wiki page explaining that 8bit PNG is best... Then saves PNGs in 24 bit anyway

So pallete, with tiles and text, and large resolutions. Seems made for JXL, eventually

well, save it as bmp

Any reason why?

because good luck having a png compressor not die when trying to compress that

actually does bmp even support that res?

The encoder uses 8,192 byte chunks, can see from checking a sane screenshot, main issue is filesize due to that 8KB limit

8KB limit?

It will only compress 8Kb at a time, so duplicate data will rapidly pile up

generic image? imagemagick identify can do that

read above ⤴️

ye, but if you have a specific type it's easier

type?

like png, jxl, etc

I don't know what the type will be, that's the thing

ah

this is for a script to convert any image into the smallest lossless size, looking at either only jxl, only webp, or both

of course there's still the odd image that is better than both of those in xz, but I don't bother checking that as that's quite rare and inconvenient to use even if it is the smallest

do note that if you convert to png first and run optipng with some fixed options itll strip an unneeded alpha channel

i.e. constant-1

may be worth considering

let me put it this way: if the image already has an alpha channel, I always want to keep it

ah

why do you need to detect it then?

out of curiosity

because I would normally convert anything that isn't ppm/pgm into ppm first, so that I can use `--streaming_input`

but ppm doesn't support alpha, so I need to use png

pam does

does streaming input not work on pam?

it doesn't *say* that it does: > --streaming_input > Enable streaming processing of the input file (works only for PPM and PGM input files).

but it might 🤔

test it. may be a documentation error

not sure exactly how I verify that though as I think it falls back to not using --streaming_input (if you give it that option on something it won't work with)...

but let me check

Oh, no, it actually does error if you try and use that with png. Let me try with pam then...

if it's explicitly enabled and refuses it should error, not silently ignore

GIMP doesn't understand pam? <:WTF:805391680538148936>

nor does nomacs...

ffmpeg my beloved

sure would be nice if I could actually verify the decompressed image is even accurate

> PNM decoding failed. :c

yeah, streaming input doesn't support it anyway so what's the point?

well I suppose it still saves me from encoding the intermediate png

at least my script should handle pretty much every case now

What’s the difference between the p*m formats?

i5-13600K, unlimited threads. cjxl cannot exploit threading so much with smaller images, and there's plenty of content outside photo where webp is competitive with jxl.

I intend to break this out by category in the next Irresponsible! Computing? I just didn't see it as a priority for the last one and wanted to be done

I don't really want to redo all my timings on 0.10, but I feel like it's prudent

or whatever, I can just post the timings from 0.9 tonight

it will just remain useless to Orum <:PepeOK:805388754545934396>

the original, portable bitmap, or pbm, is black and white. 1-bit portable graymap, pgm, is grayscale, and ppm, portable pixel map, is rgb

pam is portable anymap. it can do all of those, plus alpha

pfm, portable floatmap, looks like other netpbm formats but it's a bit different

and came way later

and there are unfortunately multiple pfm formats in existence, though the current winner is one described in the netpbm distribution

Jon how is the quality of those images I generated on cloudflare

Space, Tesla.

Real image without ia

Only neural compression

We are in a point when we can encode desideria videos at 7mbps 50fps but it looks good to subjective score minimum

Perfect metrics upscaling look boring

LIAje like

is there a reason piping input can't work with `--streaming_input`?

Probably because the size might not be defined I’m not 100% sure

size is defined in the header though

all I'm suggesting is to see the Pareto front you want a graph like this: https://discord.com/channels/794206087879852103/803645746661425173/1211973220798828625

I was referring to this comment https://discord.com/channels/794206087879852103/803645746661425173/1213471872315035658, but decided to just post results for default settings https://discord.com/channels/794206087879852103/803645746661425173/1215268764711649340. RE: "it's hard to say it's actually on the front"--I don't understand, given I provide the relevant numbers and mark the optimal settings in the table.

the front looks at two things: compression level and speed; it's hard to see both at the same time on a table of numbers, but trivial on a graph

well, anything is on the pareto front provided it isn't dominated by anything else

if anything else beats it in both compression *and* speed, then it loses

you can easily see if something is dominated by sorting the table

but you're only sorting by one thing at a time

so if you sort by speed, you have to then compare the compression numbers, or if you sort by compression, then you have to compare the speed numbers

sure, but if you sort by, say, speed, then you just look at everything faster and see if any of them also beat it in ratio

it's not a hard comparison to do

it's much easier to just graph it and you can instantly see the front

sure, but it's not exactly a difficult comparison when you have like ten entries in the table

another easy method is to sort by speed (ascending) and then sort by ratio (descending)

and the diffs between the sorts will be where things are not on the pareto front

yea, also keep in mind that non-monotonicity is what you're looking for

so, like if you sort by speed, in column A, then in column B, with ratio, will be monotonic if everything is on the pareto front

if something isn't, then that's where you have an increase and then a decrease

so like, as things get slower, you'd expect a ratio to increase, but if it ever decreases (or remains the same) you've found an issue

and it's not hard to eyeball that

I don't remember if I already asked that yet but, did the spline ever demonstrated its ability to save bytes ? I heard it was designed to draw hairs, and I understand that the encoder can't use it yet (which is fine) but was the concept validated with a prototype (even manually made) which showed that for some real case pictures, splines can help compress better ? or something else ? or was it just an intuition that it could be useful ?

yes, a few crops where I manually hardcoded some splines in the encoder

can we see one ? just curious 🙂 if not it's ok

what is encoded below the spline ?

I don’t have them at hand right now but I’ll try to remember tomorrow (not sure whether they will still be usable)

XYB(image) − spline

ah true, splines are blended on top, not perfectly opaque, I forgot

the concept is that you look at the pixels, you create a spline that matches a hair strand, and then subtract the rendered spline from the image

and then encode the subtracted version

the decoder renders the spline and adds it back on

no need to hurry but if you find an example, I would be glad to see what it looks like

I think the code that subtracts from the image is still there, actually

(or did we drop it?)

one of the reasons splines are additive rather than replaced is that they taper out along the edges

so if you add a spline atop something, you end up with a smooth transition

they fade to zero slowly

ok

right, it is, it’s just that ```c++ Splines FindSplines(const Image3F& opsin) { // TODO(user): implement spline detection. return {}; } ```

(“user” is me, scraped)

I still feel like it would've been better to do that taper in the alpha channel and then do a regular alpha blend, rather than adding.

what is the profile of the fade out ? e^(-x²) ?

you still have the boundary-of-the-spline issue

splines theoretically cover the whole image. the magnitude decays exponentially with distance from the spline

in practice, decoders just choose to stop below a certain threshold

if you had done that taper in the alpha channel, you now have both that exponential decay in the alpha channel and the question of magnitude in the XYB channels

it complicates matters quite a bit

Hmm

I don't quite remember but I think it's Erf

it is exp(-x²) iirc

erf was just used to compute the integral of that over the pixel

ah

Ooh

(I know, “over the pixel” is not really a thing given that a “pixel” is theoretically a point sample – just imagine photosites with 100% fill factor like on a camera, which is effectively like a box filter followed by point sampling)

Thanks! Not hairs but and interesting application nonetheless 😊

At the perfect center of the spline the opacity is 100% or anything else specified?

it's not alpha blended, it is added to the XYB. So something like a spline with constant color X=B=0, Y = -0.1 has a darkening effect but you'll still see what's "underneath"

Until you "saturate" a channel? If it make sense? Back in rgb it can't go below zero?

But perhaps this make no sense in an hdr world

out of range colors in RGB typically represent out of gamut colors

well if you go into negative Y it's blacker than black and will just be clamped to black when converting to RGB

In this case, it could be used for ink stroke of mangas... Perhaps

even without relying on clamping it could be used for that

does lossy modular have any real use case?

Very high quality lossy or non-photographic content can look better with it

Conpared to VarDCT there's not much reason to use it except at extremely low distances, like between 0.01 and 0.03

I reckon a port of webp's "near lossless" would work quite well

I disagree; it's quite useful on non-photo

wait so is it like webp's near lossless?

I'm sure they love all the pings :P

depends on what you mean by "non-photo"

for things like logos and that sort of thing, it's pretty bad because squeeze is very bad at that

no, it's a bit different. webp "near lossless" runs a lossy pre-filter and then just uses its lossless mode

I don't think anyone is talking about Squeeze

Squeeze is enabled by default for lossy

that's what happens when you use lossy modular tho

here's a perfect example of where I think lossy modular does better than VDCT

that's `-d 2` for modular and `-d 2.98` for VDCT (in order to get similar BPP)

so yeah, it's not hard to find examples for non-photo where lossy modular makes sense

why is there such a big gap in BPP in VDCT between -d 2.999 and 3.0?

``` Encoding [VarDCT, d2.999, effort: 7] Compressed to 364.2 kB (0.351 bpp). Encoding [VarDCT, d3.000, effort: 7] Compressed to 341.1 kB (0.329 bpp). ```

most likely because some features enable at >= 3.0

was this at `-e 7`?

do you have the original?

yeah, 1 sec

lossless original ⤵️

<@548366727663321098> looks like this is because using modular enables a patch frame

this could be done with VarDCT, it just isn't, for some reason

in any case, there are definitely reasons to use lossy modular at times

this instance is one where all the savings you're observing with modular are due to the patch frame

are patch frames even possible with VDCT?

yes, identical method of coding

patches are stored in a separate frame (typically lossless modular) and then there's a bundle in the LFGlobal section that tells you where to copy them over

in this case, test-vdct isn't doing that, and I'm not really sure why

may be worth opening an issue about it

well I'll let you do that as you know much more about it than I do <:BlobYay:806132268186861619>

as in like the same use case as webp near lossless

also can i get better efficiency by turning off jpeg auto-transcoding and decoding to pixels then encoding using VarDCT?

depends on what you mean by efficiency

doing this will incur some level of generation loss because the jxl encoder will attempt to preserve the jpeg artifacts

if the jpeg is very high quality, this will be a nonissue

and is preferred

otherwise I wouldn't

The way I see it, JXL has a bunch of coding tools, and a lossy encoder can use whichever ones make sense. And libjxl simply happens to use squeeze when you ask for lossy. Though I was wrong and Orum was in fact talking about Squeeze.

sure, but libjxl has only two tools available to it to do lossy modular, which are squeeze and delta palette

the encoder can do anything it wants, with the goal of the image file being as small as possible and the decoded image as close as possible to the original

I don't think squeeze and delta palette are the only coding tools available that would be useful for such an encoder.

Say, something like pngquant but designed for what jxl has to offer, rather than just plain quantization.

just good use of delta palette would probably be pretty great though

I'm referring to libjxl in its current state, not the theoretical prime of lossy modular

I agree that in theory it could be different but at the moment those are the only things libjxl has to work with for lossy modular

I felt that I had already acknowledged libjxl's current state, sorry.

so that "sure, but" confused me a bit I think

Apparently YT Is testing live video re encoding

And how is that related to JXL?

Cloudinary is still working on jpg

Jxl is a lot of Activity

<@853026420792360980> since you have some experience with jxl implmentations, if I wanted to make a toy encoder to test different strategies, how much work do you think it'd be from starting to having minimal modular encoder?

a decent amount because implementing an entropy encoder is hard

aye

a trivial passthrough encoder isn't hard but that won't actually be very helpful

that said hydrium's entropy encoder is mostly self-contained so you can always use the code from it

hm. I wonder if it would be worthwhile to port the entropy coding from libjxl to a standalone library, so that it could be re-used in other encoders

oh heh. Yeah I'll check that out as a first stop once I get to entropy coding :)

I personally find the part that codes the distributions to be the most annoying one to reproduce 😄 the rest is relatively simple

it was difficult to figure out how the hybrid symbol residues worked with ans state flushes

with the whole, reverse thing

also how to invert the alias table was nontrivial

essentially the way I did this was I hybridized all the symbols into residues and tokens, and then sent the tokens to the FSE one at a time, and for each state flush I tagged what index it occurred on and then cached it

so then when I wrote the state flushes in the inverse order, I knew where to put the hybrid residues

an issue I ran into when building prefix trees as well

brotli prefix trees have a max tree depth

so if you build a huffman tree in the conventional theoretical way, you end up with symbol lengths that can exceed the max symbol length

it required a bit of math on my part to figure out how to fix that

Are there any mainstream viewers that can actually display additional channels such as depth, etc? What about pages from multi-page JXL?

animated jxl viewers should theoretically be able to do that if paused

yes a viewer that can display them will display them

<:trollface:834012731710505011>

Is reversible internal colorspace conversion to YCoCg-R or something similar used for lossless compression of RGB sources in JXL or WebP? It should have some benefits on most sources...

Yes, it is used in both.

At some point, it was possible in cjxl to specify different bit depth for color and alpha using sBIT chunk. Now alpha always has the same bit depth as color. Was this change deliberate?

there's actually 42 RCT (reversible color transforms) in JXL

there's 7 different types, and each one may be followed by a permutation of the three color channels

(since there's six permutations of 3 elements, that's 7x6 = 42)

So it was a deliberate change: https://github.com/libjxl/libjxl/commit/ed6eb09bd23226db3dfdd828c359f61a8d39ddac

Have different bit depth for alpha caused any problems?

Actually, jonsneyers added the feature, because extra channels can apparently use different bit depth than color channels, but eustas removed it right away 😄

Maybe that would be best as part of this discussion https://github.com/libjxl/libjxl/issues/3415

There are legitimate use cases, where alpha could be encoded with 1 bit depth. GIF is a typical example of 8 bit RGB with 1 bit alpha. Also PNG with tRNS chunk consisting from just a single fully transparent entry.

I could be wrong, but I thought cjxl only goes down to 8 bit at most and then uses pallete for any lower? Or at least that's the case with a 4 bit image I tested a while ago

JXL probably uses palette internally for low color images but tRNS can be used for 24bpp images as well.

JXL can go as low as 1 bit in all channels and these will decode either to 8 bit PNG or PNM with the actual bit depth.

Although this applies only to Modular as VarDCT decodes only to 8bit, 16bit or 32bit.

So libjxl apparently can do bit expansion if needed so I don't think alpha in lower bit depth would be a problem.

is there any way to tell what depth a jxl image is with djxl?

oh, nvm, there's `jxlinfo` 😅

interesting, with 0.10.2 I'm getting a lot more wins from effort 10 than 9 compared to 0.10.0... but I suppose that's from the change to e 9 in 0.10.1

djxl from git main reports v0.10.0

even though git main should be more recent than 0.10.2

any idea why?

cjxl also

apparently the version macro bumps were never ported to main

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

so I just sent a PR to fix that

yeah, except that git binary releases have the correct version

looking like bench_oriented_brg5 is failing

not sure why

that's only on scalar asan

as is alpha_not_premultiplied

most of them are passing, but on scalar_asan some are not for some reason

is it because of UB?

I built from source and the version is correct: ```cjxl --version cjxl v0.10.2 [AVX2,SSE4,SSE2]```

djxl too: `djxl v0.10.2 [AVX2,SSE4,SSE2]`

<@184373105588699137> do you happen to have that HDR Blender image you were using a while ago on hand? I can't find it in this server's message history - I believe it had a 10000 nit peak?

nevermind, found it

running this *exact* same command with libjxl 0.10.2, I get a different looking output when viewing the image in Thorium

here's the new one

and the old from the original thread