JPEG XL

this is what we get for treating alpha as a special case and not properly testing other kinds of extra channels :/

looks like a convoluted way to say : "I told you so" 😄

nah, RGBA is common enough to deserve some special casing, it's just easy to miss other kinds of extra channels because they're not really common — e.g. none of the input formats we have, actually supports that.

There are not many formats supporting more than 4 channels. As an alternative, cjxl might process set of grayscale images as extra channels.

Yet jxl would be perfect for multispectral data, where tiff are used

it makes sense to special case alpha cause many formats support alpha as their only type of extra channel

such as PNG

I think heic can but that’s more a container for HEVC blocks

I would say in several image formats alpha is not an extra channel, it is stored as fourth color channel.

<@1028567873007927297> can you send me latest pdf in this Channel

Ah ok did That, is that pdf

I am just a fox, idk what you want from me 🦊

ooi, is there a tool/method to check if a jxl image was encoded in modular mode? `jxlinfo --verbose` doesn't seem to output that info. I'm trying to add support for modular mode to libvips and this would be handy to check that it's working

All JXLs have modular parts, as VarDCT’s DC components are modular

I was under the impression that you could encode an entire image with modular mode, i.e. with `cjxl --modular`, which is a better setting to replace lossless formats (like PNG). Am I misunderstanding something fundamental here?

Oh you mean specifically only modular

Yes that exists

In not store hours to detect that

it's not really something that is exposed in the libjxl api, since it is considered an internal encoder choice. But generally speaking, if `jxlinfo` says it is "(possibly) lossless", and it's not a losslessly recompressed jpeg, then chances are very high that it is a modular mode image.

Is it correct to consider lossless modular mode (i.e. `cjxl -q 100 -m 1`) as the "PNG replacement" setting? That's how I've seen it in my head, where VarDCT is for re-encoding JPEGs. It seems like an important distinction (rather than an internal encoder choice) to tune/deploy JXL on a workload split between JPEG and PNG

But maybe my brain is stuck in the past, where some images are better for PNG and others for JPEG, and I'm incorrectly mapping this to the modular and VarDCT modes

> if jxlinfo says it is "(possibly) lossless", and it's not a losslessly recompressed jpeg, then chances are very high that it is a modular mode image. That's very helpful, thankyou!

