JPEG XL

similar but the only warning was `Warning : [minor] Text/EXIF chunk(s) found after PNG IDAT (may be ignored by some readers)`

I am rebuilding libjxl now to get some more data

well building it like that didn't work

``` build() { export CFLAGS+=' -ffat-lto-objects' export CXXFLAGS+=' -ffat-lto-objects' cmake -B build -S libjxl \ -G 'Unix Makefiles' \ -DCMAKE_BUILD_TYPE:STRING='Debug' \ -DCMAKE_INSTALL_PREFIX:PATH='/usr' \ -DJPEGXL_ENABLE_BENCHMARK:BOOL='false' \ -DJPEGXL_ENABLE_EXAMPLES:BOOL='false' \ -DJPEGXL_ENABLE_FUZZERS:BOOL='false' \ -DJPEGXL_ENABLE_OPENEXR:BOOL='false' \ -DJPEGXL_ENABLE_PLUGINS:BOOL='true' \ -DJPEGXL_ENABLE_VIEWERS:BOOL='false' \ -DJPEGXL_FORCE_SYSTEM_BROTLI:BOOL='true' \ -DJPEGXL_FORCE_SYSTEM_GTEST:BOOL='true' \ -DJPEGXL_FORCE_SYSTEM_HWY:BOOL='true' \ -DJPEGXL_BUNDLE_LIBPNG:BOOL='NO' \ -DJPEGXL_INSTALL_JARDIR='/usr/share/java' \ -Wno-dev cmake --build build make -C build doc } ```

oh well, ill try ci.sh

interesting ``` libpng warning: iCCP: known incorrect sRGB profile lib/extras/dec/apng.cc:1079: JXL_FAILURE: Repeated iCCP / sRGB chunk lib/extras/dec/decode.cc:151: JXL_FAILURE: Codecs failed to decode Getting pixel data failed. ```

sRGB and iCCP are mutually exclusive according to the spec, but some decoders/apps are permissive I guess

it doesn't seem like it, at least in https://www.w3.org/TR/2003/REC-PNG-20031110/#11sRGB rather, what the spec "implies" that with `11.3.3.3 iCCP Embedded ICC profile` > A PNG datastream should contain at most one embedded profile, whether specified explicitly with an iCCP chunk or implicitly with an sRGB chunk. but then *explicitly contradicts it* in `11.3.3.5 sRGB Standard RGB colour space` by *reccomending* that they do not both appear but do not prohibit it > It is recommended that the sRGB and iCCP chunks do not both appear in a PNG datastream.

this seems like a mistaken in the spec when they ment to prohibit it, but failed to do so

https://github.com/libjxl/libjxl/issues/4087#issuecomment-2615216732

so apparently 3rd edition resolves the ambiguity

Tried to render a quick test image in Blender to get float files for benchmarking. Turns out Blender renders to a float16 image, even though it shows 32bit export options. No clue if I can increase it to 32bit anywhere, but the file hashes of PFM and JXL matched with the EXR being double the size

the multithreading in the encoder makes me wish I had a threadripper

imagine it just zooming through the image<:BlobYay:806132268186861619>

libjxl has extremely poor sub-linear scaling across threads

After about 3 or 4 threads it just stops getting faster

Depends on image resolution, group size and other options

Decoding and lossy and e1-e3 lossless encoding should scale quite well, lossless e4+ encoding scales poorly.

Huh, didn't know the game had a dithering setting

Nah. Even large 30 megapixel images with lossless e2 does not scale above 3 threads.

at compression that is

Haven't tried decompression

Someone should test on different hardware than mine and measure multi core scaling

On my system it does well up to 3 threads but just doesn't go any higher than that, aside from wasting power

But it might do better on a different system, who knows?

What kinda old hardware are you using? I see diminishing returns around 8 threads for a 45 MP image on a intel core i5-12400.

A possible bottleneck I can think of is memory throughput due to the ram-heavy nature of libjxl.

Yes, likely things get bottlenecked by the memory bus.

https://almanac.httparchive.org/en/2024/media

Aaah, maybe that's it. I'm on an old old system

Must be the memory bus

That Bayer dithering gives jxl real retro vibes, considering it's being applied to most vardct images.

Sometimes it hurts dark flat areas

It appears even in losslessly transcoded regular jpegs.

Yeah, I did a lot of testing around that https://discord.com/channels/794206087879852103/804324493420920833/1301648402664263730

Anyway, the Bayer matrix is an interesting choice, it reminds me old Windows running with 16 color graphics.

https://www.dpreview.com/news/8799733255/canon-shows-why-optical-and-in-body-stabilization-both-have-a-place > Thanks to forum member spider-mario for bringing this diagram to our attention. 😎

When a few of us were in the voice channel, <@207980494892040194> made a version that used blue noise instead. It worked well, but needed tuning

https://cdn.discordapp.com/attachments/804324493420920833/1313028719656435753/noise-comp.webp?ex=67a25c09&is=67a10a89&hm=436c2797b4e3515836bdefc3f708fffad58411f3256ef198387cb227544a2d32&

I should make a draft PR for that

If I need to do anything with images, I usually reconstruct the original jpegs and use those, so I don't get any dithering.

I'm not sure if jxl decoder is the right place to perfom dithering. I think dithering should be done as the last step when the pixels are being rendered to the screen.

Well, considering that JXL supports 8-bit RGB, that is not necessarily an option at all.

When reducing bit depth, you want to dither, and that's what's happening in the decoder.

Because it decodes the internal jpeg as float32

Not actually sure if you can disable it in libjxl, but it'd be nice to have a flag for djxl at least

In case of 8 bit source material, it seems that jxl is trying to add something that wasn't there.

If dithering is desirable, what about more advanced techniques, like Floyd-Steinberg?

Floyd-Steinberg is a bit too slow as far as I know

That's why we chose blue noise, it's a good balance of speed and quality

Floyd-Steinberg has been used for decades and it seems to be the most popular dithering method in general.

The key is avoiding repetition. This is floyd and a poor attempt at blue noise

