JPEG XL

I disagree that gecko's existence is not beneficial, sepecially compared to the hegemony of blink

firefox's entire benefit comes from not being chrome and preventing the chrome monopoly, which they have shown again and again to fail at doing. in fact, I would go so far as to say I think it would be beneficial for firefox to diem that way peoples funding and developmental resources can go to projects that are actually largely useful like webkit and servo

I don't see how Webkit, which Blink was forked from and therefore has so much homogenity, is more useful than Firefox.

because I dont see how firefox is useful at all, at least withh webkit you can use it as a base to develop a browser around, vs firefox which simply exists on the merit of it being "not chrome"

yes

all ios browsers have to use the os-provided webview

so they all get jxl support once the os gets it

I think recently that restriction was lifted or is going to be lifted however no browser engines have had a iOS port as of yet

I'm using ff, and can not really switch to any sort of chrome because of two reasons: I can't live without hundreds of tabs (and do not want to see how chrome eats all memory), and the stupidiest impossibility to make chrome to switch tabs in recent order. While my knowledge about chrome, tabs and memory relationships can be outdated (I know about edge's sleeping tabs, etc), it's tab switching is just a stopper for me

chrome and ff use a similar amount of memory

aka any memory available

I have over 8000 tabs open and Firefox is apparently using 8 GiB of RAM ||and 14 GiB of swap but let's ignroe that||

2 tabs 900mb

If you type % at the start in the URL box, everything after is used to search your open tabs. Also the tabs are organized into like 50 windows.

chrome doesn't do any worse then Firefox for memory usage, in fact it handles low ram situations better then Firefox, and had for a very long time. while it's true Chrome can use more memory than Firefox. It has always been more efficient with how the memory is used cant say I share the same with tabs since I use an external tab manager anyways, but in the end that's a small feature, that's not really a big deal like gecko versus blink. and just something that could be implemented in another browser with not a large amount of difficulty.

but chrome handles hundreds of tabs just fine, and has for a long time.

mfw this mf has a cache of the entire internet in RAM

I run Firefox with on-disk cache disabled (only RAM), and have thousands of tabs... but they are split across tab groups with https://addons.mozilla.org/en-US/firefox/addon/simple-tab-groups/ , and I configured it to only keep the shown group's tabs loaded in RAM, and even you can suspend unused tabs automatically with another extension on top

that's how Firefox is pretty consistently using under 2 GB of RAM for me at all times

Chrome is barely starting to try to play catch up in that efficiency game

> but in the end that's a small feature, that's not really a big deal like gecko versus blink. and just something that could be implemented in another browser with not a large amount of difficulty. It is a big deal for me, and if you know how to overcome it (tab manager, or whatever) - please share

the goal is not to use less ram, it's to use as much ram as efficiently possible, if you run 300tabs with chrome and check ram usage, you will find you have little `free` ram, but you should still have plenty `available` ram even if you have a lot of heave duty websites, chrome will still unload them when needed.

it's not something I myself have bothered to look into so I can't say for certain but ill keep an eye out

ofc if you do need more aggressive page sleeping, or even unloading, you can tweak that with an extension too, but chrome's default behavior for this is a lot better when under memory pressure

The main show stopper for me is tab switching, really, if it could be solved - I'd be happy to give chrome second chance

Trying to integrate jpegli with my image viewer (over libjpeg-turbo) has been a pretty painful experience

Now it's a crash during startup and I can't figure out why

Oh it created a dependency on a dll for no reason, amazing

actually not sure if jpegli did that

this cmakelists is all over the place

back to this issue

I raise you https://idlewords.com/talks/website_obesity.htm (<@184373105588699137>)

good luck getting any website to fit in a megabyte of RAM or something, most eat 40-50 MB at the very least it seems (and this Matrix Element tab is using something like 300-500 MB if I'm not mistaken)... also given that my eyeballs can't look at more than a few dozen websites concurrently, it makes total sense in my view to auto-suspend idle ones that don't have an interactive (forms/video/sound/unsaved changes) aspect to them

yes, both chrome and firefox suspend idle tabs, chrome is a bit more conservative in doing so when you have lots of ram free (also uses some available ram for it), but is a lot more agressive when you don't have a lot of ram

if you enable memory saver in chrome settings, it does it a lot more aggressively, this can pose a problem when working with a lot of tabs at the same time period

but again, I dont see the point in not using ram that is free and available,

not getting the stupid kernel OoM killer to randomly kill your other apps like the file manager, email client, or graphics editor when trying to do work

also those tabs sitting around active tend to wake up the CPU constantly -\> more heat, less battery life (if on battery), etc.

see, i don't get why the oom killer doesn't just halt programs until there's more memory or smth

firefox will typically cause an OOM situation before chrome will, this is something I have tested extensively across distros and operating systems (including android). as I have said, chrome is typically a good chunk better then firefox when under memory pressure situations

I will re-iterate what I did before, chrome is more efficient on average with how it uses ram, chrome has a higher ram usage ceiling but it also has a lower floor

a lot of my testing was preformed on a 2 and 4gb i3 2100 system and a 2gb asus t100ta, I had tested windows, various linux distros, as well as blissOS

granted I didnt test any BSDs so it could be different there

you have to kill them to actually free the memory, that being said, oomkiller is kinda really stupid, and sometimes instead of killing the head process, it will just go all the way up the tree and kill the compositor

Why?

because simply stopping a program, all the memory will remain, if you forcibly take the memory it's using, it will segfault anyways

keep in mind an OOM should only happen when you have no availible ram, though OOM can also be triggered when swap is getting hammered really hard, this is mainly a relic from when swap was stored on HDDs can thrashing could occur

sure sure but technically speaking stopping the program means it won't allocate additional memory

well not allocating more memory helps sure, but it doesn't make the situation actively better, it only prevents it from getting worse

right, so use an emergency swap to ask the user what to do :p

I suppose that could be possible

in the end, oom handling on linux is particularly stupid for some reason

why are you guys running out of ram

don't open 500 tabs that you will never look at again

Just buy more RAM

is JPEG XL an audio compression algorithm?

yes

Rather remove JS from the web. Thousand tabs worked well on lower end devices ten years ago.

very crunchy

reconstructed audio:

sounds way better then what I was doing xD

`>ffmpeg -i https://cdn.discordapp.com/attachments/794206170445119489/1132948126282547200/image_d01.jxl -f rawvideo - | ffmpeg -y -f u8 -ac 1 -r 48000 -i - -f wav - | mpv -`

i converted from JXL to PNG before rendering because my FFmpeg's JXL support is broken ``` djxl image_d01.jxl image_d01.png ffmpeg -i image_d01.png -f rawvideo -pix_fmt gray - | ffmpeg -f u8 -ac 1 -ar 48000 -i - image_d01.flac ```

probably colour space shenanigans

how is it "broken"

what happens when you try it

Unknown decoder or something can’t remember

sounds like it's not broken, but just not compiled in

ffmpeg needs to be compiled with `--enable-libjxl`

I installed using homebrew I can’t change the install parameters

homebrew doesn't let you do that, even though it builds stuff itself?

interesting

I’ll check tomorrow it’s 9pm my time

What was the input command from flac to jxl (Or PNG)? Trying to do a test myself but it's either just noise or floods with errors

flac ? the audio format ?

Yeah, if you read the messages above

How much does Pale Moon have? 🤔

Palemoon itself is about 85+ thousand lines of code AFAICT (from some old data), like Epiphany, which does not count the engine itself which is... I don't know how many lines of code

It's not even clear which part between https://repo.palemoon.org/MoonchildProductions/GRE and https://repo.palemoon.org/MoonchildProductions/UXP is the Goanna engine for Palemoon, OkyDooky

like is it both combined? does one include the other? I have no idea

ah OK seems like GRE is abandoned, and UXP is the thing

OkyDooky\: in the UXP codebase, `sloccount` sees 8.7 million lines of code, 60% of which C++ and 32% C. I wouldn't be surprised if at 8.7 million it was missing a good chunk still

So, it's likely noticeably smaller than current FF, but not *that* much smaller. Amazed they get so much done with the team they have.

I find it very difficult to believe such a web engine can be sustainably and securely maintained by a handful of people in their spare time

I also suspect it must be unbearably slow compared to modern Electrolysis+Servo+Stylo gecko with parts written in Rust

can `cjxl` not read JPEG XL files as input?

what command are you using? there are multiple ways to

I don't really remember but I think I was just trying to rewrite your JXL to FLAC command backwards, naturally it wasn't as simple as that so thought I'd jsut wait for a real answer

`ffmpeg -i [input] -f u8 -ac 1 -ar 48000 - | ffmpeg -f rawvideo -pix_fmt gray -s:v "[lengh of file in seconds]x48000" -i - [output].png`

try this ^

`ffmpeg -hide_banner -i input.flac -f u8 -ac 1 -ar (Sample Rate) - | ffmpeg -f rawvideo -pix_fmt gray -s:v (Seconds x 10)x(Sample Rate / 10) -i - -distance 0.3 -effort 8 -y output.jxl` I tweaked it slightly for direct JXL and more managable image resolution, but seems to work great, thanks

i also did the x10 /10 thing on mine it was just harder to type

Yeah, I used the JXL you uploaded to figure that out

It can, if you use a recent enough version

```% cjxl image1.jxl image2.jxl -d 1 JPEG XL encoder v0.8.2 0.8.2 [AVX2,SSE4,SSSE3] Getting pixel data failed.```

im trying to compress it

it is currently modular lossless

hm, weird, seems like the latest release only includes code until ~jan, with some feb commits backported

the commit adding jxl support is in main, but it's from may

should i try compiling from source?

also for my weird audio to JXL project would modular lossy work better than VarDCT lossy?

You can compile from source or use the Github Actions builds, here's the most recent one https://github.com/libjxl/libjxl/actions/runs/5654098785#artifacts

it's not really advisable to try to lossily encode non-perceptual data, you'll get the wrong data discarded

audio is perceptual

That's intentional, after a `_._` release the `_._._` versions only get security updates

When’s the next single dot release

it's not perceptual in the same way tho, just casting 16-bit PCM samples to 16-bit Grayscale image samples and then encoding is not a good idea

bro's just trying to have fun

what happened to `cjxl --strip`? it appears not to work anymore

``` --container=0|1 0 = Do not encode using container format (strip Exif/XMP/JPEG bitstream reconstruction data). 1 = Force using container format. Default: use only if needed.``` Does that sound like it? Because currently it doesn't actually remove original metadata, only reconstruction or forcing a container if I recall

tnere's a this bug in effect <https://github.com/libjxl/libjxl/issues/2645> exif and friends are always force-copied <https://github.com/libjxl/libjxl/blob/59d8f61cd7fc101c79148825c5d6dd14e73b9cd1/tools/cjxl_main.cc#L989> <https://github.com/libjxl/libjxl/blob/59d8f61cd7fc101c79148825c5d6dd14e73b9cd1/lib/extras/enc/jxl.cc#L73>

Is the container recommended or is it fine to leave out

I looked through my images and some are in the container and others aren’t

In the case you may want to recover an exact copy of an original JPEG file, keep it. Otherwise, if you know you'll never care about metadata, strip it. If you're sharing images, strip for better privacy or transfer efficiency.

Right now you can't disable the container, cjxl will simply never add one if there's no data to put inside it

working on improving things a bit in this regard

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

Can I use --container=0 to effectively cjxl --strip?

or does that strip the jbrd and prevent reconstruction?

I think it will currently only do that if you explicitly add --jpeg_store_metadata 0 too

if you strip JBRD is it possible to reconstruct the original jpeg, just non-bit-exactly?

since the quant weights and coeffs are in the codestream

Yes, in principle

All the actual image data is in the codestream, jbrd is only "the remaining stuff"

We haven't implemented a "default reconstruction" though, that would work without jbrd

I was tempted to mention PNG `iTXt`, `zTXt` and `tEXt` chunks. Currently cjxl will read XMP metadata from them, but they're also used to store raw text with a tag at the start such as `Description` or `Parameters`. If those could be turned into XMP or EXIF entries then at least the data is retained, even if not readable in the same way

I know at least one example of worldwide use, Stable Diffusion embeds the prompt and settings into every image like that And a more niche example is VRChat screenshots with a popular 'addon' called VRCX, where it embeds session data into the file so you know who was in the image

Thinking about it I should just make an issue

Jxl spec defines exif, xmp and jumbf. But we could also add other boxes, they are not described in the spec except that they are to be ignored. I am half-tempted to add a `text` box that just corresponds to unrecognized png text chunks

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

Two old issues were related, but one seemed to be assumed as XMP support and the other had a title that wasn't clear

just clarifying, if I convert a .jpg to a .jxl with JPEG bitstream reconstruction, then convert the .jxl back to .jpg, will the original and reconstructed be byte-for-byte identical?

as long as i don't strip metadata right

like i need to use the container

is the jpeg reconstruction in a metadata atom?

what other metadata is supported? is IPTC and TIFF metadata supported?

ICC goes in the jxl codestream, Exif and XMP go in the jxl file, everything else in terms of metadata goes in the `jbrd` box

What about converting from a PNG to a JXL?

Does the metadata just get voided?

cjxl tries to keep what it recognizes (exif and xmp)

The issue I linked above is about preserving all/most of PNG metadata regardless of type

Thought I'd get some input from others here on the formatting and verbosity of cjxl. Wb already worked on it and I had made suggestions that got implemented, but tailoring it to just what I think obviously isn't ideal Current default ```JPEG XL encoder v0.9.0 c3a4f9c [AVX2,SSE4,SSSE3,SSE2] Encoding [Container | Modular, lossless, effort: 5 | 982-byte Exif] Compressed to 3637.5 kB including container (3.508 bpp). 3840 x 2160, 1.449 MP/s [1.45, 1.45], 1 reps, 16 threads.``` Proposed default ```JPEG XL encoder v0.9.0 c3a4f9c [AVX2,SSE4,SSSE3,SSE2] Encoding 3840 x 2160 [Lossless, effort: 5 | Exif] 2311.8 KB compressed to 3552.2 KB (3.508 bpp) 1.449 MP/s``` Removes more detailed info for verbose output, changes kB to KB to keep in line with OS displayed size (Could adjust to MB too), shows original size for easy comparison, moves resolution to the encoding line and encode speed to the compressed line Current Verbose ```JPEG XL encoder v0.9.0 c3a4f9c [AVX2,SSE4,SSSE3,SSE2] Read 3840x2160 image, 2367327 bytes, 475.8 MP/s Encoding [Container | Modular, lossless, effort: 5 | 982-byte Exif] Compressed to 3637.5 kB including container (3.508 bpp). 3840 x 2160, 1.469 MP/s [1.47, 1.47], 1 reps, 16 threads.``` Proposed Verbose ```JPEG XL encoder v0.9.0 c3a4f9c [AVX2,SSE4,SSSE3,SSE2] Read 3840 x 2160 image, 2367327 bytes, 475.843 MP/s Encoding [Container | Modular, lossless, effort: 5 | 982-byte Exif] Compressed to 3637451 bytes including container (3.508 bpp). 3840 x 2160, 1.469 MP/s [1.47, 1.47], 1 reps, 16 threads.``` Changes sizes back to bytes for accurate results, makes formatting of resolution and MP/s between read and compressed identical, shows the info removed by default

strictly speaking kB is more correct, and I don't believe cjxl should mimic whatever some specific file browser uses

Oh, I thought KB was most common for filesystems, but this is why I posted here instead of straight to Github

KB is how Windows displays it but it matches no standard

SI: powers of 1000, kB, MB, GB, TB IEC: powers of 1024, KiB, MiB, GiB, TiB Windows: powers of 1024, KB, MB, GB, TB (confusable with SI except for the first one)

I would personally oppose using the Windows way

it seems macOS uses SI

(well, the GUI apps do)

GNOME uses SI as well I believe

I vaguely remember KDE (Dolphin) using IEC but it’s been a while so I’m not sure

From what I could find everything was IEC (1024) until IOS 10 where apple changed for SI

maybe they were getting tired of people complaining that their 500GB drives didn’t actually contain 500GB

God this is confusing, now it's saying everything is SI apart from Windows

I'm sure there are linux distros/DEs using IEC

I guess stick with SI since with the original size listed too people can see the difference whatever their OS reads

Caja uses 1024

GNOME switched to SI units circa 2010, and Apple since 2009 with Mac OS Snow Leopard (and later iOS 10 in 2016)

if you find remaining inconsistencies in GNOME apps, I'd be interested to know

apparently it's configurable in caja, I discovered

surely System Monitor is inconsistent with reason

also, how does GNOME UI keep getting worse with time

```JPEG XL encoder v0.9.0 c3a4f9c [AVX2,SSE4,SSSE3,SSE2] Would you like to encode an image?```

I prefer 1000 but don't mind 1024 as long as you actually use the IEC prefixes.

I'm not going to bother answering a biased vague subjective statement like that other than by "Works great for me." (<@263300458888691714>)

>powers of 1024, KB, MB, GB, TB That's how it was originally. KiB, etc is a recent invention that's pretty much useless in clarifying between real KBs (1024 bytes) and commercial KBs (1000 bytes).

how is it useless?

Because commercial KBs are still ambiguous.

"real KB" always should have meant 1000 bytes; the K prefix long predates its use in measuring data capacity

sure, but if i see KiB i know exactly what it means

That's how HDD manufacturers justify themselves, sure.

so?

I'm fairly sure sector sizes of partitions are always IEC unless something drastic changed the past few years, so a 1 kB file is always 1 KiB, right?

filesystems might use even larger blocks like 4 KiB

but it makes a difference when files are big enough; the difference between 1 GB and 1 GiB is 18,004 4 KiB blocks

Yeah, was just using 1 KiB as an example

Maybe KiB makes sense if that aligns things to sector sizes or whatever. But I don't really see why you would need to keep using powers of two beyond that.

MB/MiB is close enough for me most of the time. What really trips me up is that network transfer speeds are measured in bits instead of bytes

1 kibibyte = 1.024 kilobyte 1 mebibyte ≈ 1.049 megabyte 1 tebibyte ≈ 1.100 terabyte 1 exbibyte ≈ 1.153 exabyte

What was a 2-5% difference in the 1980s back when a megabyte was a large amount of data, is more like a 10-15% difference for today's storage capacities...

235 kB turns into 230 KiB, probably best to just stick with kB but also show original size like in my draft, then no matter the OS or software, you see the difference in the output

transfer speeds are traditionally measured in "symbols" per second

and the dominant symbol ended up being a bit :)

the definition of "baud" is "symbols per second", but of course with 1 bit symbols you get "bits per second"

Thankfully, I can change the settings on my KDE desktop widget to show bytes instead of bits, so I don't have to approximate in my head. I usually don't like aggressive homogeneity via "standards" being enforced, but data measurements are one area I'd be fine with making an exception. All the definitions above make my head hurt, thinking about them in practice. (<@189835259242741760>)

I recall reading something from I think the 60s where someone was complaining about some fancy new 1024 byte memory module being marketed as "1 kilobyte" and saying that an alternative to the SI prefixes should be found. Of course, back then, it really was just plain rounding, 1000 and 1024 being close enough that a bit of rounding was OK.

I’m not going to blame manufacturers for following what “kilo-” has meant for centuries to all but a few engineers who later thought “eh, 1024 is close enough” and wrote it in uppercase

the only ones who make it ambiguous are those who cling to that non-standard interpretation

I’d rather just kill it for good

It's not "a few engineers". It was a whole damn IT world. It's kinda weird accusing Windows of being "non-standard" when it was following de-facto standard when it was implemented.

Well, ISO exists for a reason 😅

I’m glad everyone agreed on a date format we should use so we are not stuck with whatever some engineer came up with in the 60s

we're stuck with whatever some engineer came up with in the 70s

unix time superiority

seconds since 1970 began UTC

Unix time is not that, unfortunately. It's the number of seconds since that date, *minus* the number of leap seconds since then. This makes it really annoying and terrible.

Except networking and storage :p

Adding on to that `text` box idea, I wonder if djxl could then restore it into new PNGs

Everything can be done, it's all just chunks and boxes. In practice I don't know if cjxl/djxl matter much — it's what applications like imagemagick, libvips, ffmpeg, gimp, photoshop etc do that matters. Libjxl only gives an api to write and read boxes, whether you use that and what you put inside of them is up to you...

Yeah, just thinking of legacy programs that still want PNGs with 'custom' text chunks, then you still get the savings of JXL with relative ease of use

I mean, it’s also a bit weird to say that “kilo” for 1024 was how it was “originally” (and that 1000 is “commercial”), when the kilo- prefix for 1000 (itself from the Ancient Greek word for 1000) dates back to the 18th century and was standardised internationally in 1875

and people use 4k for UHD when it's not even 4k

and dci 4k is also 4096

I think it'd be cool to have somewhere in there a percentage number for how much smaller/larger the file became after encoding

imo the more egregious one is 1440p monitors being commonly referred to as "2K" by stores

as if to separate them from 1080p

which are _also_ roughly 2K if 16:9 or wider (1920×1080)

2560x1440 is a bit off from 2k IMO

yes, if anything, it’s 2.5K 😁

Anybody know how to make a HDR .jxl file? Wide gamut should be simple enough if you just embed an ICC profile but I’m not sure how to add extended dynamic range

Maybe I need to try adobe camera raw, according to the docs it supports HDR jxl and avif out of the box

i would imagine color profile + floating point input would be needed, so you can just provide samples above 1.0

Are you talking about cjxl? I don’t have enough skills to use libjxl API directly

that works in cjxl if your input is floating point

i just compressed an openexr file i have and the resulting jxl has samples above 1.0

HDR works in int16 as well, it doesn't have to be float

the primary difference between HDR and SDR is that HDR transfers (e.g. PQ) are in absolute light levels and SDR is referred

that's what the intensity target is primarily for

so like, in int16 you specify how many nits 65535 is and in float you specify the level for 1.0?

yea

basically

float can go above 1.0, but you can always use int16 and set the 65535 level in nits to be something higher than the peak brightness of the image

and then the inability to go above 1.0 is not an issue

(HLG is relative like SDR, but the exact transfer function varies with peak luminance)

https://www.reddit.com/r/jpegxl/comments/wnf0ou/comment/iks1z3o/

here's my attempt:

on my phone, what's different? higher distance?

does jxl support 16 bit float? the jxl i sent was actually encoded from a 32 bit float exr, not 16, but idk if that would've made a difference in encoding

this one has actual HDR metadata & displays the full dynamic range

I used `exr_to_pq` & copied the target luminance info for the cjxl encode

interesting, what was that info? i don't think i set a target luminance

`exr_to_pq -l max=1000 final16.exr final16.png`

`cjxl final16.png final16.jxl --intensity_target=1206.76 -e 9 -p -v -d 1.0`

What color profile was the original exported in?

srgb

https://cdn.discordapp.com/emojis/654081052108652544.webp

10k nits

😶

try doing white=1000?

`[1] 195464 illegal hardware instruction (core dumped)` lmao

with max=8k it looks like a mess

just wondering what's the chance that software can still read JPEG XL in 20-30 years? Is it a good archival format?

That's the goal, yes.

so should i archive images using JXL or use something like JPEG (legacy) or TIFF

I would strongly recommend against using legacy JPEG to archive images unless they *already are* legacy JPEG

since it's lossy

if you don't mind that, JXL is still significantly better

As in they’re currently in legacy, should I lossless into JXL?

it seems like it should be safe to do, if they currently reconstruct properly

(I can be slightly paranoid with this sort of thing so I would still make sure that this is the case before deleting the originals)

But will the format still work in 20+ years ?

Like will jpeg xl be obsolete

I can’t give a 100% sure answer, but the more people use it, the less likely it is to die

Fair point

there will be more people with an incentive to keep it working

Also I’ll keep a PDF of the spec just in case

yeah but waht about jpeg xl 2

jpeg xxl

JPEG - 2100?

Hopefully would be backwards compatible

jpeg 2xl4me

I think the likelihood that you will not be able to open a jxl in 20 years is low. Even if adoption-wise it becomes a complete flop, I think it's already sufficiently established to assume that at least in some software it will still work in some software. E.g. ImageMagick can still open way more obscure formats from 20+ years ago...

Ok cool 😎

Worst case, you'll still have the reference implementation while making the archive, so either windows will still have 30 year backwards compatibility or you could compile the Github code into whatever platform we're using

yeah, just make sure to keep a copy of your own if you want to be on the safe side

waking up in 30 years: “I’ll just grab libjxl from githu… wait, where _is_ github?”

“anyone has a djxl.exe around?”

"Anyone remember C++?"

one time I needed an old minecraft mod and the only place I could find it was inside a single obscure mod pack whose original hosting no longer existed

God, you reminded me when I spent a week trying to find an old mod from 2011, now that was a pain in the arse

it seems like the minecraft community has/is done/doing a very very awful job of archiving older mods which is leading to more and more mods disappearing each day

It's standardized, open source, and supported natively on Linux. You can't really get more future-proof than that, since Linux will probably outlive any other platform. (<@386612331288723469>)

~~By design, JPEG recompression will be lossy in some cases, so~~ you must perform a round trip and verification on every file if you care about preserving data.

In principle libjxl should return an error if it cannot losslessly recompress a JPEG. There might be bugs that cause it not to roundtrip, but it is designed to either roundtrip or return error.

I hear that Instagram & Facebook Reels are being served as HDR if a source video is HDR only on Apple devices that support it currently - could this mean Facebook tries to do something similar with image delivery? JXL supports HDR, they'd be able to transcode existing JPEGs for iPhone users, & suddenly the iOS experience is far ahead

Oh, I guess this behavior was dropped, which is good https://github.com/libjxl/libjxl/pull/358

I remember a vague quote from Facebook saying they had the JXL support ready years ago but just needed to flip the switch

or https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c16

Yeah

spider mario, what is the difference between `-l white=XXX` & `-l max=XXX` in `exr_to_pq`

`-l white=x` means that (1, 1, 1) in the EXR is `x` cd/m², `-l max=x` means that whatever brightest pixel is actually found in the EXR (not necessarily (1, 1, 1)) is `x` cd/m²

so, for an EXR that goes up to (7, 7, 7), `-l white=100` and `-l max=700` would be equivalent

Gotcha. Is there any way to parse EXR metadata to look for those values? I'm not sure how high mine might go

Also, <@184373105588699137> this might explain things

ah, I thought it was applied on output not input, that can indeed explain things

wait, then `-l max=` should still properly equate the peak nits right?

unless my script is bunged up, could be mapping error I suppose?

hi <@794205442175402004>, does the JXL project have a particular release schedule? Having this information can be handy for downstreams like desktop environments and distros

I agree it would be practical to have a schedule, but currently we don't have one — it's ready when it's ready...

ah I guessed so \:)