correct that `-q 100` is a replacement for PNG as it is lossless (btw you don't need `-m 1` because this is implied in lossless mode), but VarDCT is also used for creating new lossy JPEG XL images

Indeed, `-q 100` is equivalent to `-d 0` which is truly lossless like PNG and will use Modular exclusively. Additionally, Modular can be enforced in lossy mode with the `-m 1` switch, turning VarDCT off, although lossy Modular is not really practical at the moment.

Actually, setting the lossless quality by `-q 100` or `-d 0` switches the encoder to a special mode where it uses only features that don't change the contents of the image. Setting the quality to any other value will set the relative quality for lossy compression and the compressed image will be always different from the original.

Lossless jxl is essentially a png replacement. It's much better than png and it's good at the same kinds of images png is good at. Sometimes lossless jxl is even smaller than lossy jxl, just like png is sometimes smaller than jpeg, for non-photographic images.

disagree lossy modular is great for comics and animated pictures, it is still slower to decode but not extremely so

Lossy Modular looks worse than VarDCT, IMO.

Depends on image, distance and settings

Perhaps it can be fine tuned but at the default distance of 1, Modular has more visible color distortion than VarDCT at the same distance.

it is extremely slower to decode

does Modular even support progressive decoding?

yes but the decode is so slow any download will be done before the first pass

thats a massive overstatement, even when decoding at 15kx8k image encodied with `-d 2 -m 1 -e 7` it only takes a second on my s9+ and 6 seconds on only the 4 little cores, 1.7s on just the 4 big cores on termux.

if you limit it to the little cores sure, but the big cores are more then enough, and this is a fairly older phone now

3 sec on 2 little and 2 big cores

idk when I try to load this <https://m.grass.moe/chapter/lacking_54> on my s10e it takes two minutes to show 2 pages then everything on my phone crashes

real world example here

I opened this on my desktop and firefox (vanilla with addon) crashed [av1_dogelol](https://cdn.discordapp.com/emojis/867794291652558888.webp?size=48&quality=lossless&name=av1_dogelol)

even 1.7s is extremely slow

perhaps in comparison, but its still "fast enough" for many uses

no that is not fast enough at all, not even close

get real

?

i use it on my phone all the time

so?

its plenty fast

for you

for many

I'll look at an image for less than a second. I'm not going to wait twice that for it to load

on a slow connection it will take a lot longer then that to download it lmao

on a slow connection my ass

guess you don't use slow connections lol

aren't you canadian

Absolute minimum speed in Canada is 50mbps

44 seconds for 2 pages, about a minute for 4 pages on a 7 year old Huawei Mate 10 Pro using Waterfox. But yeah, RAM crapped out and there was a very specific hotspot on the CPU

thats absolutely hilarious

i still occasionally make house calls to people that only get around 2mbps down at max

I think the main issue here is just the resolution of the pages. Ignoring decode cost it's over 2GB of image data alone

and this is discounting data

cellular data can be slow as molasses

cellular data is even faster

even in rural areas

wake up

maybe if you have great signal

>wake up ah yes, im living in the matrix

> on a 7 year old Huawei Mate 10 Pro It's less "wake up" and more "get a new phone"

a newer device won't make it much faster

Last week I was at a convention, 3K people brought the towers to their knees so it was 2 bar 3G if I was lucky, nothing at worst. I was unironically converting to JXL on my phone to then send to my friends

I assumed you meant 5G, ect

I mean decode speed

finally got some of the images downloaded, is not that bad, most likely the browser is trying to decode them all at once crippling the device. ```ps ~/img $ time djxl 01D.jxl --disable_output JPEG XL decoder v0.10.2 [NEON_WITHOUT_AES] Decoded to pixels. 4318 x 6061, 10.866 MP/s [10.87, 10.87], , 1 reps, 8 threads. real 0m2.571s user 0m16.260s sys 0m1.100s ```

when I was younger I had a slow computer and slow internet, now I have a fast computer and slow internet. the area I live in literally doesn't provide faster internet plans

whats interesting about this page is that it looks like neither thorium nor waterfox will properly use lazy loading

yup even with loading=lazy

because when they're not loaded they're all 0px in the same place

even without images there is a very high cpu load on this page <:kekw:808717074305122316>

0.0

power of live updating as I find out dynasty now converts to and only serves webp

Sometimes, it can look better.

It does have more color distortion though. But then again VarDCT mode in libjxl has terrible color distortion imo too

If you set the effort to 3 or below, is it still slow?

why would I do that

Because default effort setting is unacceptably slow at default settings

makes it worse than webp

Yeah but e=3 is instantaneous. e=7 is molasses by comparison

to decode?

And encode

Both

I know that lossless mode is very good

I have not tested low-effort lossy modular

But for lossless mode, e=3 is much much much much much faster than e=7 and the difference in compression ratio is worth it

Much faster decompression too

i dont care about encode time though

Well it has a huge effect on decompression time.

e=7 is a bad tradeoff in my opinion. especially since it's much slower to decode.

but why wouldnt i just use webp at that point

beacuse it's webp, lmao!

i feel bad for the jxl devs who were webp devs

efforts unappreciated

Nah, webp lossless is cool, and it's not their fault they were told they have to intentionally limit it and cripple it to match the limitations of vp8 mode, lol.

great compression attached to a Google-doomed format

Jyrki's awesome, he's an image coding hero

Google literally forced him to add arbitrary limitations to webp lossless in order to match the limitations of lossy mode.

I think the guy in charge of the webp project is the same guy who was the tech lead for On2 technologies and the same guy who is in charge of the Chrome Codec Team who unilaterally decided that there's no ecosystem interest in JXL. Jim Bankowski.

<a:yapping:1227693138215440395>

I did wonder if group size would have an effect on decode speed

Jeez, you must really dislike me. First you accuse me of not having appreciation for JXL devs that contributed to webp, and now a yapping emoji...

Pretty sure you can thank Jim for delivering webp to us in it's finished condition while at the same time also removing JXL from Chromium and its derivatives.

It does and so does jpegli. The chroma is quatized too much.

libjpeg-turbo provides okay quality at q=95 and chroma subsampling disabled for non-photo content. This can be losslessly transcoded to JXL. I think that could be an acceptable compromise.

Wait so what is the problem fundamentally with JPEG XL or random regressions in the encoder?

it's entirely down to the encoder

so the color regression is just because of the reference encoder,

Yes

It's a regression in the encoder. It's possible to design an encoder that makes different quality tradeoffs.

For manga and similar content, I would consider trying other lossy methods like lowering the bit depth under 8 bits or reducing the number of colors, so the encoder would use palette, and use lossless JXL encoding.

Similar concept like lossy PNG.

Delta pallete :>

I think, for black and white manga, 4 bit grayscale could work as well.

If I do ``ffmpeg -i in.jpg out.jxl`` is this a lossless conversion or do I need to specify something? I don't really understand the information I can find on this > ffmpeg version 5.1.4-0+deb12u1

ffmpeg doesn't support jpeg transcoding, there are a few applications and the reference command line tool that can though

Okay thank you

It’s better to use cjxl most of the time

yea, that will decode the jpeg to pixels and then encode it with VarDCT distance=1 effort=7

which is the default for the ffmpeg plugin

hey guys, im new to this whole thing and I dont completely understanding how all this works 🙂 I have a Mac and I've downloaded jpegxl via brew. now i want to use the jpegli encoder/decoder, how can I add it? the github page on jpegli doesnt help much

djpegli and cjpegli should be included CLI tools

They are actually NOT included in the Homebrew version as seperate binaries. Covered somewhere else, but I can't find it…

Actually the pull request was closed: https://github.com/Homebrew/homebrew-core/pull/167195 Not sure if the new https://github.com/google/jpegli is buildable on MacOS. Someone here at a higher pay scale may know

Closed by stalebot

I hate that so much

if you can change the homebrew build options, you need to have `-DJPEGXL_ENABLE_JPEGLI=ON` on the cmake command line

that will cause it to build jpegli

Mediainfo hasn't done anything to support jxl yet

:(

Still some difficulties to include Jpegli

I can't remember how I did it before, but wasn't there a way to render the MA tree as nodes in an SVG file?

jxl_from_tree can do it

Hmm, that doesn't seem right ```jxl_from_tree Tree.txt Test.jxl Tree.svg 'dot' is not recognized as an internal or external command, operable program or batch file.```

Did someone accidentally type `dot` instead of a `.`?

`dot` is a tool in graphviz package

this is what it looks like when converted (in svg)

or in png

Ahh right, it's a specific format for graphs. Had never heard of it before, neat

it is an old tool ! akin to LaTeX

v0.7 `benchmark_xl` can do it with `--debug_image_dir`. can't since then without patching the code

Is the x1 the quantisation multiplier?

https://discord.com/channels/794206087879852103/794206170445119489/1280280452170649610 Posted the small tool, but only have win64 binaries for now: https://github.com/kampidh/JXL-Frame-Stitcher

the help for cjxl-tiny says: "NOTE: <file in> is a .pfm file in linear SRGB colorspace" I assumed that the pfm files produced by djpegli would be in linear sRGB, however, encoding the resulting pfm file with both cjxl and cjxl-tiny produces very different results, the latter is much brighter, while the former matches the original:

So, what color space does djpegli output when the output format is pfm, and what'd be the best way to convert it to linear sRGB? Or is the pfm file in fact correct and it's cjxl-tiny that's messing something up?

probably gamma corrected sRGB

Does anyone know if there's a list of all the color space tags that djxl accepts?

`--color_space=RGB_D65_SRG_Per_Lin` appears to have done the trick

unfortunately, djpegli doesn't accept a color space parameter

I wanted one so bad too lmao

for RGB colorspaces, it’s RGB\_<white point>\_<primaries>\_<rendering intent>\_<transfer function>; primaries include SRG (Rec. 709), DCI (P3), 202 (Rec. 2020); transfer function, Lin (linear), SRG (sRGB), g<number> (gamma), PeQ (PQ), HLG, and maybe a few more I’m not thinking of

for grayscale, it’s `Gra` instead of `RGB`, and no primaries

(but still white point)

ty

basically, “how would I turn the value I want into three characters?”, hence the somewhat odd-looking “PeQ”

and the truncated “202”

So what does `--progressive_dc=2` do compared to 1? Seems to make a much more coarse preview than 1 while increasing filesize by over 10% instead of 1%

Why am I getting the "Getting pixel data failed" error on trying to convert an animated PNG file?

Might be related to this https://discord.com/channels/794206087879852103/804324493420920833/1284656561536630885

I'm using the 0.10.3 version

ah, I guess there might be a reason

Krita's custom sRGB profile

``` [libjxl @ 000001ce234b77c0] Unknown transfer function, assuming IEC61966-2-1/sRGB. Colors may be wrong. [libjxl @ 000001ce234b77c0] Unknown primaries, assuming BT.709/sRGB. Colors may be wrong. ``` from FFmpeg

There was a bug encoding APNG to JXL that was fixed with a commit made during 0.10.2 that didn't make it into 0.10.3. Do you have this problem with other APNGs too?

If yes, try 0.11.0 from the releases section on Github

oh, 0.11.0 just got released?

Looks like it works

I also don't think ffmpeg can encode animated JXL, can it? Or am I thinking of decoding, or something else...

Only decode

Unfortunately the resulting JXL animated file is bigger than the GIF file encoded by Krita beforehand

by some 90 KiB

It doesn't seem to have over 256 colors in every frame

``` --progressive_dc=-1..2 Number of progressive-DC frames, default = -1. -1 = encoder chooses. 0 = disable. 1 = extra 64x64 low-resolution pass. 2 = extra 512x512 and 64x64 passes.```

You should try e11😆

Huh... I would've expected a higher number to mean a lower resolution pass, not adding one 8x larger

It always has an 8x8 pass I think for VarDCT

That would be progressive AC

DC comes before AC

I know *

As in 8x8 pixels, or 8x upsample?

8x8 downscale

1:8

Now I'm trying to think if there's any reason for both a 64 and 512 DC in a file, since the 64 allows loading at 1% with a 1% filesize increase. The 512 adds over 10% which makes the same amount of bytes give a lower quality pass

it can be helpful for massive images

Maybe if <@206628065147748352> made some videos of regular, DC 1 and DC 2 on a high resolution camera image I might see the difference, but just truncating means a much lower quality for the same size (mine was a 4K image, would test 8 and maybe 16K but memory limitations stop me)

i guess it would probably be easier to just use Squeeze on the LF frame

higher LF level means you can use VarDCT (which is computationally cheaper than Modular) for midlevel LF frame while keeping Squeeze in high-level LF frame for maximum progressiveness. I think it's only useful for *huge* images, like, in scale of terapixels

~~do that for OpenTTD screenshots~~

Have a youtube livestream of an OpenTTD progressive decode running at 1KB/frame

Get a few days of ad revenue :P

Is there any beginner friendly way to convert my png files to lossless jxl?

I said beginner friendly because I'm not a terminal guy

https://github.com/kampidh/jxl-batch-converter

Perfect

Tahkns

Thanks*

XL converter (github.com/JacobDev1/xl-converter) Just make sure to preserve metadata (iinm metadata is discarded by default). Effort 7 is adequate, you can try higher for small images.

hello, not sure where exactly to ask: Is there a simple way to programmatically check if a JXL was transcoded from a JPEG? i have some scripts set up that allow me to quickly convert any image to jxl or convert jxl to png. i want to upgrade it so that it converts jxl to jpeg if it was originally transcoded from one. all i would need is something that tells me True or False if the jxl was transcoded. jxlinfo.exe outputs a bunch of text, but can i rely on it including the string "JPEG bitstream reconstruction data available"? or is there something more direct I can do

yes, currently to get an efficient jpeg transcode you would need a jbrd box

should i just run jxlinfo.exe and check for a line that says `box: type: "jbrd" size: [0-9]+, contents size: [0-9]+`?

If and only if jxlinfo says that, djxl will be able to reconstruct a jpeg. You can just grep for "JPEG bitstream reconstruction data available"

searching through/for human-readable text always feels a bit weird since there's no real guarantee that it won't change one day. like changing spelling or formatting

at least it's just my own personal script, so i'm the only person affected by it breaking after an update

parse the file then

If a Python script is any use to you: https://gist.github.com/alistair7/3dfbc021db19a9ff237f11a2c3561056 And if not, it shows how to parse the JXL container.

nice, thank you!

Does anyone know a better image viewer on Windows? ImageGlass is great but it doesn't support JXL/APNG animations and I can't get it to display colors wider than sRGB somehow.

I use [qimgv](https://github.com/easymodo/qimgv/releases), it's fast and easy to use with animated jxl/apng support. The only thing it doesn't have is color management. 😔

The unfortunate reality is that a lot image viewers are not color managed.

I find it ironic that the default Windows photo app handles color just fine. 😅

I really need to make a rust colormanagement crate that oculante can use xD

This isn't bad. Simple and effective. I think I'll keep using ImageGlass for most things, It's doing something weird with the colors on my wide gamut photos. This is much better than draging my animations into WaterFox though.

Hopefully with 24H2 and the new Photos app rolling out, the JXL plugin on the store will turn up soon... Also yay, another Resonite person

I haven't heard anything about MS adding support but maybe they'll just drop it out of nowhere like Apple did.

Also yes, figures there would be some overlap there lol. Does Resonite have JXL support? It's their own engine so they possibly could?

for quite a while now there has been references to JXL support in the Windows registry and the Windows SDK with said references getting changed around or added onto over time

Oh nice! I didn't know that. MS has been getting better with support recently, I know they added 7z pretty recently

Also this https://x.com/thiojoe/status/1841268514406928891

speaking of, apparently the extended archive support in Windows 11 is based on [libarchive](https://www.libarchive.org/) which sadly has pretty poor support for RAR as when testing against Windows 11 the first thing I did was make perfectly valid RAR archives that file explorer refused to open or would crash on which is a bit of a shame.

it's cool that they are trying at least

The Engine is deeply engrained with FreeImage... A 13 year old image library that they had to fork to fix the WebP security issues ages ago. Someone else asked for AVIF support, and shortly after one of the new devs said "He likes the format" so they got it working in the span of a week, but I don't think it's actually been merged https://github.com/Yellow-Dog-Man/Resonite-Issues/issues/1562

I think they also misunderstand the WebP settings, so they have 'quality' 100 lossless files with method 0 because 6 was too slow. Wanted to try an edited version with different settings but I can't recompile myself https://github.com/Yellow-Dog-Man/FreeImage/pull/9

Oh, I should point out the game uses WebP internally for photos and image storage. With Froox (Head dev) saying he wants to use AVIF in future because it's newer... I'd spend a week explaining 'lossless' AVIF but I already bullied him about BC7 compression and feel bad xD

Would JXL be a good replacement for all 3 of those formats? As I understand it AVIF might be better on the far low end BC7 is game engine optimized so I'm not sure how JXL would fare for framerate.

AVIF would only be better in the range that you would likely see visible compression artifacts so IMO it has no place near a game engine

well quality wise

when it comes to decoding, dav1d is really good at what it does on little threads, and can often perform better then jxl when it comes strictly to decoding images.

games and apps can ship a jxl library just fine and do not depend on anyone else's adoption

Also speed-wise, avif performs best for low-quality. At higher quality it gets slower for both encode and decode, while for 8-bit 420 at low quality it is faster. In libjxl we don't currently have much specialized code paths for lower precision, there's a compile option for lower precision that has some specializations but mostly it's all just float32.

for 2d-heavy games, lossless webp does the trick since it can get more agressive filesize gains, jxl is better mostly since it has comparatively fewer limitations and higher capabilities like hdr and quicker decode (for slow media like sd cards)

AVIF is awful at lossless, so JXL could be on par with WebP at 10x the speed or a smaller file at the same speed (And much lower memory usage, which the game really needs) For lossy, AVIF could work for the world previews, but it's even slower and more expensive than WebP so there could be a lot of delay In the end all images have to go to the GPU, most of the time either that's BC1 or BC7, with 7 being higher quality at double the memory usage and slower compression. I made another issue asking for GPU BC7 encoding to make it almost instant, since I'd prefer a 2 second lockup to 2 minutes of stuttering when handing very large textures

Issue is the game is built on .NET, and uses FreeImage for all image handing currently. So it's more likely to change image library entirely if adding new formats, otherwise the library needs .NET bindings which libjxl doesn't have

I should also add context, Resonite is similar to VRChat but the content is edited during runtime. So assets are constantly streamed from CDNs and between users P2P, usually converting to BC formats client side before upload to the cloud, where more variants are generated for ASTC, ect

The original filesize counts towards your storage quota, so using optimized images lowers the storage hit while the GPU variants are 'free'

Wait so if textures are just converted to BC what would be the benefit of using alternate codecs? Is it just the file size on your personal cloud storage or would there be some engine upside to using it?

Really it depends on how long they're willing to spend on it. They could do progressive loading with the 1:8 sizes you get for free, faster screenshots/saving, lower memory usage, less CPU usage, HDR textures for things like skyboxes, JPEG transcoding to lower storage costs and CDN fees for free

Probably more but I'm crawling into bed

yeah I'm looking closer at it and for lossless they are setting "quality" to 100 which well only affects compression effort because both "quality" and "method" affect only speed in lossless which isn't very intuitive

so "method" being set to `6` was probably activating the lossless cruncher since it's activated only when "method" and "quality" are both set to max

https://github.com/Yellow-Dog-Man/FreeImage/pull/17

Ah, you made a PR already. I did months ago but it was changing the threads setting instead since they lowered it from 6 to 1, then learned it doesn't use more than 2 on crunching anyway. Actually, I really don't know why I didn't make a PR before. I already did the tests of quality/method combinations to measure speed:density ratios

And apparently it was an issue not a PR I made... Guess I was still nervous about touching any code back then

Seems like Froox deleted our messages on Telegram so I guess I'll never know why I didn't. Hopefully this goes through this time

Remade my benchmarks and left a comment. Method 1 Quality 20 for Lossless, Method 5 and enabling SharpYUV for lossy since the game tends to have vibrant colors that need it

moving to https://discord.com/channels/794206087879852103/805176455658733570: https://discord.com/channels/794206087879852103/805176455658733570/1292866913210339430

```RGB, D65, Rec.2100 primaries, HLG transfer function```

does `ssimulacra2` report 100.0 upon error?

I have a PNG and a corresponding JXL file that ssimulacra2 is reporting 100.0000 as the score

(they aren't the same)

``` $ ssimulacra2 Elia.png Elia-h2.jxl 100.00000000 $ djxl Elia-h2.jxl Elia-h2.png JPEG XL decoder v0.12.0 c6355600 [AVX2] Decoded to pixels. 3600 x 2500, 13.964 MP/s [13.96, 13.96], , 1 reps, 8 threads. $ ssimulacra2 Elia.png Elia-h2.png -9.11341708 ```

upon djxling the file, the score is -9

the file itself is a hydrium encode that isn't corrupt but is bugged, so the actual score should be in the 70 range probably

What does butteraugli say?

Huh strange

Can you open an issue about this? The difference between a jxl and a decoded PNG should not be large, question is where the bug is.

in this case the difference is between the original PNG and the encoded JXL should be in the less than 100.00 range but it's actually 100.00

decoding the JXL to PNG first and then running ssimulacra2 should produce identical results

`butteraugli_main` also produces wildly different results for the jxl file and the corresponding decoded png

are they only decoding the first Frame?

is that the issue?

it's a Hydrium encode so multiple `Frame`s are present

``` $ djxl Elia-h2.jxl Elia-h2.png JPEG XL decoder v0.12.0 c6355600 [AVX2] Decoded to pixels. 3600 x 2500, 13.755 MP/s [13.76, 13.76], , 1 reps, 8 threads. $ butteraugli_main Elia.png Elia-h2.jxl 273777.6250000000 3-norm: 48609.677564 $ butteraugli_main Elia.png Elia-h2.png 137.6842346191 3-norm: 27.868563 ```

most of the frames are Skip Progressive. the only one that is Regular is the last frame

that's probably not the issue cause it's also happening for a one-frame encode

interesting

let me see if I can reproduce it with a smaller file

one that I'm permitted to share as well

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

Must be something weird going on in how they load those jxl files

I think it's cause the JXL file is overflowing

Oh

which is totally legal

And the PNG is clamped

but it still shouldn't produce 100.000 as a score though

No that is weird, shouldn't happen unless the images are identical

in other news I did fix the hydrium bug that caused the JXL files to overflow. turns out the issue was with partial blocks

I allocated a buffer for them but didn't zero out the buffer so they were filled with garbage

which in theory shouldn't matter but when they're filled with random data that isn't zero it can mess up the DCT roundoff

by zeroing out the padding before forward DCT everything is working now

still fixing bugs in hydrium before I start working on speed and options

I did do some profiling. right now `hydrium` is fairly comparable to `cjxl -d 1 -e 4` on a single thread, in both speed and quality. it loses in density but wins dramatically in RAM usage

memusage reports a max mem usage of about 300 MB for this test 3600x2500 file using cjxl, and hydrium caps out at around 100 MB for the `--one-frame` mode and the lower tile sizes can drop it as low as 6 MB

density for this file is about 1.5M for cjxl and about 2M for hydrium, so it's got a ways to go in density

that's 6 MB including libspng, it's ~2.5M from libhydrium itself and 3.5M from the png decoder

this is also with no intrinsics and no simd other than compiler autovectorization

I also don't rely on any instructions like fma that the compiler can't generate for me

(i.e. `a * b + c` will be optimized into fma by gcc provided you pass `-ffp-contract=fast`

Is there any "fire and forget" tool to denoise and/or remove artifacts from jpg so that recompression with jxl d=1 would be more efficient?

I've heard waifu or Nunif but I haven't tested it yet

Or do you always have to carefully check each image if you lost too much detail?

Don't use d=1

Use d=0 j=1

The current lossy encoder is not that efficient and it's not guaranteed to be smaller than the input JPEG but lossless mode works perfect.

Maybe in the future lossy mode will also be guaranteed smaller but right now it isn't efficient and just encodes the jpeg as if it were a normal pixmap

Yeah. But on some of the webtoons even d=2 doesn't seem to make a visual difference, so I'm wondering how much I could push it. Basically my idea would be, if you could "reconstruct the original uncompressed version" using some AI magic, how much could you recompress

It could possibly do something where it still uses the JPEG coefficients but does some adaptive extra quantisation or something

Exactly

Like go from Low quality jpeg -[AI?]-> High quality -> pixels -> JXL?

Yeah kinda

Only thing is I don’t think you can merge coefficients like with VarDCT

It would probably be more akin to e3 / e4

But current libjxl doesn't do that. Hopefully someone modifies it to re-use and requantize the existing dct coefficients instead of naively starting from scratch

Although most of the time you probably want lossless transcode

JXL’s lossless mode is actually pretty good at photographic

I don't see why you wouldn't be able to merge blocks.

I mean if you had the originals, a more efficient lossy jxl encoder should produce much better results than jpg trans-coding. So I'm wondering if with AI magic you could achieve something like that

Not sure if dct coefficients can just be merged as it is applied to the entire block

We're talking about jpeg here. Every block is basically the same quantization factors

So I think merging them would be trivial?

This is frequency domain though there is no concept of location

Hmm, good point.

I can’t think of any way to take 2 sets of 8x8 coefficients and merge them into 8x16 without any IDCT

If we were is pixel domain yes

Like for Modular it would be relatively trivial (just some tree reorganisation) as that runs in pixel domain

I wonder if you could train an AI model to work on the jpg 8x8 coefficients to restore the original image

You could merge adjacent blocks only if they were similar frequency to begin with

As in given the quantisation matrix and the dct, output another set of dct coefficients without IDCT?

I don't quite understand how dct works, but I mean the original pixel data used for jpg compression

Like you'd train an AI model on doing that

DCT is converting pixel domain to frequency domain through a new domain name and then converting it to a different type

Not great at explaining

That's fine, I'm not great at math 😉

It basically produces a spectrogram

I wonder if there are any lossy image compression that doesn’t ever go to frequency domain through DCT / FFT / Wavelets

I have a nebulous understanding of this like ripples in a pot of water to describe the image, but I don't truly understand it

So instead of pixels it's frequency

I guess modular lossy JXL with squeeze turned off?

I don't think squeeze is frequency domain...

Unless you really have a broad definition of it

It's just resizing the image basically.

Anyway, if you had an AI tool to "restore" the original pixels from a jpg, and then recompress using jxl, it would be interesting to see a benchmark

Like test it with butteraugli distance to original uncompressed image

Storing multiple smaller copies of the image that can be reversibly reconstructed into the larger one

Since the jpg then would already have a butteraugli distance to the original pixels, a jxl recompression (of an AI restored version) with say d=2 might be able to beat jpg

But if you have the original uncompressed image you shouldn't use an AI to guess... ;)

Well that would be just for benchmarking the result, normally you wouldn't have the original of course

I'm just trying to crunch shitty webtoons here 😄

You sure you don't want lossless? It's the most future proof...

Lossy libjxl 0.10 is nothing to write home to your mom about yet

Well yeah that is the sensible solution of course

It has a lot of room to improve still

To answer my own question Real-ESRGAN is easy to use and seems pretty awesome

Squeeze is also a frequency transform but the way it is used by default only applies the recursive step to the LF part, so most of the HF residuals are kind of still more or less in the pixel domain.

how is there a LF/HF split with Modular?

If there is no squeeze, it's just all HF. With squeeze, things get divided over sections in such a way that the 1:8 data is available together with the VarDCT LF, and in case of more progressive passes (for 1:4 and 1:2), the modular data is in the corresponding sections. So in principle you can do VarDCT with alpha and whatever other extra channels and have it fully progressive.

Because when you resize an image and make a smaller version of it you’re probably doing a lowpass

i thought modular was trees?

how do you cut a tree into parts?

i expect you squeeze first, then (optionally) predict the squeeze-transformed data with a tree

so there are 2 trees??

JPEG XL: The Forest Codec

So regarding my previous idea, playing around with real-esregan it seems possible. I 4x upscaled a 2k comic book (800x1131) then downscaling to fit into 4k / 2160p and using distance 8 you get a smaller file that appears to look sharper and better

there are models for 1x jpeg artifact reduction. but none of these models are mathematically reliable, inventing information

There can be a global tree but you can also have a local tree per modular bitstream. In any case, the section id, group id and channel id are all properties the tree decision nodes can use, so whether you do things as one big global tree or several local trees doesn't make that much of a difference, the expressivity is the same.

Well as long as they are good at inventing 😉

with comic-like art, possibly <https://github.com/victorvde/jpeg2png> can offer you a mathematically sound result, but you may have to experiment with iterations so you don't oversmooth

Well with realesregan the anime model actually looks worse, removing too much detail and inventing too much. I imagine this depends if you "overdo it", like use a too low size input

Theoretically, compression-wise it's better to compress the smaller input and then use a GAN as a "decompression" algorithm. I imagine that is how the next generation of compression algorithms work. Learning how (e.g.) faces are supposed to look and then using that to compress stuff

I was wondering when someone would bring up jpeg2png and https://github.com/ilyakurdyukov/jpeg-quantsmooth

Thanks google...

It attempts to 'guess' the quantized values and outputs a 'quality 100' jpeg from the input

tbh I had better results with some ai models, e.g. waifu2x

Yeah, it's just a non 'black box' AI solution

true but it was too smooth sometimes

making a JPEG decoder that tries to maximize realism (i.e. matches the distribution of natural images, a la stable diffusion) while still being constrained to produce spec-conformant pixels should not take *too* long for people that know how to do those things

The issue is finding someone who's both an AI expert and a JPEG expert at the same time, which is something I see a lot. Just throwing a neural net at the problem instead of using it for the actually tricky parts and within a range that's already possible

I use waifu2x to remove jpeg artifacts

Yeah I still have to try that out, but don't have enough space for the installation Real-Esregan only needs 50mb and is quite interesting, but does a lot more than just remove artifacts. I think it's stable diffusion based so changes and reinterprets the image much more

I use waifu2x-ncnn-vulkan

Ah thanks, will give that a try

it's a package on arch, maybe in the AUR

dunno on windows if it's a thing

Yeah works same as real-esregan, but less "aggressive"

`waifu2x-ncnn-vulkan` is only 35MB there is also 1x_JPEG_60-80.pth from BlueAmulet which is 64MB, better than waifu2x in most of my tests imo

well I guess there are some dependencies taking space, but idk how much

Right now my waifu is using 1.2GB, but I have an oooold version from 2019

Interesting, but 2x upscale is quite nice too.

So ncnn and pytorch are kinda like runtime environments for these models?

https://github.com/victorvde/jpeg2png is a brute force denoiser for jpg (no neural network) which works very well for drawings but is a bit aggressive on photos. Dev stalled 9 years ago... There is another one in the same category. but I can't remember the name

The other one is https://github.com/google/knusperli ... I wonder why I forgot the name... The author is a little known swiss

Google seems to have successfully invaded Switzerland haha

So many AI models for super-resolution! I'll need an AI model to determine which AI model is best suited for the images lol

you want some more reasons to hesitate ? https://github.com/wenbihan/reproducible-image-denoising-state-of-the-art

for pytorch models I simply use chaiNNer, easy UI for deps and workflow and just checked, ncnn is only 11MB so `waifu2x-ncnn-vulkan` is really small size

Thanks, I've been lazy and not reading up on how all the AI stuff works

I just need to upgrade my PC for those big SDKs

There are even models for halftone removal!

just pick one from openmodeldb

Yeah chaiNNer is almost perfect for my use case if it could save JXL. And load and save images in zip files / comic book archive. But should be easy to extend

I'm going to call it chainNo from now on. Chaino unclogs and cleans your jpegs!

What would be cool for chainner would be if you could remove the noise and then generate photon noise parameters or a noise LUT, and then plug than into the save image for jxl and avif again

Does libjxl have something like that? I know svt has

It has adaptive noise, but I think it's broken in cjxl currently

Basically subtract two images, original and cleaned, and then generate a jxl noise lut. But I'm basically just spewing buzzwords here, I only have a vague understanding how this works. A lookup table depending on luminance of pixel and a corresponding frequency for the generate noise? That would be like a small 2D image

> I know svt has This sounds cool. Is there anywhere I could read up on that in detail?

Hmm, it was aom enc not svt, and I think it was here: <https://aomedia.googlesource.com/aom/+/refs/heads/main/examples/noise_model.c>

SVT also has something like, but I don't quite know what this does. I only scrubbed through that source: <https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/test/noise_model_test.cc?ref_type=heads> There is another example code file too

Thought I'd try and use benchmark_xl to get VarDCT visualisations again, but seems this still isn't fixed https://github.com/libjxl/libjxl/issues/2287

```benchmark_xl --debug_image_dir="C:\Users\jonat\Downloads" --inner_threads=8 --input="C:\Users\jonat\Pictures\Screenshots\Screenshot (825).png" benchmark_xl v0.12.0 bc12b30 [AVX2,SSE2] 16 total threads, 1 tasks, 0 threads, 8 inner threads Error in jxl codec There were error(s) in the benchmark. Allocation count: 0, total: 0.000000E+00 (max bytes in use: 0.000000E+00)``` ```benchmark_xl --inner_threads=8 --input="C:\Users\jonat\Pictures\Screenshots\Screenshot (825).png" benchmark_xl v0.12.0 bc12b30 [AVX2,SSE2] 16 total threads, 1 tasks, 0 threads, 8 inner threads (Results) Allocation count: 3035, total: 6.800554E+08 (max bytes in use: 1.676737E+08)```

FBCNN maybe

why would you do this to yourself

Sayajin dejpeg and FBCNN should be better than blueamulets

I found a python script that decodes the gainmap and converts iPhone HEIC HDR files to PNG, and modified it to convert to PFM, so it can can be more easily used to encode to JPEG XL. https://github.com/CrushedAsian255/apple-hdr-heic

Thanks all for all these links, all these codes are super interesting. For my purposes, mild upscaling (~ 1.6 to 2.0x) and mild jpeg cleanup for sprucing up medium quality manga or manhwa, those stable diffusion AI models seem to be best.

yeah but how do you get a working FBCNN executable ? nothing in the AUR, they don't have any release, ...

There is a .pth model you can download and use but I haven't set that up yet. They also mention <https://huggingface.co/spaces/danielsapit/JPEG_Artifacts_Removal> which doesn't work. If you search for "JPEG_Artifacts_Removal" there are forks that also don't work.

But since I don't understand this stuff that is to be expected of my efforts 😄

use pth in chainner or git clone and use conda

oh righr they hace a release I don't why I didn't see it lmao, and I already use chaiNNer with other stuff

Oh hey, the MB/s is working again `5120 x 3840, geomean: 127.239 MP/s [115.22, 133.55], geomean: 24.672 MB/s [22.34, 25.90], 10 reps, 16 threads.`

I'm trying to use ffmpeg libplacebo to create linear grayscale float jxls, but for some reason it's coming out way too light ``` # Linear 16-bit grayscale comes out fine fmpeg -i in.png -init_hw_device vulkan -vf "libplacebo=saturation=0:color_trc=linear:format=gray16" -distance 0.0 out.jxl # Linear float32 grayscale comes out way too light fmpeg -i in.png -init_hw_device vulkan -vf "libplacebo=saturation=0:color_trc=linear:format=grayf32" -distance 0.0 out.jxl ``` Anyone know what I'm doing wrong here? jxlinfo says everything's correctly tagged, so clearly something is going wrong somewhere in the pipeline

can you show what jxlinfo says?

`saturation=0` is the problem

``` jxlinfo out.jxl JPEG XL image, 256x256, lossy, 32-bit float (8 exponent bits) Grayscale Color space: Grayscale, D65, Linear transfer function, rendering intent: Relative ```

very hacky but this works: ``` fmpeg -i in.png -init_hw_device vulkan -vf "libplacebo=saturation=0:color_trc=linear:format=gbrpf32,extractplanes=r" -distance 0.0 out.jxl ```

don't do that

don't do saturation=0

there's no reason to do that

but you are correct that grayf32 is coming out too light

ah yeah I only put that saturation=0 in there for testing, 'cause I wanted to make sure the problem wasn't that it was just grabbing eg the red channel rather than mixing them

if you want you can force the matrix to be e.g. bt709

and then it'll just take the Y channel

as in`libplacebo=colorspace=bt709:color_trc=linear:format=grayf32`? still comes out too light...

I have determined it's a libjxl bug, and not a bug with libplacebo or ffmpeg

how to test:

step 1: george.pfm

step 2: `convert george.pfm george.png`

`umbrielpng --cicp-prim=bt709 --cicp-trc=linear --fix-in-place george-16.png`

(this tags it as linear)

step 3:

`cjxl -d 0 -x color_space=Gra_D65_Rel_Lin_SRG george.pfm out1.jxl`

`cjxl -d 0 george-16.png out2.jxl`

wait, hm

now it's not

now it's not doing anything weird <:Madge:859968580996956200>

`ffmpeg -i butterfly.png -init_hw_device vulkan -vf "libplacebo=format=grayf32:color_trc=linear" -distance 0 butterfly-32.jxl` `ffmpeg -i butterfly.png -init_hw_device vulkan -vf "libplacebo=format=grayf32:color_trc=linear" butterfly-32.pfm` identical results, so probably not libjxl

ye, I think there may be some sort of white-point compensation happening with libplacebo that's not happening with gray input

just tested, it only has any difference with gray

also tested, it is indeed not an issue with the libjxl wrapper or libjxl

it looks like the pfm and png output is also having the issue

also compared the 16-bit png input to hydrium and libjxl and got similar results

reported, here's irc log ``` [2024-12-04_21:19:25] <Traneptora> do ffmpeg -i in.png -vf libplacebo=format=grayf32 out.pfm [2024-12-04_21:19:33] <Traneptora> then compare in.png to out.pfm using e.g. mpv [2024-12-04_21:22:43] <Traneptora> https://0x0.st/X7W3.png https://0x0.st/X7WY.png [2024-12-04_21:23:02] <Traneptora> ffmpeg -i george-gray.png -vf libplacebo=format=grayf32 test.pfm [2024-12-04_21:23:08] <Traneptora> and then mpv --no-config --pause --screenshot-format=png george-gray.png test.pfm [2024-12-04_21:23:12] <Traneptora> take Ctrl+s screenshots [2024-12-04_21:23:30] <Traneptora> adding :range=pc to the libplacebo command doesn't change anything ```

thank you!

Stretching this channel a bit, but does anyone know of (ideally) a WASM tool that uses blue noise dithering, or even better anything that uses the gaussian blue noise mentioned the other day? So far I've only found Surma's old tool https://surma.dev/lab/ditherpunk/lab

noticed that the JXL toolchain distributed by Nixpkgs no longer contains `jpegli` as of `0.11.1` is this intentional upstream?

jpegli has been moved to its own repository

hopefully someone can also begin building `jpegli` for Nixpkgs

Homebrew failed to include `jpegli`

Please just merge it back into libjxl...

There's no reason to separate it... just separate the dependency-ridden cjxl/djxl code from the library code!

:(

Nothing else needs to be separated

possibly jpegli could even be integrated into libjxl (definitely djpegli)

as its based on similar technologies

They never should have been separated... the only thing that makes sense to separate is the example tools that require a lot of external dependencies to build

You know. Things that **actually** affect how convenient it is for library users to build the library.

is there a WASM build of SSIMULACRA2 for use in web browsers and Deno?

In principle I'm totally fine with the projects being separated, might even be useful considering the option to replace libjpeg libraries with jpegli ones... However, you currently can't simply build jpegli from the jpegli repository without conflicting with a bunch of libjxl stuff. Not even by setting cmake flags. And jpegli currently also isn't versioned.

No wonder jpegli isn't packaged anywhere.

It would be nice if it also would install jpegli header file for software that wants to use `jpegli_` api and also maybe a libjpeg header file that allows you to compile existing software to use jpegli instead, by macroing all `jpeg_` calls to `jpegli_`

So the compiled software uses jpegli symbols instead of libjpeg ones

yeah

Anyone here know of a tool (preferably commandline) to attach an icc profile to a jpeg or png without modifying other data structures?

Exiftool?

I thought that's a read only tool

Nope it can write too

Okay here's another neat question for ya nerdy bunch. I have an EDID binary image from my monitor firmware, the EDID data structure contains white point and chromacity coordinate data and gamma information. How do I create a color profile based off this data? Why can't I find a tool that does this?

Do I have to parse it myself with perl cuz I don't even know what illuminant these chromacity coordinates are in reference to in the edid data structure

d50 like same as icc pcs?

edid spec says the coordinates are according to "CIE publication 15.2"

Has no one wrote a perl script to convert an edid.bin to an icc profile? :(

I believe DisplayCal can do it

correct

it doesn’t take the edid.bin as input; it just reads it directly from the display

I don''t know if the gui can use bin files, but if you use the python api it can

note that the white point and gamma in the edid are probably useless

iirc the white point is technically supposed to match the monitor's out of the box settings

i'd just use edid-decode and copy over the primaries to displaycal's synthetic profile creator

Displaycal has a Python api and a gui profile creator?

Can't save an .icc profile :(

yay python

seems like a bug in the python 3 port

(the upstream is still python 2 iirc)

ah, right, Arch is getting it from https://github.com/eoyilmaz/displaycal-py3

might be worth raising an issue there

ah, python2 is not available on arch anymore and is utterly discontinued upstream and not receiving security fixes from the python project.

pip the python2 version