JPEG XL

Gotta do it then <:KittyLaugh:1126563616343216268>

For the extra pizza points of course

I wish I knew from what server come your cat/fox emojis <:PepeHands:808829977608323112>

My own private emoji dumps <:Rays3:686219917120634881>

0.o

And there's... many of them XD

Do some lossy on the jon Sneyers site

RANDOMYL to do some aomedia damage leaded by a single autistic Man to Google

I worked on s9 avif

Finished the benchmarks

Low bpp 0,130bpp

okay I think I found it you did go further than just `-b 13` since there's no upper limit <:KekDog:805390049033191445>

Does that make a difference?

Tried 13 and 23 and the output was excactly the same <:KekDog:884736660376535040>

AH

sometimes it makes a diff

Nice. However, that's not what I did <:KittyUwU:1147753612529913938>

well then I didn't found anything tried all combinations of `-i` `-i -1` never used `-j` bc that'll break the JPG and `-t` does not change anything of course Either you used `-j`, or a `jpegtran` that's better than mozjpeg's one <:KekDog:805390049033191445>

<@1051137277813870592> remember also this person who has lead to test jxls

If you really want to know... then you know what to do <:KittyPizza:1147750033018605680>

I give up 😭 this is the smallest I could reach `1129211` bytes with `-j` lol

6 hours of burning my CPU to not find how you did this

tried even with regular jpegtran

Soooo, pizza time? <:FoxPizza:785013250914779176>

i guess so <:PepeHands:808829977608323112>

Pizza when? <:foxstare:1213161230114758756>

when you come to my place <:KekDog:805390049033191445>

Damn, so no pizza soon then <:KekDog:884736660376535040>

that lets me some time to retry to compress the file <:KekDog:805390049033191445>

let's read the perl script in depth Ig

Poor CPU <:RaysShock:686219918030798921>

since you said you used only jpegultrascan the only thing that is possible is that you used another jpegtran

I won't spoil my secrets and will keep watching you become the number 1 cause of global warming <:KittyUwU:1147753612529913938>

says the guy optimizing hundreds of file to gain every single byte <:KekDog:805390049033191445>

Shhhhhhh

~~Not like you do the same thing or anything <:KekDog:884736660376535040>~~

Heres way more concentrated and with Noisy

Yes

How is svt av1, do you work on svt also or in the psy101 aomenc?

only psy101 for now

*for now* we'll get em eventually ;)

I've been compressing since the sun rose, and now it's 9PM, but it's finally done... Tried compressing 25 textures out of a Blend file, a few 8K textures along with smaller sizes ``` Lossless Texture Encoding Test PNG 102 MB ECT --all-filters -9 89 MB WebP -lossless -q 100 -m 6 70 MB JXL -d 0 -e 1 98 MB JXL -d 0 -e 3 75 MB JXL -d 0 -e 5 71 MB JXL -d 0 -e 7 61 MB JXL -d 0 -e 9 57 MB JXL -d 0 -e 9 -g 3 -E 3 -I 100 56 MB JXL -d 0 -e 10 55 MB ``` So if Blender adds support, I can cut the storage in half

Interestingly, WebP had the exact same memory use and time spent on the 8K normal map, but JXL got 10 MB lower 49 MB PNG, 39 MB WebP, 29 MB JXL

have you tried `-e 7`? 🙂

Blender already has webp support though? 🤔

Yeah, which is why I tested it too

also, remember that `-q 100 -m 6` isn't always the smallest

it was more that "cutting it in half" is only vs PNG, and if you already used webp, JXL won't give you that sort of gain (typically)

For webp I'm using -z 9, isn't it like "smallest lossless"?

no

I've tested all `-z` levels on thousands of images, and it's not unusual for the highest level to *not* give the smallest results

Ah yeah, although I've never encountered a blend file using WebP so far, so might as well get the extra 20% with JXL, not to mention once there's some better flags/heuristics found

Ok, thank you, I will test another levels on my type of images

mine do <:AngryCry:805396146322145301>

I have some massive textures in them, so every bit of savings really helps

With a 7 year old CPU and 16 GB of RAM, I kept the test suite small so I could still do other things once in a while, the `-e 10` run took an hour and a half on the normal map alone with half of my RAM

I asked a friend for help with `-e 10 -g 3 -E 3 -I 100`, and it ran 3x faster than my normal `-e 10` but with double the RAM usage (Double the threads, higher clock and SSE4 along with double AVX2 speed)

Was half tempted to have monad run his suite of parameters on a normal map to find the best settings, since it's quite different to a regular color image

One annoying thing I realised is that the 'find external files' thing cares about extentions, so I had to install an addon to override that

normal maps are usually the smallest of textures, though roughness maps can be quite small too at times

This was an 8K 50 MB PNG to start with

these are blend files created by other people?

Yeah

ah, okay

I assume you're thinking of tiled normal maps that repeat over the entire surface?

no

roughness and normals are two different things

I know, I've just never seen a 'small' normal map that isn't tiled

normal maps are rarely tiled on objects

the only place I see them tiled is on things like terrain

One example is scales on a reptile's body, but yeah, it depends on what kinds of model you work with most

sure but then they're probably just putting multiple scales within a single render map (which is still not the same thing as 'tiling')

Multiple scales with a seamless edge so it can be repeated without noticing

But anyway, texture big, WebP small, JXL smaller

<@179701849576833024> Opinion Meta rtc

Edited it into the list

Not bad

16 seconds instead of WebP's 160

Although I imagine using more conservative WebP options would make it closer too

One thing I noticed is that `-g 3 -E 3 -I 100` improved the colored textures, but made the normal maps worse, and the reverse for using defaults instead. I should probably try to find a middleground, or just have <@263300458888691714> run a set of textures through his gauntlet to find the most optimal settings for 3D models

Huh... I would've thought decreasing group size would increase multithreading, but it actually made the encode a third slower

Also added 1, 3,5 and 'Max 9' to the list

Send me some representative files, if you like. I don't mind timing as long as they're ~1 Mpx or less, otherwise I can see about parallel encodes to optimize density alone.

I have to apologize. I guess the last round wasn't really fair for jpegli. I didn't use `djpegli` to decode jpegli jpgs in my test. Although this shows us how quickly jpegli jpgs can break if they are constantly decoded by "regular" jpeg decoders like the one in `imagemagick`.

So, another round with proper use of the `djpegli` decoder:

well that's very concerning

are the other decode libs not complying with the spec?

iirc the jpeg 1 spec doesn't really define how much precision decoders should provide

It does, but it allows pretty imprecise decoders and still calls them conforming. JPEG conformance is defined in a funky way: a decoder has to produce sample values such that when you apply the DCT on them and quantize the coeffs, the result is in the same quantization bucket or off-by-one, or something like that, if I recall correctly.

that's very... permissive

much better indeed; perhaps `djpegli --bitdepth=16` would be interesting as well (or maybe that was already it?), but I’m not sure the improvement would be that much

while we're on the topic of cjpegli, is there a reason it doesn't accept JXL input? 🤔

later, in ISO/IEC 18477-1 (JPEG XT) the de-facto subset of ISO/IEC 10918 (JPEG) was defined (i.e. JFIF + payload that is baseline/progressive 8-bit mode with huffman), and ISO/IEC 18477-4 (conformance testing of JPEG XT) defines a better conformance test for that than the original ISO/IEC 10918-2

it doesn't? for me it does

oh, I didn't test it... then the help is wrong: ``` INPUT the input can be PNG, APNG, GIF, EXR, PPM, PFM, or PGX```

Maybe open an issue for this. We should probably make some function in extras/codec.h that returns a string of supported input/output codecs (which ones those are depends on compile-time options) and use that in help screens of the various tools.

Will do. Open it on the libjxl GH?

as it's part of libjxl, seems like that's the place to do it

Yep, already with `--bitdepth=16`

Don't suppose you could include the original image in the line-up too for future? They have different forms of degradation but it's hard to tell what's most graceful

Weirdly the first frame of the video seems to be missing a keyframe too... Odd

Almost reminds me of WebP2's polygonal encoding

webp2 is dead though, and probably for the better

First and last or all 900 frames? <:CatSmile:805382488293244929>

All 900, just so you can pause at any time and take a closer look at the artefacts

Yeah, something weird happened with ffmpeg-vp9... Unfortunately, I've already deleted all the frames and the original photo.

Ah well, half the fun is playing with settings until something works

Finished full benchmarking on Midori 11.3.0

I compared with mozjpeg and only one image at a single time