we could probably at least anticipate and announce some time in advance when the next release will be, when we are sufficiently close to it....

for now, as far as I understand, for 0.9 we still want to get the decode-cms thing and the no-aborts thing done. Possibly also chunked encode, if that is ready.

what form of tonemapping does `exr_to_pq` use? im getting nit peaks far higher then what is set by `-l max=700` when using ocio's python tools

no tone mapping, but very chromatic highlights might be throwing off the max calculation

I would generally favour `white=`, it should be more predictable

less dependent on the exact image content and more on how it was produced

ahhh I see

exrstats from exrtools is an option if packaged for your system

hmmmm, I wonder how hard it would be to add jxl to oiio...

<@703028154431832094> I now see that openimageio’s `iinfo` tool with the `--stats` flag is also a viable option, thanks <@184373105588699137> for pointing me to it 😁

yeah, oiio is typically what I use for working with still exr images, so having native jpegxl support for that is quite tempting, I may work on it should I find the time but it would be quite low priority sadly

that being said, it shouldn't be too hard to work with since iirc it's mostly just standard affair, example for jpeg is here https://github.com/OpenImageIO/oiio/tree/master/src/jpeg.imageio

though colorspace stuff would be nice to support in ocio too im not sure how necessary it would be?

looks like placebo bug in SDR -> SDR contrast ratio got fixed