Or, I just squint and see what turns into a gradient first

Also, because JXL does animation, error diffusion could be distracting, so a fixed LUT is better

Hmmm would it be possible to use the photon noise feature to do dithering as well?

It's already in the codec.

https://surma.dev/lab/ditherpunk/lab

Yes, there was actually a blog post about it which I've never been able to find again

A flag to disable dithering would be relatively easy to add. I should probably work on that instead of trying to compile libjxl on Windows 😅

Another option is using an old version of the decoder. 😄

why would you ever disable dithering? You can just decode to a higher bit depth...

that doesn't look like true blue noise, there's lots of LF energy...

Hence "a poor attempt", it was using the site I linked

When the source was 8-bit to begin with, decoding to higher means either PPM (Too niche to share) or PNG (16-bit means too large to share)

argh moiree patterns

Yeah, that's why we want to move away from Bayer

Bayer, Floyd, 'Blue Noise'

Spent the past half hour trying to make a new blue noise image, but can't find any online tool to convert and only GIMP came up with a filter for it

Why would you ever NOT dither 8 bit output? That's just plain wrong

That's like put toothpaste in your coffee levels of wrong

Because the original image never had dithering?

Yeah but we are talking about lossy right? The original is gone and doesn't matter

In lossless there is no dither

In that case just use AVIF if you don't care about the original :P

The dithering adds bayer patterns to dark flat areas that never had a gradient in the first place

No. The original doesn't factor into this. It's not that I don't care about the original. It's actually more true fidelity to the original if you dither 8 bit output even if the original wasn't dithered

Because the image is being processed and converted into a different format and back again. It would be like if you converted an sRGB image into ProPhoto and back. You are applying a transformation to the image at high precision and when going back to low precision you need to dither again every time

Any time you do some kind of transformation and edit to the pixels at high precision those pixels need to be redithered when going back to the original low precision after the lossy transformation

The closest analogy I can think of is, that would be like resampling without doing a lowpass filter first

And getting really strong moire patterns in your output that weren't in the original

Dithering is necessary, otherwise you get stripes and bands and other weird lines and creases that weren't in the original

What if banding was the original? What if you want to *preserve* the banding?? <:KekDog:805390049033191445>

Original, djxl, jxl-oxide. It's a small example, but I can't be bothered to find another real-world example when I already linked to it above

Don't get us wrong, by default dithering is usually better and it will stay that way.

The banding will probably still be there if it's in the original. Jxl is not supposed to smooth over visually noticeable image features.

Dithering cannot smooth things either

That's exactly what it is doing https://discord.com/channels/794206087879852103/804324493420920833/1301649129541337148

At more reasonable zoom levels, it causes patterns and draws the eye to what's meant to be flat/smooth areas

Hence wanting blue noise so there is no pattern to notice

There have been times where I didn't want dithering, and there have been times I wanted gamma *incorrect* scaling.

Those cases are very rare, but having it as an optional flag comes at no cost

I still think all color management, scaling etc. should be done before dithering.