That's unvalid as hall of shame site had different type of treatment

Q100 works well the problem is low bitrate q43.2 q36.44 q21.3-34.77

Those are awful

But with new release will it forensicaklty Improvee

Decided to try and fit this 28 MB HDR (7z for discord's limit) into a PNG or JXL, but the PNG is 34 MB and the JXL is 69 MB. Lossy it hits 1 MB but surely something must be going wrong to hit 69 bpp on a 32 bit input. I can even 7z the JXL down to half it's size

well what was your process

magick convert gives an 18 MB jxl

I used ffmpeg to make it into a 32 bit PFM and then cjxl with -d 0

gives me a 23 MB jxl which identifies as 32-bit (the magick-produced file identified as 16-bit)

Any settings other than `-d 0`?

nope

Ah, it's a regression since 0.10.2

``` C:\Users\jonat\Downloads>cjxl drachenfels_cellar_4k.pfm drachenfels_cellar_4k.jxl -d 0 JPEG XL encoder v0.10.2 e148959 [AVX2,SSE2] Encoding [Modular, lossless, effort: 7] Compressed to 22960.8 kB (21.897 bpp). 4096 x 2048, 1.771 MP/s [1.77, 1.77], , 1 reps, 16 threads. C:\Users\jonat\Downloads>cjxl drachenfels_cellar_4k.pfm drachenfels_cellar_4k.jxl -d 0 JPEG XL encoder v0.10.2 59637dc [AVX2,SSE2] Encoding [Modular, lossless, effort: 7] Compressed to 72278.1 kB (68.930 bpp). 4096 x 2048, 6.406 MP/s [6.41, 6.41], , 1 reps, 16 threads. ```

```100663319 d.pfm 29273625 d.hdr 24688539 d.pfm.7z 22960752 d.e7.jxl 22937905 d.hdr.7z 22605021 d.e7.jxl.7z 22505088 d.e7.jxl.zpaq 21813103 d.hdr.zpaq 21092318 d.pfm.zpaq 18532019 d.e10E3I100g3.jxl 18531699 d.e10E3I100g3.jxl.zpaq 18521955 d.e10E3I100g3.jxl.7z 18519649 d.e10E3I100g3.jxl.paq8px207```

the man-which-individually-zipped-compressed-image-just-for-the-sake-of-satisfaction.

>d.e10E3I100g3.jxl this was probably a good stopping point <:KekDog:805390049033191445>

Nah, just wait until the server with 2TB of RAM exclusively for running e11 encodes

https://github.com/libjxl/libjxl/issues/3511

FWIW ... on this set there is no difference between ideal settings

Note the settings I try are curated for my usual content. I did notice different behavior on a different set of pairs, but those were 16 bpc, 1 Mpx and I'm not bothered to go through the effort reducing them and reencoding rn. Also on some other normals I noticed the kNoWP path was favorable.

Ah, thanks. Yeah, it seems to be a unique case where the variance between each image dulls any effect of different settings

-d 0 took only 194 seconds

MacOS does not like big JXL files, it seems to not take full advantage of tiling and such

I did some extensive tests with lossy encoding, tried different distances from 0.010 to 1.000 by steps of 0.001 and computed the butteraugli score. For effort 8 in grey (vs effort 4 in red) I get a strange behavior: the butteraugli score seems capped at 0.28...

does it correspond to an hard value in the code ?

expressed in ssimulacra score there is no such step

Interesting, is this an image with or without alpha?

without I guess... It is the image 15 of the kodak benchmark, I'll try if other images do the same (but tests take some time to run :D)

Initially, I was looking for a sweet spot in the speed / quality tradeoff, whatever the speed

without ! file gives `../benchmark/kodak/15.png: PNG image data, 768 x 512, 8-bit/color RGB, non-interlaced`

I can reproduce this

benchmark_xl v0.10.2 5f57c4a8 [NEON] 12 total threads, 4 tasks, 4 threads, 2 inner threads ``` ./kodim15.png Encoding kPixels Bytes BPP E MP/s D MP/s Max norm SSIMULACRA2 PSNR pnorm BPP*pnorm QABPP Bugs ----------------------------------------------------------------------------------------------------------------------------------------- jxl:8:d0.2 393 226328 4.6046549 1.141 73.234 0.34626903 93.82546540 52.84 0.15089569 0.694822594129 4.605 0 jxl:8:d0.1 393 342656 6.9713542 1.100 56.113 0.26659861 94.69318716 57.28 0.09944881 0.693292871168 6.971 0 jxl:8:d0.05 393 529921 10.7812703 1.089 40.734 0.27091136 95.08974557 61.33 0.08716123 0.939708730372 10.781 0 jxl:8:d0.01 393 981279 19.9641724 1.157 38.276 0.26865784 95.13987048 66.10 0.08554240 1.707783313250 19.964 0 Aggregate: 393 448126 9.1171452 1.121 50.311 0.28630212 94.68559785 59.18 0.10284787 0.937678965029 9.117 0 ```

Looks like gaborish is the culprit: ``` ./kodim15.png Encoding kPixels Bytes BPP E MP/s D MP/s Max norm SSIMULACRA2 PSNR pnorm BPP*pnorm QABPP Bugs ---------------------------------------------------------------------------------------------------------------------------------------------- jxl:8:d0.2:gab0 393 223467 4.5464478 1.065 70.787 0.33846688 93.79991486 52.36 0.15223970 0.692149862797 4.546 0 jxl:8:d0.1:gab0 393 316773 6.4447632 1.077 53.574 0.20741303 94.85464509 57.01 0.08714694 0.561641385480 6.445 0 jxl:8:d0.05:gab0 393 432217 8.7934774 1.049 52.066 0.11433402 95.31268252 61.85 0.04471525 0.393202544791 8.793 0 jxl:8:d0.01:gab0 393 766964 15.6039225 1.054 40.671 0.02204305 95.56940241 74.61 0.00838248 0.130799566316 15.604 0 Aggregate: 393 391390 7.9628475 1.061 53.234 0.11533200 94.88174267 60.92 0.04722284 0.376028243275 7.963 0 ```

gaborish again 😅 It was not on purpose 😄

<@532010383041363969> I think we should either make dec_gaborish(enc_gaborish) approximate the identity function (at least as distancee goes to 0), or disable gaborish by default at low distance. It doesn't make sense to do a gaborish that introduces more error than the compression itself.

related: https://discord.com/channels/794206087879852103/804324493420920833/1092894594578010192

^ what I linked to may be an older post but I just tested and the same still happens in newer builds of libjxl

I really should have made an issue post on the libjxl repo back then about gaborish negatively affecting higher quality levels

just get rid of gaborish

it's false advertising

like the whole generation loss thing aswell

gaborish is quite useful at typical quality settings, but at the moment the encoder side is not doing the inverse of the decoder side (because apparently doing something different is somewhat better according to butteraugli), which is bad for generation loss and puts an artificial limit on the precision.

and at d << 1 there is no use for gaborish imo

it's useful when DCT would introduce very mild blocking

at very low qualities, it's not that useful since it cannot get rid of severe blocking

and at very high qualities it's also not that useful since there won't be any blocking anyway

avifenc replaced default cjxl

Frames here https://dropmefiles.com/92nqF

are you decoding to 8-bit RGB or 16-bit RGB?

``` magick -depth 16 png48: djpegli --bitdepth=16 avifdec -d 16 djxl --bits_per_sample=16 ```

is this 4:4:4 avif?

jpegli is holding up quite well here, jxl is a bit disappointing imo. I think we should tune the encoder heuristics for generation loss, until now we've done all tuning for a single generation and that doesn't allow catching subtle accumulation of errors...

I only used the `--target-size` parameter, but according to `avifenc -h` the default is 444.

when using 420 it will degenerate a lot quicker, but they wisely made 444 the default so it's only fair to use that

I wonder what the impact would be on single-generation quality

of course I don't want to sacrifice single-generation quality for multi-generation quality — I'm hoping multi-gen quality can be improved without affecting single-gen much

Maybe we can start with this: https://github.com/libjxl/libjxl/pull/3547

I think I was maybe wondering whether it might not even improve it

by now, we know that looking at quality at low bitrates is irrelevant to quality at high bitrates

but do we also know it to be the case between one- and multi-generation?

where we would plausibly be applying _the same_ artifacts several times?

intuitively I would expect that if the result after N generations improves, it means the first generation is also better.

though some of the multi-generation error might be caused by invisible errors bleeding into visible errors only after many iterations, and optimizing _only_ for the Nth generation might miss some opportunities for perceptual optimization.

Was just running some random tests on an image that seemed unreasonably large, and then thought to run ECT first related to this issue https://github.com/libjxl/libjxl/issues/3415 Original 30 MB PNG ```JPEG XL encoder v0.10.2 60dfa1b [AVX2,SSE2] Encoding [Modular, lossless, effort: 7] Compressed to 10948.8 kB including container (3.931 bpp). 6293 x 3541, 4.296 MP/s [4.30, 4.30], , 1 reps, 16 threads. PageFaultCount: 621943 PeakWorkingSetSize: 414.8 MiB QuotaPeakPagedPoolUsage: 35.19 KiB QuotaPeakNonPagedPoolUsage: 16.99 KiB PeakPagefileUsage: 457 MiB Creation time 2024/05/01 19:37:29.048 Exit time 2024/05/01 19:37:34.746 Wall time: 0 days, 00:00:05.698 (5.70 seconds) User time: 0 days, 00:00:04.046 (4.05 seconds) Kernel time: 0 days, 00:01:06.312 (66.31 seconds)``` ECT 15 MB PNG ```JPEG XL encoder v0.10.2 60dfa1b [AVX2,SSE2] Encoding [Modular, lossless, effort: 7] Compressed to 10930.5 kB including container (3.924 bpp). 6293 x 3541, 4.981 MP/s [4.98, 4.98], , 1 reps, 16 threads. PageFaultCount: 497987 PeakWorkingSetSize: 311.3 MiB QuotaPeakPagedPoolUsage: 35.19 KiB QuotaPeakNonPagedPoolUsage: 16.73 KiB PeakPagefileUsage: 351.9 MiB Creation time 2024/05/01 20:03:25.041 Exit time 2024/05/01 20:03:29.900 Wall time: 0 days, 00:00:04.858 (4.86 seconds) User time: 0 days, 00:00:03.531 (3.53 seconds) Kernel time: 0 days, 00:00:54.625 (54.62 seconds)``` So it not only reduces size slightly, but also increases speed and has a fairly drastic impact on memory usage, I'd assume mostly from removing an unused alpha channel

-d 0 for lossless but all default for everyting else

maybe learning matplotlib

the only difference between the first and second graph is the kind of picture ?

same encode params on different image sets (photo vs ui)

Made a proposal to improve precision and generation loss at the very low distances (up to d0.5) — I think it's most important to get it right in that quality range, since that is relevant for authoring workflows. Improving generation loss at higher distances is harder but only relevant for things like memes. https://github.com/libjxl/libjxl/pull/3563

at some other distances, like closer to 1.0 it doesn't give any improvement, just up to 0.5?

i mean exactly 0.5 is just some average number or is the gains mostly just up to 0.5? maybe make benchmarks like up to 0.8-0.9 and perhaps these changes would be useful at larger distances? or at least make gaborish weaker

Above d0.5 the gains from gaborish become bigger, so just disabling it would still improve multi-gen but at the cost of single-gen...

I tried making the amount of Gaborish proportional to distance but it's tricky, just scaling the kernels (for both enc and dec) didn't really seem to improve things.

I also tried retuning the enc Gaborish weights for generation loss but couldn't get real improvements. I suspect 5x5 is just not big enough to make it more accurately approximate the inverse of dec Gaborish.

maybe also change the description for recommended quality/distance, like for editing/authoring workflows ```-d DISTANCE, --distance=DISTANCE Target visual distance in JND units, lower = higher quality. 0.0 = mathematically lossless. Default for already-lossy input (JPEG/GIF). 1.0 = visually lossless. Default for other input. Recommended range: 0.5 .. 3.0. Allowed range: 0.0 ... 25.0. Mutually exclusive with --quality. -q QUALITY, --quality=QUALITY Quality setting, higher value = higher quality. This is internally mapped to --distance. 100 = mathematically lossless. 90 = visually lossless. Quality values roughly match libjpeg quality. Recommended range: 68 .. 96. Allowed range: 0 .. 100. Mutually exclusive with --distance.```

q95 it's d0.5 or q96? https://canary.discord.com/channels/794206087879852103/794206170445119489/1116377019928805426

d0.5 is something around q95.55

so if you use q96+ then generation loss will be greatly reduced by that PR, at q95 or lower nothing changes

would be interesting to have some stat on which quality is used by users of Photoshop or gimp to save as jxl

the gimp version I have don''t even ask for quality...

So it is d = 0

is it a knowledge or a guess ?

``` % jxlinfo doc/Untitled.jxl JPEG XL image, 2560x1440, (possibly) lossless, 8-bit RGB Color space: 672-byte ICC profile, CMM type: "lcms", color space: "RGB ", rendering intent: 0 ```

educated guess then 😄 does someone tested photoshop or lightroom to see ?

It's memory

photoshop doesn't have jxl export yet afaik, only import

not yet 🙂

when saving images from adobe camera raw, the scale seems to be roughly as follows (based on just the filesizes I'm getting, no idea what actual encode settings they use): 1 (lowest): something like d4.5 3 (low): something like d3.5 6 (medium): something like d1.75 9 (high): around d0.85 10: around d0.65 11: around d0.4 12 (very high): around d0.1 (I tested on one HDR image, no idea if they use the same scale for SDR images)

Lightroom does, iirc (will check again when I get home)

(forgot to check)

I’ll set up a reminder this time

😅

It does

70 is the default quality proposed or the last used?

Proposed, owner of this Lr does not use jxl at all, so nobody touched it before me, and neither I

It seems low... For a photophile tool

The scale is likely different

Well, quick test shows that Lr's Q70 approximately equals to d1.5. Also it seems that Lr uses effort 4. Edit (fab mode on): d1.5 in terms of libjxl 0.9.2, for 0.10.2 it is d1.4. Edit2: assumption based on file size only, I did not compare quality

Lr is not a photophile tool, it is mainstream very rough and imprecise tool, just popular because Adobe is "default choice" when someone is not an *photophile* and just wants to apply some preset, then make some easy adjustments, and publish. But for serious raw processing it is.. err..

Btw, using any "non-srgb" profile something strange happens with cjxl (tried AdobeRGB): Lr jxl -> djxl produces png with correct profile, Lr png -> cjxl -> djxl produces png without profile. If open these jxl files in Ps (ACR, actually) then Lr jxl opens correctly, and cjxl jxl opens with like gamma 3.0 (second is the correct one, first - wrong)

Also sometime Lr is doing something very strange, and starts producing files with size of d ~ 0.04, while slider is still on q 70

Also, just curious, why such "jump" in file size between d 1.47 and 1.48 (I'm not fabbing, just tried to determine distance used by Lr)?

that's a weird jump in size indeed

I get a similar discontinuity on another image: ``` bash-3.2$ cjxl 001.png 001.png.jxl -e 4 -d 1.47406095 JPEG XL encoder v0.10.2 0.10.2 [NEON] Encoding [VarDCT, d1.474, effort: 4] Compressed to 153.6 kB (1.133 bpp). 1276 x 850, 11.290 MP/s [11.29, 11.29], , 1 reps, 12 threads. bash-3.2$ cjxl 001.png 001.png.jxl -e 4 -d 1.47406096 JPEG XL encoder v0.10.2 0.10.2 [NEON] Encoding [VarDCT, d1.474, effort: 4] Compressed to 135.7 kB (1.001 bpp). 1276 x 850, 39.422 MP/s [39.42, 39.42], , 1 reps, 12 threads. ```

seems to be something specific to effort 4, at other efforts I don't see such discontinuity

there could be an underlying encoder bug — seems like this happens for all images (a discontinuity in size/quality when going from d1.47406095 to d1.47406096 at effort 4)

``` Encoding kPixels Bytes BPP E MP/s D MP/s Max norm SSIMULACRA2 PSNR pnorm BPP*pnorm QABPP Bugs ----------------------------------------------------------------------------------------------------------------------------------------------- jxl:d1.47406095:4 53140 9991512 1.5041668 10.839 17.775 2.03326460 82.25755149 40.27 0.82721810 1.244273974514 3.043 0 jxl:d1.47406096:4 53140 8872981 1.3357781 11.983 16.511 2.28357451 80.24075946 39.39 0.92258484 1.232368654393 3.046 0 Aggregate: 53140 9415652 1.4174742 11.396 17.131 2.15478797 81.24289756 39.83 0.87360110 1.238307007034 3.045 0 ```

at effort 3 it also happens. Starting at e5 the discontinuity disappears.

Newby question for benchmark_xl. Couldn't find any info on this (if there is up-to-date info please point me to it). When you're using other codecs like `--codec jxl:wombat:d1,jxl:tortoise:d1,webp,jpeg`, is there a way to control what webp and jpeg are outputting? I was testing a bunch of files and getting things like: `Encoding kPixels Bytes BPP E MP/s D MP/s Max norm SSIMULACRA2 PSNR pnorm BPP*pnorm QABPP Bugs --------------------------------------------------------------------------------------------------------------------------------------------- jxl:wombat:d1 710 134383 1.5128110 1.825 39.245 1.60255078 83.51023260 38.76 0.73965539 1.118958803113 2.424 0 jxl:tortoise:d1 710 144164 1.6229202 0.367 37.316 1.35725912 84.41896693 39.34 0.67479117 1.095132212951 2.203 0 webp 710 167404 1.8845435 2.505 69.623 14.05078436 67.21178694 40.43 4.84898826 9.138129361767 26.479 0 jpeg 710 906697 10.2071035 38.716 77.593 0.73615628 93.14825430 54.46 0.30377413 3.100653981873 10.207 0 Aggregate: 710 232867 2.6214865 2.839 53.035 2.17789175 81.50795034 42.81 0.92597697 2.427436143726 6.164 0` Would be great if the SSIM scores were closer. Or can you actually target a SSIM score? Edit: just realized jpeg:q## works.

`jpeg:qXX`, etc. as I recall

Thanks. Can you target a SSIM score?

don't think so, just the distance for jxl/jpegli, which is roughly butteraugli score

Wait, is the JPEG I'm benchmarking actually jpegli?

i don't think so

`enc-jpegli` for jpegli

Thanks

webp has `m` and `q`

jpeg also is yuv444 by default. It's all undocumented afaik, I usually read the code to know the options

Hehe. Figured that might be the case. This page doesn't give many details: https://github.com/libjxl/libjxl/blob/main/doc/benchmarking.md

Photoshop Save As 00: IJG 46 Photoshop Save As 01: IJG 52 Photoshop Save As 02: IJG 63 Photoshop Save As 03: IJG 66 Photoshop Save As 04: IJG 71 Photoshop Save As 05: IJG 75 Photoshop Save As 06: IJG 81 (!!!) Photoshop Save As 07: IJG 78 Photoshop Save As 08: IJG 84 Photoshop Save As 09: IJG 88 Photoshop Save As 10: IJG 92 Photoshop Save As 11: IJG 96 Photoshop Save As 12: IJG 98 from https://photo.stackexchange.com/questions/57226/how-does-the-usual-jpeg-0-100-quality-settings-translate-into-photoshops-0-12-q also photoshop "save for web quality 50" is quality 82 in IJG

that's from 9 years ago though, meanwhile they have probably made changes to their scale

but yes, Adobe quality scales are quite different from those of libjpeg/imagemagick/gimp/etc, and they generally put most of their settings in the "useful range" (e.g. libjpeg q > 60) rather than having half of their settings correspond to libjpeg q < 50. This makes sense but it also causes confusion because many naive people think "quality 80" has some universal meaning ("20% of the pixels are lost" or something, I dunno) across all codecs and software.

So was running some tests on a large number of images, and it looks like `benchmark_xl --print_details_csv` drops the SSIMULACRA2 score. Any magic incantation to get it back into the output?

`--print_details` without the `csv` does output it.

is this magical enough ? 😄

I guess the csv writing was added before ssimulacra2 was added. Maybe open a github issue about it, should be easy to fix that.

```!? colors (mean) images Mpx (mean) | colors/px (mean) | share | share | | tag 84 100.00% 0.15 100.00% 23853 0.12 all 10 11.90% 0.41 32.12% 55003 0.13 digital_painting 5 5.95% 0.35 13.70% 48576 0.14 edit 6 7.14% 0.01 0.42% 2344 0.29 logo 6 7.14% 0.10 4.75% 13025 0.16 mixed 20 23.81% 0.25 40.16% 52412 0.24 photo 32 38.10% 0.02 5.78% 21 0.00 pixel_art 8 9.52% 0.31 19.97% 94811 0.37 watermark 8 9.52% 0.17 10.77% 18878 0.13 content_other 72 85.71% 0.16 91.87% 27424 0.12 visibly_opaque 12 14.29% 0.09 8.13% 2427 0.15 visibly_transparent 41 48.81% 0.26 83.03% 48139 0.21 DirectClass_sRGB 6 7.14% 0.07 3.10% 4818 0.29 DirectClass_sRGB_Alpha 1 1.19% 0.24 1.91% 246 0.00 PseudoClass_Gray 30 35.71% 0.03 6.93% 20 0.00 PseudoClass_sRGB 6 7.14% 0.11 5.02% 35 0.00 PseudoClass_sRGB_Alpha Pareto front for bpp and CPU time |Pareto front for bpp and real time bpp (mean) Mpx/s CPU (mean) ||included in 'all' B | mins unique mins Mpx/s real (mean) best of 7318280 3.485172 100.00% ···· 0.00022882000 0.003897477 CR· all 7320231 3.488666 65.48% 40.48% 0.002835134 0.0268040 CRA cjxl_0.10.2-m_d0e11 7325717 3.488910 57.14% 34.52% 0.00024972189 0.004579500 ··A cjxl_0.10.2_d0e11 7660342 3.675485 2.38% ···· 0.214605 0.231191 CR· cjxl_0.10.2_d0e10```

derived from

code

Yeah, I brute forced it with some cleanup in good old BBEdit.

optionally using resampling with pixel art

BTW, I'm finding you can tweak settings of lower efforts to get much better compute/density ratio.

How to read the 'relative bpp'/'relative real' columns, those are the relationship to the value for the next less dense milestone.

So d0e7E4g3 is 10x faster than d0e10 for 99.91% the bpp.

e6E4g3 is 3x as fast as e8 for 99.62% the bpp.

This depends on content. For some content, there is not much improvement for low efforts, but e9 and e10 are easier to beat.

Testing a DNG file from my iPhone 13 Pro. 12 bits. Converted to PNG->JXL 3 times with 12 bits, 10 bits and default bit depths. Was a bit surprised to see they were all exactly the same size. But maybe there is only 10 bits worth of data in there? `jxlinfo IMG_2042_12bpp.jxl IMG_2042_10bpp.jxl IMG_2042.jxl JPEG XL file format container (ISO/IEC 18181-2) JPEG XL image, 3024x4032, lossy, 12-bit RGB intensity_target: 10000.000000 nits min_nits: 0.000000 relative_to_max_display: 0 linear_below: 0.000000 Color space: RGB, D65, Rec.2100 primaries, PQ transfer function, rendering intent: Perceptual Size: 1,358,415 bytes JPEG XL file format container (ISO/IEC 18181-2) JPEG XL image, 3024x4032, lossy, 10-bit RGB intensity_target: 10000.000000 nits min_nits: 0.000000 relative_to_max_display: 0 linear_below: 0.000000 Color space: RGB, D65, Rec.2100 primaries, PQ transfer function, rendering intent: Perceptual Size: 1,358,415 bytes JPEG XL file format container (ISO/IEC 18181-2) JPEG XL image, 3024x4032, lossy, 16-bit RGB intensity_target: 10000.000000 nits min_nits: 0.000000 relative_to_max_display: 0 linear_below: 0.000000 Color space: RGB, D65, Rec.2100 primaries, PQ transfer function, rendering intent: Perceptual Size: 1,358,416 bytes`

Interesting!

I read this as asserting signaled bitdepth in the codestream just informs the decoder https://discord.com/channels/794206087879852103/804324493420920833/1228977409915883581

for VarDCT

In lossy mode, bit depth is just "FYI" metadata. The encoder always takes the full precision of the input image buffer as input, converts it to XYB, and encodes things with a precision that only depends on the quality setting (given with --distance or --quality, doesn't matter, it's just different scales that all map to distance internally)

So the bit depth is basically just a suggestion for a bit depth to use to represent the decoded image.

Oh interesting, wouldn't have been my guess.

The actual precision of lossy jxl images cannot really be expressed as a bit depth, especially not an RGB bit depth. The spec allows basically arbitrary precision (in libjxl it is in practice capped by the use of float32 internally, but still that's a pretty high precision), so e.g. slow gradients can be done super accurately in jxl, while other formats tend to struggle with that due to having a relatively low internal precision.

Especially video codecs need to make a compromise there: it needs to be implementable in hardware, preferably not using too much SRAM and only using fixed point arithmetic, and also the decoding process needs to be fully specified (no wiggle room for implementations to trade precision for speed) since otherwise errors can accumulate, so they typically end up having a relatively low internal precision. Which is fine for their use case, which is video delivery.

For a moment I wondered if the 32float regression I found could effect VarDCT at all, but I don't think it does pallete if I recall

No, it's not related. VarDCT only uses Modular to encode integers.

<https://loathra.com/jxl/bench/20240517.html>

Amazing job!

The folks at MSU tried out ssimulacra2 as a metric for video (just frame by frame, not taking into account temporal information)

not bad actually, given that especially at higher bitrates there may be a very wide fluctuation of what people will choose and appeal can be favoured over everything else, so even no-reference metrics can get very high scores

I've been defaulting to ssimu2 for pretty much everything lately :D

I requested ssimulacra2 scores for the next video codec competition from the MSU guys a couple months ago <:woag:1070464147805970432>

isn't MSU that 🇷🇺 group that charges to see their results?

only the most detailed information, which is mainly interesting for large companies and MOS and such benchmarks in general are very costly, so I don't see a problem that the detailed results aren't free basic is publicly available

like here, all metrics are poorly correlated with mos, because ~0.5 is basically the same as a coin toss

when the quality for some content is high enough, people can't properly rank what's best

visual compareasons are problematic at all but high compression levels. even subjective appreciations can be affected by sight, the display panel used and lighting conditions

i myself commonly diff outputs against the originals then multiply for a whole set so as to make what were unperceptible deviations much more noticeable, especially for noise

I don't think 0.5 can mean decorrelated, otherwise most of those metrics would be negatively correlated with perceived quality, which I find hard to believe.

i mostly mean that almost all metrics are 0.5 and below, so it's a very difficult case for a correct MOS comparison, some results may be true when the difference is obvious, but some may not, like even for Y and YUV VMAF for the same version there's a huge gap, which is usually not the case in practice

VMAF doesn't even consider chroma, how can YUV VMAF be different than Y VMAF?

just all the channels are merged into a single one, from what I understand

I imagine they convert U and V to grayscale channels and run it on that, even though that's a pretty bad way of doing it

there's some channel mixing ratio that gives a better results and not just for vmaf but usually just Y is enough for vmaf

like

So that's weighing Y 10/12 and U,V 1/12 each then, in that top one, I guess

It's a rather color blind way of dealing with color, imo, to just apply a grayscale metric to chroma components. SSIM as it was originally defined doesn't make sense on chroma, since it applies a kind of gamma corrrection, treating errors in the darks differently from errors in the brights (errors in darks are considered worse than errors in the brights). When applied to Cb and Cr components, that means it will consider errors in yellows and greens worse than errors in blues or in reds, which doesn't make any sense.

I did a small test (with the image 15 of the kodak set) in which I benchmarked the size and score of lossy jxl at high quality (for every distances from 0 to 2 by step of 0.001) and in both cases, for butteraugli, and the effect is even stronger for ssimulacra2), the highest efforts don't give the higher ratio size vs score... strange isn't it ?

for butteraugli e9 seems to perform a bit better than e10, and for ssimulacra2 e4 seems to be better

ssimu2 > 90 is very high quality, probably the effect is caused by low efforts not doing gaborish — when https://github.com/libjxl/libjxl/pull/3563 gets merged, higher efforts should also not do gaborish for these very high qualities

I think effort 8+ might be producing slightly worse results than e6/e7. We usually don't test those high efforts as thoroughly as the default effort, and I think it may be trying too hard to optimize for butteraugli at those high efforts.

true ! I have to pull wait for it to be merged !

yeah, like I already said, at very high qualities some tools need to be re-tuned (for higher efforts) or maybe even disabled if not giving any improvements

Is there robust reason to believe these results strange for this particular image? Are they outside expectation given measured correlation between the metrics and subjective assessment?

the data from CID22 that I used to tune/validate ssimulacra2 had an average human score of 88 for the original (people don't all give the max score to any image, even if the image is literally identical to the one they're comparing against), and there's always some amount of noise and uncertainty in human scores

ssimu2 had a mean abs error of 5 or so w.r.t. the human scores, so you can add an implicit ±5 to ssimu2 scores

the human scores themselves had average 90% confidence intervals with a width of 4.4, so even those have to be interpreted with an implicit ±2.2

If I understand correctly, we should not trust that ssimu2 can differentiate so precisely that we should be surprised about the demonstrated performance at high quality on this image.

it's not even clear to me what visual quality really means for very high qualities (i.e. enough below 1 JND so that literally no human can tell the difference)

that said: ssimulacra2 is a classical metric (no funky AI stuff), a score of 100 is guaranteed to be mathematically lossless, and nothing in the math can introduce non-monotonic behavior or other weirdness. It may be weighing things incorrectly (e.g. assigning too much importance to one component over the other, or one scale over the other), but it only uses positive weights, i.e. more error always means lower score.

Thanks for the details!

So far, most of the encoder tuning has been done for the d1-d3 range for photographic images, and recently some non-photo too. Also the focus has been on perceptual encoding, i.e. for images in visible light, viewed by humans. For some images that doesn't make sense (e.g. scientific / medical images) and we should instead do something that is just trying to minimize sample error without making assumptions on how the samples will be rendered (<@179701849576833024> recently added an option for that and made a start of an implementation). For the very high and very low quality (well outside the d1-d3 range that is the most useful range in practice and the one we've been focusing on mostly), probably there is room for improvement.

higher quality should be much easier to tune because it's not a bit starving case and most of the tools that are needed to compensate distortions or hide artefacts are actually not that important or even harmful so it's mostly methods that improve lossless or close to lossless and very low quality will requires much more complex changes and research

I'm testing progressive decodes and getting some surprising results. It looks like JPEG is besting JPEG XL it terms of getting a decent image up first. Left image is JPEG from mozjpeg with -progressive on (although it made no difference). Right is cjxl -e9 -p -d matched to the SSIMU2 score of the jpeg.

try with `--faster_decoding=4` Anyway, at matched quality levels that doesn't surprise me (at least in scenarios that are not throughput-limited). But what interests me is when you have a hard bitrate cap, want visually lossless (or near visually lossless) quality, and then want the fastest transfer + decode time.

can you send the image itself? I wonder if this is an artifact of https://github.com/libjxl/libjxl/issues/3296 i've found libjxl to not be ideal when doing progressive decoding

also when doing encoding, instead of doing `-p` I normally use now `--progressive_dc=1` for lossy images since i've found it to generally be smaller

It's more a decision of the decoder than a limit of the format to decide when to show a group, the Oxide examples clearly show this https://discord.com/channels/794206087879852103/1065165415598272582/1176213246437494935

Original:

Thought it might be the image so tried it with a different, much bigger one. Pretty much the same results:

I'll try `--progressive_dc=1` and `--faster_decoding=4` out

allowing more patches benefits density ``` B ssimu2 dssim alien 150845 84.94961437 0.00031486 alien_more 143620 85.97630715 0.00030562 perlin 170514 85.34212669 0.00030758 perlin_more 143936 85.75967001 0.00026263 pfp 522960 81.83891840 0.00042752 pfp_more 442135 83.15266273 0.00035611```

also, e8-9 doesn't like patches ``` colors (mean) images Mpx (mean) | colors/px (mean) | share | share | | tag 24 100.00% 0.52 100.00% 3400 0.01 all 6 25.00% 0.22 10.54% 694 0.00 game 6 25.00% 0.30 14.25% 139 0.00 reduced_palette 24 100.00% 0.52 100.00% 3400 0.01 text 9 37.50% 0.78 55.74% 4296 0.00 ui 24 100.00% 0.52 100.00% 3400 0.01 visibly_opaque 15 62.50% 0.66 79.29% 5004 0.01 DirectClass_sRGB 2 8.33% 0.29 4.69% 2816 0.01 DirectClass_sRGB_Alpha 1 4.17% 0.45 3.60% 26 0.00 PseudoClass_Gray 6 25.00% 0.26 12.41% 148 0.00 PseudoClass_sRGB 1 4.17% 0.37 2.97% 5193 0.01 source_gnome_screenshot->exiftool 23 95.83% 0.53 97.03% 3323 0.01 source_imagemagick->exiftool Mpx/s real (mean) | Pareto front for bpp and real time B bpp (mean)| | best of 1497634 1.036160 4.291 R cjxl_0.10.2-p_d1e7 1709641 1.189026 5.240 R cjxl_0.10.2_d1e7 3206825 2.203859 0.81073 · cjxl_0.10.2-p_d1e9 3207420 2.205582 1.2093 · cjxl_0.10.2-p_d1e8 3435532 2.394660 1.2079 · cjxl_0.10.2_d1e8 3444868 2.398201 0.79728 · cjxl_0.10.2_d1e9```

actually, the highest efforts probably just suck for VarDCT in general

Libjxl currently doesn't show DC frames progressively, it only shows them when it reaches the AC frame. So in terms of bytes for first image, cjxl -p is currently actually less progressive in practice than default encoding.

```images Mpx (mean) images Mpx (mean) | share | share tag | share | share tag 798 100.00% 1.30 100.00% all 685 85.84% 1.37 89.91% visibly_opaque 65 8.15% 2.73 17.05% 3d 113 14.16% 0.93 10.09% visibly_transparent 45 5.64% 1.55 6.71% algorithmic 6 0.75% 0.37 0.21% DirectClass_Gray_Alpha 73 9.15% 1.89 13.27% digital_painting 495 62.03% 1.48 70.18% DirectClass_sRGB 84 10.53% 2.24 18.06% game 173 21.68% 1.21 20.13% DirectClass_sRGB_Alpha 56 7.02% 0.21 1.15% logo 30 3.76% 1.63 4.70% PseudoClass_Gray 83 10.40% 1.15 9.14% lossy 87 10.90% 0.54 4.55% PseudoClass_sRGB 51 6.39% 1.75 8.57% machine_learning 7 0.88% 0.33 0.22% PseudoClass_sRGB_Alpha 96 12.03% 0.84 7.71% photo 83 10.40% 0.35 2.82% source_app->exiftool 73 9.15% 0.23 1.59% pixel_art 41 5.14% 0.27 1.05% source_gimp 68 8.52% 0.30 1.94% texture 525 65.79% 1.44 72.86% source_imagemagick->exiftool 58 7.27% 1.28 7.16% ui 89 11.15% 1.44 12.35% source_other 60 7.52% 1.52 8.76% watermark 60 7.52% 1.89 10.92% source_web->exiftool 159 19.92% 1.68 25.74% content_other Mpx/s real (mean) | Pareto front for bpp and CPU time unique mins | |Pareto front for bpp and real time B bpp (mean) mins | Mpx/s CPU (mean)|| best of 855533978 6.54794670 100.00% ···· 17.251 22.095 CR cjxl_0.10.1_d0e1 zune_0.5.0 860429631 6.59029791 21.68% 21.30% 40.784 47.864 CR cjxl_0.10.1_d0e1 913975002 7.04326593 78.70% 78.32% 31.526 43.323 ·· zune_0.5.0```

zune includes write time

``` B ssimu2 dssim alien 150845 84.94961437 0.00031486 alien_morer 136976 86.69735563 0.00028835 perlin 170514 85.34212669 0.00030758 perlin_morer 142841 86.32329967 0.00023073 pfp 522960 81.83891840 0.00042752 pfp_morer 409098 83.23960189 0.00033600```

``` Mpx/s real (mean) | Pareto front for bpp and real time B bpp (mean) mins unique mins | best of 1407207 0.9413538 91.67% 87.50% 1.3825 R cjxl_0.10.2-p4_d1e7 1709641 1.189026 12.50% 8.33% 5.240 R cjxl_0.10.2_d1e7```

``` Mpx/s real B bpp | best of 32806 0.313131 0.5812 cwebp_1.3.2_z9 32837 0.313427 0.7170 cjxl_0.10.2-p5_d1e7num_threads0 34140 0.325864 13 cwebp_1.3.2_z8 39239 0.374534 0.3846 cjxl_0.10.1_d0e10P0I0g3modular_palette_colors10000patches0num_threads0 104147 0.994077 0.2568 cjxl_0.10.2-p5_d0e9num_threads0 133964 1.27868 0.2525 cjxl_0.10.1_d0e9num_threads0 341087 3.25566 1.68 cjxl_0.10.2-p5_d0e7num_threads0 409098 3.90482 2.33 cjxl_0.10.2-p4_d1e7 479706 4.57877 2.25 cjxl_0.10.1_d0e7num_threads0 522960 4.99162 3.25 cjxl_0.10.2_d1e7num_threads0```

In what way did you "allow more patches" by the way?

first just tweaking patch heuristics, like marking more screenshot areas and increasing patch size, then looking for more patch occurrences not detected by the text-like heuristics. but the last version also tries to find a tile layout across the entire image

so in the last image where basically everything is caught, probably none of those patches were exactly found by text-like heuristics. while in the previous image all of the patches were found by text-like heuristics (somewhat relaxed)

there is somewhat a loss in density for text compared to p4. I would have to investigate in a disciplined way to figure out why. but even disregarding the timings (I didn't optimize at all), I am not sure the results are super convincing compared to other lossless tools

feel free to make a pull request if you have tweaks for the patch heuristics 🙂

Okay, so I managed to beat WebP on that image. d0e7num_threads0 13778 B @ 4 Mpx/s

Just wondering how much better is JXL compared to JPEG XR?

I don’t recall JPEG XR being any good at all, so probably “plenty”

JPEG XR is somewhere between JPEG and JPEG 2000 — it was designed to be somewhere in between those two in terms of both functionality and compression performance, and also in terms of computational complexity (J2K was seen as "too complex", both computationally and in how much functionality it brings). For the typical quality range, there is not a huge difference between the compression performance of the best JPEG encoders (say, jpegli and mozjpeg) and that of JPEG 2000. So generally speaking, I think you can assume JPEG, JPEG XR and JPEG 2000 are all more or less the same, with the caveat that for JPEG things can get significantly worse if you use a 'bad' encoder (one that is optimizing for speed, not compression performance; e.g. default libjpeg-turbo or the hardware encoders in cameras), and also things break down at the lower bitrates (it becomes a blocky mess while J2K / JXR can still produce a less embarrassing image) and de facto JPEG lacks features such as alpha channels and high bit depth (it can in principle do these things according to the actual JPEG spec, but in practice applications implement only the JFIF/Exif subset which means 8-bit and no interpretation of components that would allow alpha).

AFAICT, JPEG XR is quite a bit worse than even JPEG – check out the banding in the sky at 2bpp here: https://afontenot.github.io/image-formats-comparison/#abandoned-factory&JPEGLI=l&JPEGXR=l

or in the image “Bath from Alexandra Park”

or how much detail it removes from the lake in “Cecret Lake” at 2.5bpp

Vallée de Colca at almost 3bpp 😬

Yes, though I cannot tell to what extent that is an inherent problem of the JXR bitstream or just a bad encoder. In practice any format is only as good as the best encoder, and JXR is pretty much abandonware — an implementation was made available when Microsoft was pursuing standardization, but it's not the nicest tool to use (e.g. it's quite idiosyncratic about its input and output formats) and it has not seen any improvements or even maintenance in many years now.

JXR does seem to be pretty good at lossless half float compression (e.g. Windows HDR screenshots), I did a quick comparison against JXL with a few screenshots I had lying around (lossless transcoding via libjxl, default settings on effort etc.): ``` 30493053 -> 27807169 bytes, -8.81% 16173522 -> 11866731 bytes, -26.63% 34901826 -> 24896383 bytes, -28.67% 24749140 -> 21437036 bytes, -13.38% 29241593 -> 27512549 bytes, -5.91% 30205570 -> 30416320 bytes, 0.70% Best: -28.67% Worst: 0.70% Mean: -13.78% ``` Interesting that one image actually compresses worse as JXL 🤔

Ah, interesting, I haven't looked at lossless JXR. I didn't know it does a decent job at lossless...

We should probably at some point tweak jxl's lossless encoding for float/half-float. Probably some of our encoder heuristics are not so great for this case, there might be room for improvement (things have mostly been tested with png input images so far).

https://docs.google.com/presentation/d/1z0BCT2Ql_z_jiPODxYCZi0G_PCt9KB_QeE3hJesgb_8/edit?usp=sharing — some WIP slides to report on some benchmarking we've been doing (well, mostly <@604964375924834314> )

interesting ! not all graphs are easy to interpret... but it's not my job 😄 nice work

interesting, e3 is worse than e2 on this large photos for some reason, patches? ```F26 Multithread 87.280s, 4.650s, 171,419,206 JXL e4 16 Thread 16.799s, 4.959s, 184,393,550 HALIC Multithread 0.703s, 0.984s, 187,375,364 JXL e2 16 Thread 6.159s, 2.312s, 195,672,678 JXL e3 16 Thread 8.607s, 4.661s, 205,789,465 F23 Multithread 2.701s, 1.828s, 211,589,542 JXL e1 16 Thread 2.053s, 2.109s, 216,187,168``` <https://encode.su/threads/4141-Simple-Lossless-Image-Codec-(-SLI)/page2>

Since 0.10 patches shouldn't be enabled at all until e10, and before e5 would enable patches in lossless

It's not guaranteed that e3 actually compresses better than e2

For nonphoto, usually e2 is better. For photo, usually e3 is better. But there are plenty of counterexamples.

it's photo though, so isn't it a quite surprising result? could it be related to PPM conversion process?

I saw the same thing with the multispectral satellite images from <@446428281630097408> , which are photographic (not typical but still) and e2 outperforms e3 on them.

hmm

true for images eligible for chunked encode, requiring at least one edge > 2048px. smaller images will still try patches

Even then, the results only go up to e4 and patches is enabled at e5, or at least used to be

I cannot seem to find the original images — when I follow the link, I only see jpeg files and rw2 files, but no ppm files

Anyway, e3 generally works better than e2 for photos, but it depends on the behavior at the pixel level — there can be things like more or less sensor or photon noise, different debayering methods, all kinds of on-camera processing, and presumably in some cases e2 will be better and in other cases e3 is better.

maybe someone here can find these useful? Lossy sizes: https://le-m.ltgc.cc/derpi-image-corpus/data/derpi.lossy.size.tsv Lossy SSIM: https://le-m.ltgc.cc/derpi-image-corpus/data/derpi.lossy.ssim.tsv Lossless sizes: https://le-m.ltgc.cc/derpi-image-corpus/data/derpi.lossless.size.tsv

It's SSIMULACRA 2 now

there are some images like https://derpicdn.net/img/view/2024/2/16/3303519.png in the set that have alpha so obviously the scores for jpg will be very low for those

https://docs.google.com/spreadsheets/d/1Wm_qwI_Ll1MrVcyKZcyIZr9aVWpTXYFdttdClTp2tH4/edit?usp=sharing

just put the data in a sheet and made a little summary table

the categories (like g4sa) are standard denominations ?

eventually I need a script to make images for csv tables, full spreadsheet software kinda sucks

https://github.com/PoneyClairDeLune/derpi-image-corpus/blob/main/corpus/README.md#still-images It's documented here

One thing to note is that ssimu2 was tuned and validated mostly with photographic images; most datasets with subjective scores have few or no non-photo images. Metrics should never be really trusted, but on nonphoto images that's probably even more true.

not sure if there would be a crowdsourced subjective scoring dataset for non-photographic images soon for use in perfecting the objective scores, but if that's of use maybe there are quite some people willing...

So... I saw a 200 MB PNG get uploaded by the graphic design guy for a game, opened it in Irfanview, disk size is almost equal to memory size. At first I assumed they had set the compression to 1 in whatever software they were using to export the PNG, then I zoomed in a notch... They applied a noise filter over the entire image, including the logo text at the bottom, making it near impossible to compress. So naturally, I'll leave the challenge to some of you <https://cdn.discordapp.com/attachments/1154514014563483759/1266220528893427855/ResoniteMarketing_A1PosterGeneric_01_v01.png?ex=66a45b43&is=66a309c3&hm=9f804960a30aa2a93c877ccfb4357be4b3c58d69dad2845a16e627037305827e&>

Original, default ECT run, and JXL e9

And now I realise the color count in the JXL is off by 800...

I managed to get it smaller as a lossless WebP (135 MB). though I did drop the empty alpha, did you not drop it when doing the JXL?

Mine kept the alpha, I was running it after ECT so assumed it would already be stripped if it was empty

wait a minute I just checked the alpha and it's not actually empty

guess ill redo the lossless WebP then

only ended up 2 MB bigger (137 MB total)

is the challenge to compress better by removing the noise ?

I was going for lossless, but whatever you'd like really. I just want to see how people handle a nightmare image

IrfanView is not accurate here at all, I don't know how it counts colors, but the difference is there (almost?) always

We are in constant battle with our designers team, they just are not thinking about size and compressibility at all. It is ok for them, for example, to provide svg with 90% invisible shapes just because "it is invisible, what's the problem?"

ECT -90099 --mt-deflate (165,667,468 bytes) ~~got bored and decided to waste some electricity <:KekDog:884736660376535040>~~

Only 870.04KB (0.5349%) smaller than -9 --mt-deflate lmao

With WebP doing so well, ideally we could run effort 11 on a cropped area, then copy the parameters for the full image

What does `-90099` change?

Don't know exactly. But any slower and it'll be way too slow <:KekDog:884736660376535040>

> A different syntax may be used to achieve even more compression for deflate compression if time (and efficiency) is not a concern. > If the value is above 10000, the blocksplitting-compression cycle is repeated # / 10000 times. > If # % 10000 is above 9, level 9 is used and the number of iterations of deflate compression per block is set to # % 10000. > If # % 10000 is 9 or below, this number specifies the level.

So it runs the block splitting 9 times with 9 deflate iterations, if I'm reading this right

Includes missing info from the command line help

you surely meant block splitting 9 times, compression level 9 with 99 iterations

That would be 990099, I think

And what number would be likely to allow the strongest compression, regardless of the time required?

Theoretically, just press 9 until it no longer runs

Will test for science, but I doubt it is a viable solution. <:KekDog:805390049033191445>

-99999 ftw <:KittyUwU:1147753612529913938>

And all filters b <:KekDog:884736660376535040>

The brute force evolutionary filtering

My motherboard will have melted before it's finished.

Would be a good test for recent Intel CPUs if they make it before exploding.

Who needs that prime checker thing when you can just optimise PNGs to heck and back

Intel officially suggests reinstalling nvidia drivers 5-10 times to see if the cpu is affected or not 🥲

I know why I'm using architectures that are at least 5 years old.

Added DSSIM as well, and changed the test cases. The tests are still running. Everything's not final yet, wanna give jpegli a try later. Lossy sizes: https://le-m.ltgc.cc/derpi-image-corpus/data/derpi.lossy.size.tsv Lossy SSIMU2: https://le-m.ltgc.cc/derpi-image-corpus/data/derpi.lossy.ssim.tsv Lossy DSSIM: https://le-m.ltgc.cc/derpi-image-corpus/data/derpi.lossy.dssim.tsv Lossless sizes: https://le-m.ltgc.cc/derpi-image-corpus/data/derpi.lossless.size.tsv

~~may add "time" later just to see how horrible AVIF is~~

"not only is it lossless..."

Noticed this <https://www.phoronix.com/review/amd-ryzen-9950x-9900x/12>

On Windows it will be slower currently, probably 🤦‍♂️ But it is a good sign, that jxl is used in tests

and I think it's not using avx512 😛

test scripts are here, https://github.com/phoronix-test-suite/phoronix-test-suite/tree/99c30505d730c2429ad2120346dc197cf3f1355c/ob-cache/test-profiles/pts/jpegxl-1.6.0 windows does download the static binary, on linux it compiles libjxl so it's not a great comparison to judge across, but there isn't really a *better* solution IMO since compiling on windows sucks

I meant this https://www.youtube.com/watch?v=D1INvx9ca9M

I've only heard briefly about it, havnt learned much about it yet

https://loathra.com/jxl/bench/20240819.html

send a PR? 😉

Yes, please turn this into a PR! Also consider proposing changes to make e9/e10 more effective, it's very much possible that they too can be made faster and/or better.

or make it `-e11` and `-e12`, that also works for me 😛

Or `-eeeeeeeeee`

```cjxl -e ω Generates every possible valid JPEG XL bitstream to find the absolute smallest possible image file. Time complexity: "it will finish, eventually..." ```

if we were to ever implement this, we should probably implement regular saving of the current search state to disk and support for resuming from the saved state

so that a single power loss, or reboot for OS updates, etc. doesn’t ruin the whole thing

“noooooo this cjxl had been running for 37 years”

“I’m sure it was close to being done”

"Hmm, it's been running for a week already but I forgot to add an extra thread... Do I stop it now or is it nearly done?"

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

But being able to see what options e11/12/13/∞ ended up choosing on a sample image, and reusing it on similar larger images was an idea that's already got an issue, maybe mixed with a general compression settings option for metadata

That doesn't work if you do the search the Kolmogorov complexity way: just generate all bitstreams, in order of increasing length, until you find one that decodes to the image you want.

why wouldn’t it? we can just save every <n>th generated bitstream

Ah just to keep track of where you were, sure. But you won't have a valid bitstream until you're done.

ah, right

yeah, it’s just so that stopping the program (one way or another) doesn’t mean having to start again from scratch

In any case it would only theoretically work 🙂

If a million JXL artists had a million browser tabs, eventually there would be your image

I mean you could be smart(er) and *only* generate valid bitstreams that correspond to reasonable images - after all, if you do lossless you can't really *choose* much except the decision tree, the distributions, the transforms and LZ77, no? so you could exhaustive search those instead of bitstreams 😛

Yes, that would turn it from a million lifetimes of the universe to only a thousand or so.

I think with some genetic algorithms you can even do it in a sensible time

I will not be writing it though

Some progress indicator for e11 would be very useful. Like 100 variants processed, 10^9 are waiting

that will make certain people very happy XD

I think some kind of progress indicator would be helpful so I know just how many weeks it will take for my -e11 to encode

Then `-v` on cjxl would actually be useful too

-v -v -v -v -h?

During encoding

Fair point

Does the API even expose progress?

If not, that feels like something that would be important, like how would an application display to the end user the estimated transcode time

The issue is deciding what counts as "progress", is it finishing a group? Moving to the next heuristic?

The only thing that is important - more or less stable one "piece" time, and their number known from the start, so it can be used to calculate overall progress

finished writing my own little progressive loading tester

40 kB/s

`-d 2.5 -j 0 -p --progressive_dc=1 --progressive_ac`

did this finally got a PR ?

not as far as I know

Look, that methodology is not very smart. First, I'm not a programmer, so I don't know the proper way to search such a big space to find a true optimum. Second, trying some monolithic array of settings on every image is still wasteful. I figure it would take 32-36 configurations to be comfortably denser than current e11, but some settings can be predicted to be useless based on content. (If you know the content up front, you can match e11 at about 1% the compute rather than 5%.)

My goal was not really to improve e11, I am not interested in that. My goal was to convince people that it sucks. That said, yes, I am actually working on a small improvement that is slightly less dumb. I've assessed a few thousand more configurations over the last days and will implement a test which should allow density improvements over a 32 setting list while only trying 25 settings per image.

I think `-e11` doesn't try to be smart 😛 the code snippet you wrote there is perfectly fine as a PR IMO

(or at least, it can be a very good starting point for it)

Okay. I will try my current idea, but I can offer the straightforward thing otherwise.

I submitted something for you, dude.

Time to berate me on my mistakes.

<:Hypers:808826266060193874>

thanks

I have a question to, probably, <@794205442175402004> ? When I discovered jxl two years ago I immediately converted everything losslessly convertable to it, using -e 9, as I was unaware of more advanced settings. I don't know version of libjxl, but it was the latest compiled build available on January of 2023. Now I just became curious enough to recompress one of that (huge) files to see if there is any improvement. So I used command line: cjxl -d 0 -e 10 -E 3 -g 3 -I 100 TMP7.png TMP7.jxll . And when it finally finished it's work (User time, 0:01:17:56:937 😅 ), two interesting things appeared: it is smaller by 3 MB (out of 200 😅 ), and new file decodes much faster than the old one: ~1000 ms vs ~2500, while new one uses less cores, see screenshot: first peak is decoding old file, second - new. Could you guess, why it is so?

`-g 3` means internal group size 1024x1024 is used, instead of the default 256x256. That can be better for compression (fewer poorly predicted pixels on the first row and column of each group) but it also means less opportunity for parallel decode, since you can only use one core per megapixel instead of up to 16 cores per megapixel.

File is ~50 MP, and I have 16C\32T CPU, is it still limiting factor? Also - even with this limitation you are talking about, new file is decoded 2.5 faster than the old one

less core usage & faster i knew it

Just tested, the same file, the same arguments with except of -g 3 (no -g at all) produces slightly larger file that decodes a bit slower - ~1000 ms vs ~1200

Curious how the other group sizes fare now, since I did have an image where -g 2 was 10x smaller than the others

Wait ~2 hours 😅

-g value is in name

There's -g 0 too, but seems like a fairly consistent 150-200 KB saved per level

I can test -g 0, but only tomorrow

if the goal is density, g0, g1 are not worth trying in general

smaller group size can also be super slow in some contexts

Larger group size is good for prediction and for lz77 if you have horizontal runs or repetitions. Smaller group size is good for having more finetuned local RCTs and smaller local palettes. Also smaller groups allows more enc/dec parallelism (but for a large enough image that doesn't matter that much, since even with g3 you can make use of one core per megapixel). Generally the default is not too bad but g3 will usually be a bit better. It can be worse too though.

Loading speed: g1 - 1350 ms, g2 - 950, g3 - 1050

Also <@263300458888691714>, now that you've dipped your toe in the water by 'fixing' e11 somewhat, I might as well bring this up too

Well this doesn't seem right... ```JPEG XL decoder v0.10.2 4451ce9 [AVX2,SSE2] Read 39126861 compressed bytes. Decoded to pixels. 8880 x 9376, 0.997 MP/s [1.00, 1.00], , 1 reps, 16 threads. PageFaultCount: 74412162 PeakWorkingSetSize: 2.564 GiB QuotaPeakPagedPoolUsage: 36.12 KiB QuotaPeakNonPagedPoolUsage: 14.2 KiB PeakPagefileUsage: 2.768 GiB Creation time 2024/09/04 17:26:02.958 Exit time 2024/09/04 17:27:26.636 Wall time: 0 days, 00:01:23.678 (83.68 seconds) User time: 0 days, 00:06:58.687 (418.69 seconds) Kernel time: 0 days, 00:12:20.562 (740.56 seconds)```

40x decode slowdown on e10

Every single tile stored as a patch?

each emoji encoded as a patch, yeah

that decode print out ain't from my image, yeah? 'cause that would be weird

No, just had it typed out already so didn't realise you had sent that file

Did some patch encoding by hand or was that the new heuristics for finding tiles you made?

they're detected from a function specifically for finding general tile-like repetitions, rather than text-like

Does it still work decently on text, or is it more one or the other?

one or the other in this case

technically you could combine results from both collections

Yeah ~~another addition for e11~~

Another example where webp by far outperforms existing cjxl, however file from <@263300458888691714> outperforms webp by the same magnitude as webp does to existing cjxl

https://embed.moe/https://cdn.discordapp.com/attachments/803645746661425173/1280926166068232273/tiles_pfp.jxl?ex=66d9daf4&is=66d88974&hm=c51046723b8256de2e4c27b68539a1ba0a76359b914cd1bebd56846c21a1eae8&

Nice!

Heuristics that try to detect a grid of repeating patches could be useful for more kinds of images than this rather contrived example. Text in a monospace font also behaves like that, e.g. screenshots of anything in textmode or in a terminal window.

well, contrived is a bit unfair, it's a legitimate image I had saved

Yeah I just mean this is not a particularly typical type of image

imo, it would mostly useful for game screenshots over the text-like heuristics. modern retro pixel style tends to be more messy, but traditional styles offer more exact repetition

In reference to that e10 decode I posted before ``` WebP: 3.16 bpp Encode 200 Seconds 4424 MB RAM Decode 813 milliseconds 606 MB RAM JXL e10: 3.76 bpp Encode 3400 Seconds 8036 MB RAM Decode 102437 milliseconds 1781 MB RAM JXL e9: 4.40 bpp Encode 65 Seconds 840 MB RAM Decode 3125 milliseconds 619 MB RAM ``` Tried to measure Decode memory using ffplay since I have it on hand, e10 used up so much CPU my mouse actually stuttered for the first time in years, ended up just using Irfanview from the command line So still some work to do xP

The actual command was `cjxl -d 0 -e 9 -I 1 -g 0 -E 3`

This is the source file if anyone else wants to mess with it https://puu.sh/KefiO/0968286c2d.png

Smallest group size helps with palette, high entropy so only 1% is needed for the MA tree from loose testing

Probably almost as good as the direct emulator integration that was talked about years ago, sampling sprites from the cartridge and essentially reconstructing the game scene on decode

Note to self: Lossy Modular does not use chunked encoding like lossless does

Odd

Also, turns out using ZSTD on a PPM is the highest compression I could reach, 29.9 MB

Have you tried XZ?

Not the back doored version

yeah I have some files where XZ is the best compression