which means this works again: `ffmpeg -i xyb.jpg -vf libplacebo=color_primaries=bt709:color_trc=iec61966-2-1:format=gbrp rgb.png`

er, not necessarily

hm

ah it is, I had forgotten to recompile placebo <:kek:857018203640561677>

Can anyone help with https://github.com/libjxl/libjxl/pull/2704 ? We're looking for JPEG encoders (hardware or software) that produce bitstreams with empty DHT segments, i.e. containing the sequence `0xFFC40002FF`

this is rare/unusual/useless behavior but apparently it does exist, we just don't know how common it is

lots of mentions of JPEG XL in https://news.ycombinator.com/item?id=36982507

so I tried searching for the CDN for that image to try to find its source

hm

Is there a firefox fork that follows Firefox development and regularly merges in patches, similar to how Thorium does with Chromium

Preferably with JXL support

iirc some firefox forks like Pale Moon are based on older versions of firefox and have sort of diverged

i would do it except mozbuild breaks every week

I looked at waterfox, dunno if they are what I'm looking for tho

waterfox tracks ESR pretty closely, but they dont do a lot of patches, but they certainly do some, librewolf maybe? IIRC at one point they had jxl support at least,

Tested waterfox. It passes: https://jpegxl.info/test-page/

dunno if they merged W's patches or not but the animation works, so I suppose yes?