> Effectiveness of audio noise reduction varies by lens. (https://cam.start.canon/en/C005/manual/html/UG-04_Shooting-2_0070.html) … what

Ahh, they're talking about mechanical lens sounds

> When recording with the built-in microphone, this feature reduces mechanical lens sounds caused by autofocusing, as well as white noise.

ah, that makes more sense

i've always found built in mics terrible and honestly pointless at this point, if you are spending money on a higher quality camera for video recording, its worth it to just look for one with mic in and attach even a cheap shotgun mic to it. they are "good enough" for most cases and small enough to fit on even go pros now

or a separate recorder so you don’t even need to connect it to the camera

(to the point that you can film with your phone if you like)

DaVinci Resolve can then sync it with the camera’s built-in audio in two clicks in post

(and then you can delete the camera’s audio track altogether)

yup, recorders are for sure nice, I had a camera body mount that my phone could go into so I could use it has a recorder and a screen window, worked well

But the quartz clock in the recorder is going to be out of sync with the camera if they are separate...

You'll have to manually sync and account for drift if it's a long enough recording

I have not found this to be an issue in practice

> In the early days of portable digital recorders, Samson launched the “Zoom” line of recorders, but used pretty cheap commodity clock crystals like you might find in a PC, maybe 100–200ppm. What you would find is that, in a few minutes, the camera sound and the recorder sound would be pretty clearly walking away from one another. They fixed this in subsequent models like their H4n, and all of a sudden became the go-to recorder for video sync use.

It's rare for two separate clocks to not have drift

*some* modern devices can avoid clock drift by knowing it's an issue, and re syncing video according to synchronized time, it isn't super perfect and won't ever be used scientifically in place of genlock, but is typically "good enough"

ugh, more issues with decoding pngs in cjxl hitting this issue https://github.com/libjxl/libjxl/issues/3973 T.T

which tool do you use for Fant downscaling ? Even Gimp doesn't seem to have it [⠀](https://cdn.discordapp.com/emojis/654081052108652544.webp?size=48&name=av1_Hmmm)

oh, it's a thing from paint.NET any tool that I can use in Linux with Fant downscaling ?

Gimp also works

Let me double check real quick

Yup, downscaling the image using bicubic or linear algorithms with integer divisors (1/2, 1/3, 1/4, so on) results in the same scaling as fant/box.

It looks even better than libplacebo's special "ewa" algorithims I'll be honest

oh nice, thank you for testing ❤️

libplacebo's scalers really aren't that special, what is special is using glsl scalers

That makes sense

Here is another comparison for fun

For some reason libplacebo can't handle RGB with alpha

libplacebo itself can, but iirc its ffmpeg stuff is not wired up?

What the fuuuuuuuuck? If I zoom on one particular WebP in Irfanview, trying to pan makes the antimalware service start chugging and make the panning stutter

Even stranger, it's location dependant, but putting it into an excluded folder doesn't help

gpu skill issue?

5.0% really isn't much

It doesn't use the GPU, it's image decoding :P

Well, not even decoding, panning rather

it uses it for rendering though doesn't it? panning would be rendering domain

It works fine in my Downloads folder, no stutter. Trying it in the original folder, or a Defender excluded one, causes stuttering and Antimalware CPU usage

Does it do this persistently? Or does it stop after a while?

Every time I pan, CPU usage stops when I stop dragging

Very strange... I made a PNG version to see if it was specifically WebP, but now both work fine

And now it's stuttering again with the PNG deleted

https://youtu.be/EzjWBmhO_1E

Here's bit stream and image header parsing in Zig: https://gist.github.com/jjrv/cb373bcbde3f5d6287977f5ad0c510f8 Not much verified or tested, but a bit of comptime made it nice to write. Super easy to pretty-print resulting structs as JSON. Bit stream avoids unaligned access, I got the impression it might be a bad idea on wasm. Super unsafe, reads past the input buffer at both ends. Targeting wasm, I just don't care. Less checks in code means less to download and execute. getVar64 should be the only function in BitReader with branches executed at run-time, the rest are comptime. I do have a wasm-build of a recent libjxl but it's about a megabyte-sized .wasm, hoping for smaller.

Would it be useful to produce an annotated view of header contents and corresponding bits (for investigating some jxl file)? Trying to get some early benefit out of this in case continuing doesn't end up making enough sense. Close wasm integration might have the benefit of less work getting debug output out of it visualized.

A spec is available in https://discord.com/channels/794206087879852103/1021189485960114198

Zig syntax seems kinda nice and clean...

And the the static comptime stuff seems pretty nice too...

I'm kinda skeptical, there has to be something terribly wrong with it because there's always a catch of some kind

Nice things aren't allowed to exist after all

😂

I mean, you drag a file to a box in a web app, and it shows the bits in the file, which bits correspond to which things and what they mean. Might be helpful for the next hapless soul who decides to write a decoder or encoder.

Haven't found a catch yet, except that the Zig spec is in flux so half a year old code always needs some changes to compile on latest nightly 😅

Oh, I thought you wanted to code that yourself

Looks like the code wouldn't become too much uglier, to support a comptime flag where it creates a structure in memory with info of which bit ranges ended up in which struct fields. And yes I was planning to code that. A kind of meta-JXL-viewer. For now, just for the headers, but if I end up writing a full decoder, then a meta-viewer can for example show which MA tree predictor was used for which pixel, and what intermediate images at different steps might look like.

That would seem to constantly produce useful visible results during development, instead of only at the end when it properly decodes an image completely, since I don't know if I'll get there.

I'm interested in a more complete understanding of the format, to figure out anything non-obvious relevant to bitmap and vector tiles for online maps. Currently polylines are usually compressed using variable length integer coordinates, delta to previous point, sign moved to LSB. But maybe more could be done, looking for inspiration.

If I can call zig libraries from C and generate/verify C headers that work with zig code then it might be a great language to write a codec with. And have a lot of LUTs generated at comp time

I like self-documenting/self-explanatory code

C is easier to call from Zig, than from C, believe it or not. Since you can just include a C header and use, but it gets imported in a struct of your choice instead of polluting the global namespace.

You can set C defines only that header can see, and I guess you can set their values based on any comptime computation. So the limited C preprocessor also gets replaced by Zig comptime.

Never tried to call the other way around, but StackOverflow says it can generate C headers during build https://stackoverflow.com/questions/77062533/how-to-make-the-zig-build-system-emit-a-c-header-along-with-a-generated-library

In C, you could evaluate code at comp time too. You just put a rule in a makefile for how to generate a header file containing data tables, for example.

You just write code in any language you want that can generate the data table and put it in a makefile rule

I don't really get the comptime thing in zig

it seems like there should me more to it than just "this is evaluated at compile time instead of runtime", because that's not really a unique thing?

in other languages, ordinary functions can also be comptime evaluated and have their logic replaced with the inlined result

optimizations are not semantics

during comptime in zig, types are available as values that can be passed around

what does that look like? it sounds somewhat more compelling that “erm, we have `constexpr` too”

At its most basic it looks like this: ``` fn max(comptime T: type, a: T, b: T) T { return if (a > b) a else b; } ```

you can also do stuff like use the built-in function `@typeInfo(T)` to get a list of the fields in a struct, and then use `inline for` to do stuff on each field (the loop is semantically unrolled at comptime, so of the different fields are different, that's fine, it's just like writing a visitor that goes to each field manually)

Or you can dynamically (at comptime) construct a type info struct and turn it into a type with `@type(T)`.

(you can write `anytype` as the argument or return type if you don't have a type parameter available to use like in the `max` example above)

ah so compile time code evaluation, generics (which look like they might be similar to rust's monomorphization) and metaprogrmming are all handled with `comptime`

that's pretty neat

Also, while all code has to be syntactically correct, dead code elimination happens *before* checking whether the code makes semantic sense. So you can do `if (@hasField(@typeOf(foo), "bar") { foo.bar }` and it won't complain about the case where foo doesn't have such a field.

downside is if you do anything non-trivial it easily becomes spaghetti, and unlike interfaces or traits, you can't just look at a function signature and know what it needs. Like there's stuff in the Zig standard library that takes a `writer`, but that's just ducktyped with `anytype`.

This also makes it a lot harder for library authors to ensure that they don't accidentally break backwards compat.

And if you write generic code, unless you write a lot of error handling boilerplate to give the user nice errors when they use an improper type, all the errors will be terrible and useless.

I see

i feel like trying Zig properly some day, but its approach to memory safety doesn't appeal to me

if I primarily wrote C id probably be very interested, but it doesn't look like i have much to gain coming from Rust, and it gives up memory and thread safety

what approach to memory safety? lol

lol, for a language where comptime is a selling point, it's pretty funny how its memory safety is runtime checks instead of compile time proofs

Maybe someone can test on their device, but both my Samsung S23 and S24 produce invalid PNG screenshots that cannot be converted using libjxl

exiftool `Warning : [minor] Trailer data after PNG IEND chunk`

~~time to overhaul png loading in cjxl totally~~

A much older Samsung using LineageOS outputs valid PNGs

Can you zip and send one?

here

This is from the S23

They're storing metadata as raw text after the `IEND` chunk``` Samsung_Capture_InfoScreenshot Captured_App_Info SEFT```

lmao

ExifTool seems to read it correctly > Warning : [minor] Trailer data after PNG IEND chunk > Samsung Capture Info : Screenshot

I wonder why they handle it that way, since the phone itself doesn't even display this metadata, none of the stock apps do

It would be a trivial one liner patch in cjxl to not have a mental breakdown when it encounters a trailer

And just print a warning instead

Could even store the trailing data as a “tail” box or something

Or just discard it

shouldn't discard by default. unexpected data loss is worse than unexpected encoding failure.

Agreed

Not arbitrary data, but I wanted to use XMP tags to store unsupported PNG text chunks <https://github.com/libjxl/libjxl/issues/2641#issuecomment-2268101325>

Then either end software can check for the same tag names, or djxl could write the chunks back even if it's not the same order, ect

It should preserve it in a metadata box or, failing that, cjxl should just print a warning and exit with a non zero status after ignoring the tail data and transcoding the damn PNG

:)

There should be a standardised “unknown” metadata box

Like to store the tEXt from png

What about garbage/junk metadata from aCropalypse?

well if it's a format with a dedicated end chunk or marker then aCropalypse can be ignored because none of it is even valid data (valid in the sense of following said format's spec and being considered an actual legit part of the image)

That makes sense

Why would tEXt be stored in an unknown box and not some standardized exif or XML "comment" tag

Hence my comment. Invalid data should be invalid and the cause resolved. tEXt chunks are valid but ignored unless already EXIF or XMP currently

I’m don’t know much about png metadata

if ur coming from rust, idk why you'd try zig

oops sorry necro

magick's hashing probably doesn't apply things like metadata or icc does it [Hmm](https://cdn.discordapp.com/emojis/1113499891314991275.webp?size=48&name=Hmm)

No it does not handle metadata

is my pseudo-quadraphonic setup overkill?

(the headtracker hasn’t arrived yet but I’m not sure whether it will improve the experience)

never :D

i have no clue what i'm looking at (i guess some sort of tool top optimize audio coming from speakers for your head position?) but it looks very interesting

i run my mic through reaper are you saying I should also be running my desktop audio through it

first plugin takes the quad audio track and turns it into 3rd-order Ambisonics; the plugin in the screenshot visualises the resulting Ambisonics signal and where the sound come from (but since it’s just from a quad recording, there is no elevation information), and then the last plugin renders the Ambisonics signal to binaural audio to be played on headphones

so in some sense, it effectively simulates quadraphonic sound on headphones

the headtracker I refer to is a device that tracks how the user (in this case, me) turns their head, which makes it possible to rotate the Ambisonics signal accordingly in real time before rendering it

that's really cool

does it only work with rotation or is there also a location aspect to it? i imagine a quad audio track isn't really enough to infer what it would sound like if you were like a meter to the left

i guess it would be enough if you knew the location of the four microphones and did some sort of trilateration but that sounds like it would be very computationally expensive and timing sensitive

indeed, a limitation of Ambisonics is that it just models spherical sound

so this approach wouldn’t even let me simulate “walking one metre to the left in an actual room with quad speakers”

makes sense, still really cool though 👀

I guess I’ll see how strongly I miss this once the tracker arrives

for now, I can turn my “virtual head” by clicking on knobs, but I mostly don’t bother 😂

just strap some joycons to your head <:galaxybrain:821831336372338729>

hm… https://www.digitaltrends.com/gaming/how-to-use-nintendo-switch-joy-cons-on-pc/#dt-heading-frequently-asked-questions

(for the sake of balance, I will point out that this person seems to have strong opinions against Ambisonics: https://www.reddit.com/r/SpatialAudio/comments/18s2adr/does_ambisonics_format_lower_sound_quality/ki433po/?context=2)

they seem to mostly have practicality issues with the approach that uses speakers though. using headphones, like you are, probably removes a lot of interference from external factors

at some point the answer is to just use speakers

also, if it works for you and you like it, that's all that matters 🙂

they do say: > dont even get me started on the stupidity of using ambisonics to decode to binaural.

I’d be curious to get them started

so true, you just need the four or eight audio outputs to satisfy the four or eight ears we have

maybe they mean when creating an ambisonics mix from scratch as opposed to e.g. capturing with an ambisonics microphone

this reminds me of those "surround sound" headphones that have multiple drivers per side

(I guess upmixing quad to ambisonics would still fall under that criticism then, but, eh)

oh, yeah, I’m not sure I ever really understood the point

but then I’ve never tried them, so who knows what I’m missing out on

i guess it's true that that the shape of our ear helps with distinguishing directions too, so maybe they play into that

apparently, they’ve stopped using multiple drivers in recent times?

> Surround Sound headphones are a gimmick. The early ones actually tried to shove a full 7.1 speaker system in, that failed because they had to use tiny little speakers - thereby wrecking the audio quality. The modern ones are a gimmick because at core they're using the same positional audio trick as any other stereo headset. > > I've owned a set of both. One of the best of the original multi-speaker cans, and a more recent "7.1" "surround" headset. They both delivered worse audio and less immersion than high-quality modern Stereo headsets.

------ > In the past there were multi-driver headphones. Didn't really work out. > Now the majority have 1 driver. (what is okay, considering the improvements.)

ah I see, that makes sense

spatial audio also works with those head/ear-shaped microphones. then you only need two channels to capture what sounds like basically exactly what you would have heard if you were there, if you listen to it with headphones (or earbuds work even better, i imagine)

they are many youtube videos that were made this way, it's pretty cool

My card doesn’t charge international transaction fees it seems, so adding DeepSeek tokens using CNY & WeChat Pay saves me 6 cents.

Reminded me of this https://github.com/google/tabuli

yeah, it’s quite neat – the main potential drawback is the fact that the listener’s orientation is effectively hardcoded in the recording

(which can be fine depending on the purpose)

it’s not a _pure_ coincidence 😁

e.g. I wrote large parts of this https://github.com/google/tabuli/blob/main/speaker_experiments/angular.cc

it uses a similar idea as https://github.com/sboukortt/intersect-lv2

https://github.com/google/tabuli/blob/main/speaker_experiments/two_to_three.cc was a more direct “port”

ahh yeah that's a good point

3d sound studio my beloved

https://gitlab.gnome.org/GNOME/gnome-backgrounds/-/commit/85c63cb0c231570ad2017c3b75b58fe79bad6792

Unfortunate

weird, i thought decoding performance was about the same for both formats...

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6886#note_2360630

maybe it can be and libjxl just hasn't had the same optimization efforts as common jpeg decoders

The comment that lead to this commit talks about 17 seconds of stalling before the desktop loads

Which indeed does sound weirdly long

``` 2015 X1 Carbon gen3 i7 with 8gb ram. Not super old, but not super young either. Has a 600mb/sec SATA SSD. Samples for login land roughly 60% in gnome-shell, of which about 85% of that is in JXL decoding, presumably for our new file format for backgrounds. I'm a less concerned that it's 85% and more concerned that it's about a 17 second stall on login. ```

Certainly an interesting thread

...is it a blocking task?

yes it is https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2205

this doesn't excuse the long decode time, but those should definitely be asynchronous

Well, easier for them to just switch back to JPEG

Sad, but it is what it is

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6886#note_1812522

The benchmark in this comment using gdk-pixbuf.-thumbnailer also doesn't give a favourable result

In fact, it is pretty much downright unusable, compared to JPEG

I had wanted to try switching KDE's thumbnailing to WebP and JXL to compare loading times, but haven't gotten around to setting up an environment

it's a bit suspicious to me, might be something off in the gdk-pixbuf integration code

Seems like a reasonable assumption

According to yourself, there was but it was fixed <https://github.com/libjxl/libjxl/pull/2942>

Maybe something broke again?

Though, I don't think the OP ever actually said it was fixed, only said it was still slow a few days ago, so it could be a hardware quirk

I have no old CPU to test with, but with my current setup get these results ``` $ /usr/bin/time -f "%E seconds" gdk-pixbuf-thumbnailer -s 1440 adwaita-l.jxl foo.png 0:00.77 seconds $ /usr/bin/time -f "%E seconds" gdk-pixbuf-thumbnailer -s 2160 adwaita-l.jxl foo.png 0:01.66 seconds ```

Which is still slower than the JPG decode in [this comment](https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6886#note_1812522)

what format are the wallpapers in? Lossy or lossless?

If they're high effort lossless that could explain it

I was wondering, did they ever test JXLs recompressed from JPEG?

worst case perf scenario, they'd just end up picking using those files, and still get some compression benefit over just regular JPEG

right, but not *too much* slower

Are they maybe compiling libjxl without any simd or something like that?

especially if they have noise generation, I could buy it being slower

(they don't)

Lossy

ok, on my pc adwaita-l.jxl takes ~150ms to decode

I wonder if the thumbnailer uses multithreading

it's still not *too* slow even in that case (~250ms), but still

what does `time ~/libjxl/build/tools/djxl -v --disable_output adwaita-l.jxl --num_reps 10 --num_threads 0` tell you?

adwaita-l.jxl has noise, I remember optimizing jxl-oxide for that image

Latest stable version of libjxl ``` $ time djxl -v --disable_output adwaita-l.jxl --num_reps 10 --num_threads 0 JPEG XL decoder v0.11.1 794a5dcf [AVX2,SSE4,SSE2] Read 757379 compressed bytes. Decoded to pixels. 4096 x 4096, geomean: 56.299 MP/s [55.39, 56.76], , 10 reps, 0 threads. real 0m2,997s user 0m2,707s sys 0m0,265s ```

So 300ms

That seems to point at the gdk pixbuf loader being slower than djxl

Can you try the thumbnailer with jpeg?

It's not a direct comparison since both images looks slightly different, but running `/usr/bin/time -f "%E seconds" gdk-pixbuf-thumbnailer -s 2160 adwaita-l.jpg foo.png` 10 times always took around 0:01.84 seconds ± 2 milliseconds

isn't that pretty much the same as the jxl file?

(indicating most of the time goes, well, not in the reader)

Here are the cjxl settings they've used, pretty standard stuff https://gitlab.gnome.org/Teams/Design/wallpaper-assets/-/blob/master/48/00-tojxl.sh?ref_type=heads ``` cjxl --photon_noise_iso=800 -p -q 85 $1-l.png $1-l.jxl cjxl --photon_noise_iso=800 -p -q 85 $1-d.png $1-d.jxl ````

Not the exact image, but I want to render the original image to get a better base for comparing

Yes, slightly longer even

maybe they're on some ancient libjxl

They are on 10.3

https://packages.ubuntu.com/search?keywords=libjxl&searchon=names&suite=oracular&section=all

https://packages.ubuntu.com/oracular/libjxl-tools

maybe there is low available memory and they end up using swap space or something?

I don't think so, this problem was reproduced by multiple people in the issue

libpixbufloader-jxl.so, which the thumbnailer seems to use for JXL is on libjxl version 0.11, but I cannot speak for Ubuntu/GNOME OS

guess I should try that out at some point in the future

I am installing Ubuntu 24 lts and GNOME OS in VMs currently to test further

If it helps, they could remove the noise and use 0.11's dithered output instead

Does progressive actually do anything in this scenario? I'm fairly sure they're not doing progressive loading during startup, ignoring the fact progressive isn't actually progressive since 0.10's chunked encoding

the problem was reproduced by multiple people *before* my patch

so far it's only one person

Then maybe a person here with older hardware may be able to test, my hardware is far too new. I will still test of course, but it's not the same

you can try compiling it without simd, which is probably the key here

there's a cmake option to set highway to scalar only

so nothing will be vectorized

At least it doesn's seem to be a general issue with GNOME OS, the results are almost identical to my earlier runs on bare metal

boot times were also normal, nothing out of the ordinary

gdk-pixbuf-thumbnailer is slower than djxl, around a factor of 4

At least on my hardware and in this VM

gdk-pixbuf uses libjxl 0.10 in GNOME OS

This background image that I've tested on loads in around a second in the VM

Takes less than 100ms on baremetal in KDE Plasma

Loads in under 2 seconds on my 8 year old Android. So something is very wrong if they're getting more than that

It also takes around one second using GNOMEs image viewer, loupe, on bare metal

So it's not an issue of only GNOME OS, but GNOME's implementation is slow for some reason

It seems to affect other GNOME applications as well

System time is around the same as djxl, right? So maybe it's something other than the decoding itself

djxl decode takes around 0.3 seconds on bare metal, so roughly three times faster than loupe

loupe uses glycin, which sandboxes decoders in separate process and communicates with those using unix socket. maybe that's the reason

and... glycin jxl loader doesn't seem to use parallel runner?

The results above are all singlethreaded, djxl is still 4x faster

that likely doesn't help

...and bwrap and seccomp filters and setrlimit. anyway that slowdown on single thread is very suspicious, maybe glue code is slow?

I swapped the wallpaper between JXL and JPEG to see if it any impact on boot time, but no. Maybe my hardware really is just too new for it to have a significant impact ``` --- JXL Wallpaper graphical.target reached after 4.694s in userspace. graphical.target reached after 3.860s in userspace. graphical.target reached after 3.777s in userspace. graphical.target reached after 3.675s in userspace. graphical.target reached after 3.783s in userspace. graphical.target reached after 3.850s in userspace. --- JPEG Wallpaper graphical.target reached after 3.900s in userspace. graphical.target reached after 3.816s in userspace. graphical.target reached after 3.718s in userspace. graphical.target reached after 3.858s in userspace. graphical.target reached after 3.774s in userspace. graphical.target reached after 3.762s in userspace. ```

This is the way... If only dynamic linking was a thing of the past

Dynamic linking is so ugly and fragile by comparison, and gives the library too much access...

Wouldn't you just boot to a black desktop if it took a long time to decode?

No, because they apparently haven't implemented asynchronous decode for the wallpaper, so the login doesn't finish until the decode has finished

Who hasn't? On X11 the wallpaper is usually drawn by its own dedicated process

And x11 is not known for being well made

its likely an issue with how they have services setup

I don't know if KDE/GNOME use a separate process or not

Those have an even worse reputation than x11 itself

yeah they do use separate processes

well KDE at least, gnome I dunno

Without dynamic linking, it would take ages before new libjxl versions percolate to applications. Sure it's messy and complicated, but besides avoiding a bunch of duplication of compiled code, it does have advantages. Plus it doesn't hurt to have another incentive to keep the API stable...

I mean in general, if libraries were replaced by a multiprocess server/daemon system instead.

That would be a better design, like in plan9

A better convention for operating systems beyond the usual Linux-style stagnation

dynamically linked libraries having updates pushed out and then used by already installed applications is basically only a thing on Linux, and Linux distros could just as easily recompile applications when libraries are updated, rather than rely on dynamic linking. Which they actually have to do with lots of C++ libraries due to the use of templates. And ofc fpr the 95% of users who are on Windows and macOS, application updates are needed anyway. And the most widely used Linux distros try to be "stable", and thus don't update libraries anyway.

example: Arch Linux rebuilding a bunch of stuff for flac 1.5 https://archlinux.org/todo/flac-150/

well I think it's not a great idea to ship statically linked copies of image codecs like libjxl with all possible applications that may want to encode/decode images... not just because it duplicates a few megabytes of binary size, but mostly because it means that many applications are not going to bother to push an update for every new libjxl version, so bugfixes and improvements will end up taking longer to get deployed than they already do...

I don't see why applications would be more likely to push updates with new libjxl versions just because it's dynamically linked. Dynamic library updates are always bundled with updates to the application as a whole, so there's always a rebuild of the application anyway.

Well not in Linux distros, or e.g. in things like Homebrew afaik

Of course if you're going to ship a copy of the library with the application anyway, then you can just as well (or better) link statically

but applications don't push updates on Linux, the distro maintainers choose what to do. i don't really care about static vs dynamic linking but I think this argument is kinda weak.

and distros like debian and red hat don't ship major library updates much anyway, just bug fix backports

It makes life a lot easier for a distro (and saves a lot of storage/bandwidth) if minor/patch version updates and bugfixes can be done just by updating the library itself instead of having to upgrade anything that depends on it too.

> Quad binaural is an alternative system [in which] four binaural stereo images are used, corresponding to different head orientations (front, left, back and right). These are mixed together live depending on where the user is looking. This system only supports one axis of rotation, unlike ambisonics which supports all three.

fun

I wonder how well it works in practice

if I look 45° to the side, does mixing 0° and 90° binaural recordings together really work?

I also wonder how many implementations of this actually exist

ah, Samsung uses it, apparently

> As the viewer turns within the “space” of the video, the Gear VR crossfades between the binaural streams. You never hear more than two files in the output. If you’re careful with how you construct and monitor your mixes, you can do this with little to no noticeable phase issues as the boundaries are crossed.

On Windows and Mac and other non Linux platforms each app vendor ships their own redundant copies of the dynamic linked object files.

They never get updated until the app vendor decides to update and the app vendor decides what version to use, not the OS vendor. That is just static linking with extra steps!

Dynamic linking is a cool technology and is useful but the way it's usually used is not appropriate

And it's a lot more dangerous than a server daemon model

+ lgpl compliance i think

If you want to share and re-use code as a common shared service then it makes more sense to communicate with a separate process than to link it into the same process, where it can hijack control away from the programmer (take a long time to hand control back to the caller, or just never give control back and hang or abort())

I think there are cases where it makes sense to link (either statically or dynamically) and a lot of cases where it makes more sense to have it in a separate process space.

And it's not often considered when to use which

lgpl is a clown license honestly

MPL achieves a similar goal more elegantly and permissively

But licenses and copyright in general is clownish overall so eh

Patents are kind of interesting because they encourage people to publish and explain their inventions but they also operate in a pretty clownish way

yeah, head tracking works but I’m not sure it feels that mindblowing

and the zero point drifts a lot

yes and no, because if you ship dynamic libraries you can use dlopen() or equivalent to load plugins on the fly

but yes I agree that this is kinda silly

every GTK app for windows ships a copy of GTK

for ex.

VST plugins are a prime example of that (and as you might have guessed, came to my mind from recent experience)

not sure what VST plugins are

but I know that a few things use these strats to load plugins on the fly without taking too much ram

for ex. gdk-pixbuf uses dlopen on libpixbufloader-jxl.so only if a JXL file is found, iirc

they’re audio processing plugins that are typically loaded in DAWs or video editors

for example, one could buy this audio denoiser from Waves https://www.waves.com/plugins/clarity-vx-pro

and then use it in Audacity or whatever

(it’s not in the list because I have not bought that plugin)

https://www.productionmusiclive.com/blogs/news/top-30-best-vst-audio-plugins-in-2022-for-music-production

LV2 (https://lv2plug.in/) is an API with a similar purpose, and somewhat more popular than VST on Linux due to its licencing

(but both VST and LV2 exist on Linux and elsewhere)

ffmpeg has a filter to apply an LV2 or LADSPA (LV2’s predecessor) plugin https://ffmpeg.org/ffmpeg-filters.html#lv2 https://ffmpeg.org/ffmpeg-filters.html#ladspa

ah that's what that is for

nice

And EUPL does an even better job, giving you the best of the MLP, the LGPL, and the AGPL.

Sometimes it's better to use IPC than to link objects

Often linking is not what you actually want, it's just used by convention even when it's better served by another method

speaking of OpenStreetMap, a while ago I tried transcoding the PNGs they serve to lossless JXL, and to my surprise they barely got any smaller. I guess they spend a lot on compression to save on bandwidth

oh damn, you could probably use splines really well for that. and you wouldn't even need to use spline heuristics in an encoder, you could just directly convert line-like features from the OpenStreetMap data to splines

I do like how the quality 1 JPEG has like, idk 16 colors total, and is 200 KB, while the quality 1 WebP looks fairly reasonable and is like half the size <:KekDog:805390049033191445>

pretty sure this is is how the ICC Varints work?

annex E specifies the following

I think so yeah, but i just forwarded that message because openstreetmap was mentioned. what you said was brought up in the discussion surrounding it, you can go there if you click the redirect at the bottom of the forwarded segment 🙂

ah okay

I thought they use svg

Compression of Spectral Images using Spectral JPEG XL Authors: Alban Fichet Christoph Peters Intel Corporation Editor: Brent Burley Walt Disney Animation Studios Editor-in-Chief: Eric Haines NVIDIA Abstract The advantages of spectral rendering are increasingly well known, and corresponding rendering algorithms have matured. In this context, spectral images are used as input (e.g., reflectance and emission textures) and output of a renderer. Their large memory footprint is one of the big remaining issues with spectral rendering. Our method applies a cosine transform in the wavelength domain. We then reduce the dynamic range of higher-frequency Fourier coefficients by dividing them by the mean brightness, i.e., the Fourier coefficient for frequency zero. Then we store all coefficient images using JPEG XL. The mean brightness is perceptually most important and we store it with high quality. At higher frequencies, we use higher compression ratios and optionally lower resolutions. Our format supports the full feature set of spectral OpenEXR, but compared to this lossless compression, we achieve file sizes that are 10 to 60 times smaller than their ZIP compressed counterparts. https://jcgt.org/published/0014/01/04/

Discussion in https://discord.com/channels/794206087879852103/822105409312653333/1346799113840103455

Does anyone know of a relatively recent resampling method, called HQIP or something similar, made default in an image processing tool with the description 'a paper will be published on it soon'. I've tried to find it a few times but it seems to have vanished, it quoted better quality and speed than any other method. It's a long shot, but if anyone would know they'd be in here

I'm also wondering how the downsampling used in libjxl compares to other methods. I know the paper Jon made recently shows a few examples, but it seems like the best of any method and should implemented elsewhere too

I considered if jpegli should just resamle the image at low quality too, but obviously different dimensions could be a big issue for some applications... Not that they should go that low anyway

on decode, it just uses the pixel data that's given in multiple passes. do you mean on encode?

Yeah

https://www.reddit.com/r/zerotomasteryio/comments/1j5rrsr/a_student_just_disproved_a_40yearold_hash_table/mgkhz61/

ohey I know Bill Kuszmaul

I went to summer camp with him

https://arxiv.org/abs/2501.02305

it's a small world 🙂

there is a method of text topic classification that works by compressing the text and comparing the similarity of the Huffman data to some target. the method turned out to be faster than and about as accurate as using word embeddings. now i'm wondering if you could create some sort of whole-image classification thing that uses just the MA trees for 1024x1024 images (one whole group)

I think it might work. many similar scenes will have similar MA trees, but you might even be able to tell the difference between a pine forest and broadleaf forest because pine trees are easier to predict with NE and NW, and as such that predictor usage would give it away

tomorrow after work I'll see if I can use Jon's code to encode visually similar images to see if they create similar MA trees

If it works I doubt it'd be useful at all in practice, because encoding an image losslessly at a high effort setting is probably less resource efficient than using other image classification methods haha

The AVIF displayed by the browsers on the left looks awesome /s

I miss the ocean image with the filesize 😔

Looks like it's just very noticable on my desktop (on both very different screens showing pretty much the same) that is running X11 and using a 3700X & a RX 560 (less shader variant).

_petition to add it back_

https://web.archive.org/web/20230417171231im_/https://jpeg.org/images/jpegxl-home.jpg

anyone has a good corpus with JPG images for benchmarking compression?

A tag added with filetype:jpg order:score ||https://danbooru.donmai.us||

Why JPG images? Wouldn't you want lossless for that?

if you acquired digital versions of mangas its a thouroughly diverse source (humble sometimes offers 20+ volumes for multiple series for barely 20$ in its ebook bundles)

also handy since many online readers recompress and rehost those so you get a reference for both originals and lousy recompresses to bench against

reversible jpg transcoding is lightning fast for this kind of content (consistent sub 40 milliseconds - effort 7 an excellent default but even 3 still guarantees smaller filesizes converted at even shorter durations)

Wouldn't you ideally still want to compare against the original in that case? So it's probably better to create the intermediate JPEGs yourself

scanlators releasing using pngs are a different source of truth

as for official originals, itd have to be either raws or the png originals in japanese (few paid japanese services offer that even for their own apps)

for benchmarking optimizers once again

ah

I tested all of these (order: first = smallest output): - JpegUltraScan.pl - `ect` - MozJPEG's `jpegtran` - IJG's `jpegtran` - libjpeg-turbo's `jpegtran`, leanify, pingo, jpegoptim, curtail, jpgcrush, jhead (but they were useless compare to those above)

but I would need a quite big corpus with a lot of variety to be sure it is like that

pingo was useless compared to ect?

pingo should perform about the same, if not better

mmmmh then I need to test on more files indeed but my point was: I found nothing better than a mix of ect, jpegtran and JpegUltraScan.pl

oh I remember why I said pingo was useless: > Looking at pingo's result, it looks like it either replicates or directly copies what ECT is doing, in addition to stripping the 18-byte JPEG header: I don't like that at all, since it decreases support https://encode.su/threads/3987-Jpeg-Optimizer-testing?p=77383&viewfull=1#post77383

I've never seen a situation where stripping the JPEG header mattered

perhaps, but I guess it is an invalid JPG file without that header

(?)

All programs/websites I have used new and old process it just fine.

And if it works, then I find pingo to be better than ect

Is JPEG Ultra scan just brute force ?

What does Caesium Image Compressor use for optimising JPEG?

yes, it's very slow

and the savings are perhaps not so important compared to the exec time but hey, who doesn't want 0.1% save? <:KekDog:805390049033191445>

I often get better savings though <:KittyThink:1126564678835904553>

And also use up to -b 3 since more never resulted in a smaller file for me

I remember `jhead` saving 6 bytes over jpegultrascan once but that was bc it used arithmetic encoding

proof [⠀](https://cdn.discordapp.com/emojis/659513552033415188.webp?size=48&name=av1_pepegun)

Not home XD

I never thought I would win so easily https://cdn.discordapp.com/emojis/1126563616343216268.webp?size=48

Won't even be home for 10 more days <:KekDog:884736660376535040>

well, I just remember this: https://github.com/MegaByte/jpegultrascan/issues/9 but uncommon iirc and well... it's 4 bytes <:KekDog:805390049033191445>

Could it be that GIMP and krita do not display zero duration multi-frame JXL?

That's layers, isn't it?

<@693503208726986763> have you ever thought about adding .ogg support to your project [RHEFO](https://github.com/T-3B/rhefo) by making use of [OptiVorbis](https://github.com/OptiVorbis/OptiVorbis)?

wtf why did only the first URL embed

test: [OptiVorbis](https://github.com/OptiVorbis/OptiVorbis)

Yes of course! It is planned, but as you can see in the sh script there are dozens and dozens of TODOs <:KekDog:805390049033191445>

I really want to "finish" asap a first version so I can make a release with embedded optimizers

and that first version should have all the already supported format completely done, so it takes time (as well as benchmarking/bruteforcing numerous of optimizers)

And once I release it I'll share it on encode.su too

The current Gimp plugin (the one in the libjxl repository and the independent one in Gimp's source) always coalesces zero-length frames, so the layers that appear in Gimp when opening a JXL file are always blended animation frames. See https://github.com/libjxl/libjxl/discussions/3900 and the discussion in https://github.com/libjxl/libjxl/pull/1863 .

Krita does either animation or layers, but not animated layers

<https://www.nasa.gov/blogs/missions/2025/03/14/nasa-science-data-received-blue-ghost-captures-eclipse-from-moon/> If only it was a JXL

https://www.nasa.gov/wp-content/uploads/2025/03/eclipse-shot-from-blue-ghost-mission-1.jpg

Hm... a bit unfortunate but well. I guess it will still take a bit until I can replace ora for layered screenshots with jxl. (Krita shows OpenRaster very well btw.) ~~(I set it to frame duration of 1 ms for the jxl for now. Ignore the small weird things like mergedimage not properly generated in this ora or Floorp positioned a bit too far right in the jxl)~~

(Also reason on why to replace ora: I doubt tesseract will ever support it & jxl inside ora has zero support as of now anyways)

This might interest you https://bugs.kde.org/show_bug.cgi?id=500877#c4

Yeah, thing is just that ideally it should be a jxl since that has a good chance to be supported by the library used by tesseract and I want to be able to use that to quickly find images with certain content. Imagine being able to filter for files containing specific windows (window names in files) & then further narrowing it down by looking for e.g. some text that was displayed in a certain application. ~~(Ideally everything regarding windows should be vector based cause I want vector screenshots to work outside of GTK3 windows and I just want to be able to grep for text from any window... but that's faaar away)~~

Do you still have the 0 duration JXL?

screenshot2.jxl has duration: 0.0 ms displayed by `jxlinfo` screenshot.jxl has no duration displayed. Not sure if those files are actually conforming...

screenshot.jxl opens perfectly fine as a layered image in Krita, though the layers weren't named (Which is possible in JXL)

Yeah, just noticed this as well

Did not try it earlier cause for the others there were issues

But funnily GIMP does have issues with this one and only shows the top layer

Also same for Floorp

tried gimp with a processing test no idea if I did something wrong but had very clear 8bit processing artifacts when I applieda gaussian blur to a red star on a cyan background

-_-

will we ever get a foss photo editor that can handle jxl native that doesnt suck <:PepeHands:808829977608323112>