I believe so yes,

yes they did, forgot about it myself lol https://github.com/WaterfoxCo/Waterfox/pull/2938

Waterfox crashed on CMYK JXL images last I checked. I dunno if they fixed that or not.

Mercury. https://thorium.rocks/mercury

aren't Mercury and Waterfox by the same guy

oh wait nvm I'm misremembering something

Mercury & Thorium are by the same guy

wha

um actually

<:PepeOK:805388754545934396>

I just adopted the AUR package for waterfox-current-bin

Are extensions designed to be forward-compatible like unknown PNG chunks?

i.e. are decoders required to ignore extensions they do not recognize without erroring?

If so, why not have a Text extension in the codestream, which contains an entropy-coded stream of UTF8-encoded text?

Or rather, it contains an entropy-coded stream of Unicode Codepoints

Unless that's more difficult than doing 8-bit UTF-8?

not sure which would be harder to do, but I wonder if it would make sense to have a text-extension like the equivalent of PNG's `zTXt` chunks

extension bits are read and ignored

ah so it does say that

> Extensions for ImageMetadata, FrameHeader, and RestorationFilter are not currently defined, so the decoder reads and ignores any extension bits specified there.

Maybe something like: ``` u(8) | "und" | country_code[3] U64() | 0 | compressed_length ``` ("und" for unspecified language, and "zxx" for the "encoded text has no linguistic content") If the `compressed_length` is nonzero, a decoder then reads an entropy-coded stream with one pre-clustered distribution, and then it reads `compressed_length` symbols from that entropy-coded stream, using `0` as the context each time. Each symbol has a value between 0 and 255 (inclusive), and the concatenation of all symbols forms a UTF8-encoded text stream.

If `compressed_length` is zero, then no entropy stream is read. Instead, this extension tags the linguistic content of the image data itself.

I'm thinking that since the extensions bundle itself has a size, there's no need to tag the uncompressed length of the entropy stream

That's better done as file format boxes imo. Codestream should be for things that have rendering impact.

One possible use for codestream extensions would be some new kind of gaborish/epf filter (which if ignored, still gives you a reasonable image), or maybe some extra index/toc that could help to speed up decoding in some way.

The capability to contain clipping path (with existing splines) would be a nice extension

perhaps. maybe add `tEXt` boxes? and maybe allow them to be embedded in `brob`

See also: https://github.com/libjxl/libjxl/issues/2641 and https://github.com/libjxl/libjxl/issues/2687

Arbitrary text makes sense, though I don't think we should just use all PNG chunks

since JXL is not a PNG recompressor

stuff like `tEXt` is generic enough that plaintext and brob boxes could cover it

but I see no need for arbitrary PNG chunks like bKGD or hIST or tRNS

etc.

but text-based metadata is low-overhead, especially when the brob mechanic exists already

It's less about "PNG recompression" and more about "text metadata makes sense to have as a thing"

Would be nice to have lossless be lossless, instead of throwing away the text

Agreed

Wait what is usually put in those chunks other than XMP?

Application specific things?

ImageMagick uses it for plaintext creation/modification timestamps

Some genAI uses it to store the prompt

In general I think it would be better to avoid generic plaintext where only humans can make sense of the semantics, and use something like XMP instead so standard field names can be used when possible (and new ones added otherwise)

problem is XML is terrible

Just out of curiosity, has anyone tried using cjxl on Android using something like Termux?

I got sent down that rabbithole a bit after trying to find some app that would encode JPEGs using MozJPEG and someone suggested I try using Tetmux + ffmpeg. It turned into a bit too big of an ordeal, but I thought I might try seeing if I could play around with encoding JXL files before unistalling Termux.

yes, it works

https://media.discordapp.net/attachments/808742092213715034/947437547854909490/android-users-viewing-a-jxl.mp4

bro charge your phone

i don't even use that phone anymore

18 month old video

So, is installing the same as on a Debian distro? Or do I have to build it?

install libjxl-progs from their repos

idk if it's up to date but it exists

And cjxl works fine too. I use it a fair amount inside of Termux.

Found the repo listing. It looks fairly up to date (July 2023). Should I go with regular libjxl or the progs one?

i'm guessing regular libjxl is only the library and -progs includes the cjxl and djxl programs

Thanks for the help! It installed fine. One more question\: is there a beginners guide for commands? The libjxl Github shows a few starter commands, but I'm super new to using CLI tools to work with files, media or otherwise.

<:megapog:816773962884972565>

so i just learned about jxl today

i have some images i rendered in blender that are 48bpp and end up needing 130MB as png

i found out that Krita can read/write jxl, so i tried converting one of those images. I compared the png and jxl images and they aren't exactly the same! does krita have a bug or does jxl not like 48bpp images?

Are sure that you're using lossless JXL?

^^^ how did you convert them image

lossless was checked when i exported

i opened the original png and the converted jxl in krita, set one of the layers to Difference, merged them, and then used the color sampling tool to check if everything is 0,0,0. but no, most pixels are like 1,0,0 or 0,2,3 etc.

its not the worst error in the world, since its just off by like 3 out of 65535. but still, lossless should be lossless so whats going on here?

is there a different program i can use, so that i can eliminate the possibility that its just a Krita thing?

I know Krita has a few bugs with JXL that are being fixed in the next release, but if you want to be certain then you can use the reference software from Github Either from Releases https://github.com/libjxl/libjxl Or you can get the most recent from here https://artifacts.lucaversari.it/libjxl/libjxl/latest/

You can try using cjxl/djxl to see if things are different

i will report back with results later

If it's a 130MB PNG, then I assume it's fairly high resolution. On effort 9 it can use a *lot* of RAM so I'd be a bit wary of that

130MB 😳

I've had 150+ before :P

150+MB 😳

using these tools, the jxl file is 100% lossless. so yeah, krita is dum dum

i got plenty of ram. it does take 41 minutes to compress though

Yeah, that sounds about right. How big was the resulting file by the way?

81 MB

the original png was made with blender, which has the best png compression i have ever seen. the converted-back png is 134 MB

Yeah, Blender is one of the few programs that compresses PNGs 'Properly', I know there was mention of changing the djxl PNG encoder too

im just glad to see that jxl is in fact lossless as advertised

is there something i can install to see thumbnails of jxl files in the windows explorer?

It can do even more than 16 bit per sample losslessly, but probably applications that can handle that properly will be rare

I think there's a WIC thingie somewhere, no idea how well it works though

I haven't used Windows since 1998 or so, when I finally removed that Windows NT 4 partition

https://github.com/saschanaz/jxl-winthumb I mentioned it to a friend in a voice call while they were screen sharing a while ago, they installed it live in about a minute and we both watched the file explorer fill with color haha

how do i install this

its just a dll?

Huh, I could've sworn it had install instructions before...

Download the DLL from releases, put it somewhere safe (Maybe a JXL folder under Program Files), open cmd there, run `regsvr32 jxl_winthumb.dll` then it should start generating previews (`regsvr32 -u xl_winthumb.dll` to uninstall)

Ah yeah, the instructions were on the initial release > How to use: > > Download the dll file > Open a terminal window as administrator > Move to your download directory > `regsvr32 jxl_winthumb.dll`, or to uninstall, `regsvr32 /u jxl_winthumb.dll`.

doesnt looks like my computer wants this

the file was found and loaded, but DllRegisterServer failed with error code 0x80004005

Huhh....

First thing I get searching that is no Administrator privileges

ah makes sense

works now

Nice

the colors of the thumbnails are off though. left is jxl, right is png

Yeah, that was an open issue on the github

It would be nice to have a fully working and easy to install windows solution! Even if this discord is full of bearded geeks, windows users still represent a huge part of the potential users

There was a bat file in the old version that ran the DLL register and modified registry so Microsoft Photos would work too, but not sure if it's up to date

Oh wait, apparently that was to make an executable that would do it all for you, but never put in releases https://github.com/mirillis/jpegxl-wic/blob/main/installator_setup.iss

What does `jxlinfo -v` report for the encoded JXL? If I had to guess, it's probably setting the distance to zero but isn't disabling XYB.

hmm interesting, I can't reproduce it myself even on krita 5.1.5

From the sounds of it, it was 16 bit per channel if that makes a difference

Yep, tried roughly the same.. exporting 16bpc RGB (48bpp) from blender, open in krita and export it to lossless jxl

Did you have animated checked as well? Could be something weird going on there

animated is checked by default and i didn't touch it

``` box: type: "JXL " size: 12 JPEG XL file format container (ISO/IEC 18181-2) box: type: "ftyp" size: 20 box: type: "jxll" size: 9 box: type: "jxlc" size: 85018837 JPEG XL image, 8192x6144, (possibly) lossless, 16-bit RGB+Alpha num_color_channels: 3 num_extra_channels: 1 extra channel 0: type: Alpha bits_per_sample: 16 alpha_premultiplied: 0 (Non-premultiplied) have_preview: 0 have_animation: 0 Intrinsic dimensions: 8192x6144 Orientation: 1 (Normal) Color space: RGB, D65, sRGB primaries, sRGB transfer function, rendering intent: Perceptual ```

So xyb is not the issue... Might be something like passing buffers in a different format or colorspace

doing some experimentation

so i converted the png to jxl using krita, and then i converted that back to png using djxl

i opened the two pngs in krita and compared. no difference

this means that krita doesnt read jxl files correctly

next test: open original png and the jxl made by cjxl in krita. compare. different

yeah krita is doing something wrong while decoding

It might be doing some unnecessary color transform that is slightly lossy

can you try another test: re-export the original blender png to krita png (make sure to embed the profile), and then compare the new png to the jxl one?

im gonna be honest, at this point i dont have the actual original file anymore. i can at best use the png made by djxl

how do i make the god damn bot stop pinging me, i hate level-up bots so much

no difference between krita's png and djxl's png

I'm still can't reproduce it on krita by difference layer and color picking yet, but testing with DSSIM tells another story.. I'm gonna make a guess it's the krita's png decoder that might be slightly off when dealing with cicp instead of icc on png

seems like blender's export didn't seem to use icc on png?

oh right, one thing as well that krita 5.1.x do try to store lossless jxl with cicp enum as well instead of icc.. which is might be also a contributing factor..

you could probably block it, I assume doing so prevents pings.

hi <@794205442175402004>, you might be interested in https://gitlab.gnome.org/GNOME/gnome-build-meta/-/issues/698#note_1801107 where it turns out GNOME needs to temporarily revert the JXL addition to OS, due to the lcms support not being in a released version of libJXL \:(

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6886 too which seems at least in big part related to libjxl's dynamic noise feature

Interesting that noise makes that much of a difference

For synthetic wallpapers I think they should just disable noise if they only use it as a dithering method so they can use 8-bit output without banding. We will probably have an option to let libjxl do the dithering. They could also use 16-bit buffers and do their own dithering

That said, perhaps there is a performance bug in noise synthesis? Maybe only in the specific callback codepath they use? Worth investigating... Could someone open an issue at libjxl for it?

Could it be that they wanted to add synthetic noise as an artistic filter/effect ? Is it even possible?

<@794205442175402004>\: do you think it would be possible for your library to be introspectable by [Sysprof](https://wiki.gnome.org/Apps/Sysprof) (I've no idea if it isn't already, but I would think Christian would have pointed an exact culprit already if that was the case... or maybe he didn't have the time)

could be one more tool in your arsenal

No idea what has to be done for that besides, I assume, building with debug symbols

I guess you can mute that bot or something in your discord? I understand it's annoying, but it's also kind of nice to see who are the more active people on the discord - though of course game-ification of chatting is kind of silly

do we not want to advise trying out the faster_decoding flag (or whatever it is) as well?

you can mute the channel

this seems to suggest we should do 0.9 before september

that's odd... I could understand it being related to lcms, but noise ought not to be *that* slow

Or to backport relevant changes into 0.8.3

How to store the prompt from png text chunks in .jxl file?

I'd move the text from a raw text chunk to a field in XMP or exif.

> an XMP packet is embedded in a PNG graphic file by adding a chunk of type `iTXt` with the keyword `'XML:com.adobe.xmp'`

You can use a tool like TweakPNG to do so

https://github.com/jsummers/tweakpng

It's windows only, but it works in Wine

out of curiosity, how does `cjxl` work with `iTXt` fields tagged with `XML:com.adobe.xml`

does it take the XML data inside and verify it or pass it as-is?

if so, you might be able to embed non-xml data in JXL's xml section

No, just takes it as a blob without verifying

how is XMP embedded in jxl?

Is there a box for XMP specifically? what about IPTC

There is the `xml ` box and the `Exif` box that are specifically mentioned in the spec, where XML boxes are typically used only for XMP but in principle it could be anything xml

For iptc we didn't put anything in spec since iptc fields should be written as xmp or exif but not using the legacy iptc thing

Can it be non-XML?

it seems a bit odd if text based metadata can only be XML, given how bad XML is

It’s industry standard 🙃

Well there is `jumb` which can have payload boxes in various formats

What is so bad about XML? It's verbose, but with `brob` that's not a big problem... Anything else?

XML proper is almost fine, associated "technologies" aren't

the biggest problem with XML proper is an overdependence on textual format

a lot of things are terrible about XML, namely that trying to parse it leads to a bajillion security vulnerabilities

libxml2 has two active CVEs in the current version on Debian, for context

much of the industry has moved to JSON if they can

I think for metadata, it’s mostly just an implementation detail. You probably don’t have to directly interact with XML since libraries will return the data in a data structure native to the programming language

i like XML

clearly you haven't tried to parse it then

https://www.computerworld.com/article/2582828/the-threat-of-xml.html

Here's an article explaining how bad it is from the year 2001

https://cheatsheetseries.owasp.org/cheatsheets/XML_Security_Cheat_Sheet.html

https://www.opswat.com/blog/depth-look-xml-document-attack-vectors