JPEG XL

after trying, seems jxl cant be set as wallpapers - listed and selectable, but wallpaper doesnt change

in file properties/details theres no metada filled but system recognizes its an image and shows blank fields (shoved a file inside a music-only library set as such in case it was previously just an assumption from being in an image folder)

reconstructible jxl from jpg doesnt decode

right click on jxl and you get the option to rotate or set as wallpaper

I see, so it's still very experimental

experimental doesnt leave canary

in theory, but what you're describing is that it doesn't work

work in progress?

jxl is listed as an image format, signatures are registered, but there's no actual decoder now

Finally done, mostly https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/4055#issuecomment-2002158159

Merged at least, but missing a few features

any news for XYB JPEG support in FFmpeg ?

it has supported XYB jpeg for a while

you can decode XYB jpegs in FFmpeg just fine, and it just forwards the ICC profile

left PNG right cjpegli XYB JPG both are displayed using `ffplay`

ffplay is not color managed

this has nothing to do with XYB jpeg

play it with mpv or plplay

works great with MPV 0.o unfortunately my image viewer (pqiv) uses FFmpeg, so it has that color error too 🥲

that means your image viewer is not color managed

the issue isn't using ffmpeg the issue is ignoring color profiles

throwing the pixels at the screen without regard for the ICC profile is incorrect

like mpv uses ffmpeg too i think

and causes the undesirable behavior

indeed, mpv decodes the jpeg with libavcodec

thanks <:PepeOK:805388754545934396>

I did a bunch of work to get ffmpeg to decode weird subsampled RGB jpegs that were produced by old versions of jpegli

and then some changes to libplacebo to work correctly with the XYB icc profile

e.g. https://code.videolan.org/videolan/libplacebo/-/commit/5f44a16fb2ebf2e1893b847429dabf5595fed730

couldn't you use libplacebo filter to render out the image with the icc with ffplay? I thought you could but im not too sure now

yes

so I opened an issue and they answered: > pqiv uses GTK's own GdkPixbuf for rendering standard file formats, and it looks like it doesn't really support this: > https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/104 > Do any Gnome default viewers get this right for you? I don't know any (even that don't work with ICCs) <:KekDog:805390049033191445> I just know that the FilePicker dialog doesn't support ICCs

GdkPixbuf supports ICC profiles

see the gdk-pixbuf loader in libjxl

and I use Eye of Mate and it works fine

the answer is the icc profile is a base64-encoded null-terminated ASCII string

with the `icc-profile` option key

used in `gdk_pixbuf_get_option`

Eye of Gnome, the gnome image viewer, also works fine

nice thank you

(figuring this out was not easy, btw)

you can call `gdk_pixbuf_get_option("icc-profile")` which returns a `gchar *` string, and then you can use `g_base64_decode` to get the actual ICC profile buffer

which can be fed to lcms2 or something of that form

so could we consider that an "uncommon" ICC in JPG ?

the XYB icc profile? yes I'd consider it unusual

the fact that it's "base64-encoded null-terminated ASCII string"

oh, that's just how gdk pixbuf does ICC profiles

oh ok

the "icc-profile" option is just the icc profile, encoded as a base64 string

why they chose to store the metadata this way? I do not know

Oh yeah, I'm not sure if anyone ever mentioned and it seems obvious, but https://squoosh.app/ also supports JXL *input* and will display on browsers without support

Just playing with some resampled pixel art and now I can see every other format at... Well uh, yeahhhh....

extremely outdated version of the jxl decoder and encoder, no?

afaik its still 0.5 or 0.6 from 3 years ago (!) from before the bitstream was even finalised and forward compatibility guaranteed

https://assets.nintendo.com/image/upload/ar_16:9,b_auto:border,c_lpad/b_white/f_jxl/q_auto/dpr_1.0/c_scale,w_1200/ncom/en_US/products/hardware/nintendo-switch-oled-model-white-set/115461-switch-oled-white-boxart-1200x675

Nintendo serving JXL?

where'd you get that URL?

From a 4chan thread

it is indeed a <:JXL:805850130203934781>: `115461-switch-oled-white-boxart-1200x675.jxl JXL 1200x675 1200x675+0+0 8-bit sRGB 49465B 0.000u 0:00.004`

I notice it says f_jxl

or from `jxlinfo`: ```JPEG XL image, 1200x675, lossy, 8-bit RGB Color space: RGB, D65, sRGB primaries, sRGB transfer function, rendering intent: Relative```

I cant open it it just closes itself lmao

its an option. avif is served if jxl not supported and default even for jxl supporting clients. shows their cdn provider totally generates the images - cloudinary?

I think it seems to prefer avif for me

So, is anyone here running safari, and can tell us what % of images they serve in JXL?

Or download Pale Moon

I changed it to f_auto and opened it in Safari, it gave me a JPEG1

So I think Nintendo has not opted into serving JXL's to people automatically

hmmm, it doesn't use accept headers T.T

f_auto uses accept headers AFAIK

But Cloudinary doesn't serve JXL by default yet

website operators must opt in

got latest safari build running on windows, fetches and downloads jpg

im browsing nintendo's site and using the below and it's still giving me avif ```ps Accept: image/jxl,image/webp,*/* Accept-Encoding: gzip, deflate, br Accept-Language: en-US,en;q=0.5 ```

aren't you opting into avif with that `*/*`?

Accept-Language should be en-CA for you 😉

it's an option but it should be lower prioritized [Hmm](https://cdn.discordapp.com/emojis/1113499891314991275.webp?size=48&quality=lossless&name=Hmm)

yeah if you do that half the websites you come across are french for some reason

CDNs don't care about priority

they used to [av1_PepeHands](https://cdn.discordapp.com/emojis/654081051768913941.webp?size=48&quality=lossless&name=av1_PepeHands)

oh common > Accept > image/jxl,image/webp,image/png type: webp

solution: refuse to accept anything except <:JXL:805850130203934781>

in the biggest markets (us, uk, canada and japan), 35% of the mobiles in active use support jxl and thats before any additional support in their own mobile apps or chromium

thorium serving avif to me as well, I can't get it to serve JXL at all unless I manually use f_jxl

almost all avifs are served by cdns and as delivery-only images for whats originally jpgs. the original jpg should always be the fallback

yeah even when using accept image/jxl only it serves jpeg and png

i wonder what cdn is used <:Thonk:805904896879493180> cloudinary?

> f_auto uses accept headers AFAIK > But Cloudinary doesn't serve JXL by default yet > website operators must opt in

Yeah, not much activity lately but they updated both libavif and oxipng recently so probably just patching commits in other forks https://github.com/GoogleChromeLabs/squoosh/issues/1402

yeah that would be it

universal defaults for all regions make no sense anymore. in those markets jxl should logically be the first format served

Google Chrome Labs... no wonder it's not updated 😮‍💨

Ironically, I'm actually using 0.6 to test <@532010383041363969>'s Delta Palette (Or at least I assume it's mostly theirs, since they're the pixel wizard always experimenting)

And not quite, bitstream was frozen around 0.3, which is no longer avalible to download from the Github releases

<@794205442175402004> do you have anything you can share on when JXL might start being served by default by Cloudinary?

my only guess would be that they're waiting until more browsers get support?

better yet, by other cdns like cf. it seems they had a working pipeline they activate for even small clients the moment they ask

I remember Facebook's old comment on the chrome issue saying they were ready to 'hit the button' on full support

probably because jxl support is unstable except for safari, and forks have a very small percentage

I know Firefox Nightly's support is still a mess, but assuming most are either on Safari or Forks is there any downside to turning it on?

anyone who serves their own content to their own mobile apps shouldve hit that button regardless of browsers' implmeentation (like shopify, web builders, social everything or any app that serves its content **only** through its own app). that alone wouldve made mobile apps serve content much quicker than the full website in a browser

(If someone goes out of their way to enable the nightly flag, they probably know not to use the Firefox JXL anyway)

for a cdn or a browser? I cant claim to understand how cloudinary works, but as a general "CDN" standpoint, if they arent seeing the numbers of devices enabled, it could just be that it doesnt make sense to spend the extra cputime/storage on it

Somehow I completely forgot the images are cached and not just computed realtime.... Which obviously wouldn't work at all

i know theres slow movers but leading web services arent supposed to operate by long outdated market conditions like theyre shipping physical products whose state cannot be changed post-delivery

every recompression from jpg to avif/webp is *lossy* and a full conversion, whereas jpg->jxl is almost instant on any hw, consistently guarantees 20% lower filesize and introduces no extra data loss. this alone is a web changer

wget gave me a JPEG-XL

I can download it directly from the browser, but there's no suffix

Doesn't matter on Linux, though.

I got a friend to test it on an iPad and it directly loads in safari

yep, serves me a jxl using Floorp

well, that makes sense...

anyone wanna try bleeding edge safari on windows, its 2 zips extracted to the same folder

the nintendo website does use Cloudinary so if you force it to serve JXL by changing the endpoint to f_jxl, it serves <:JXL:805850130203934781> , but normally f_auto just serves AVIF, as, well, expected...

<:This:805404376658739230>

theres no point serving avif to ios/safari though like its an express cloudinary client request demanded with an iron fist

Usually you can't force it because transforms are locked. Unlocked transforms are for debug purposes only

yea, i found that weird too, i don't think we're supposed to be able to change "f_auto" like this...

It's still opt-in, we do have some customers who did opt-in already. We're now serving about 40 million jxl images per day, still peanuts but quite a bit more than the 1-2 million jxl images we served per day beginning of this year.

I'm eagerly awaiting the day it stops being opt-in, suddenly there would be a lot of traffic to cite as evidence of jxl being widely used.

I wonder how busted a "redirection" app would be that would `s/f_auto/f_jxl` probably pretty busted

those are some good numbers 0.0

strange increase ! which client caused it ? 😄

truly, that's some real "ecosystem interest"

the first peak was probably people not using their windows computers because they were busy with christmas (so using their iPhones more instead)

Here are the top "browsers" we see with image/jxl support (numbers are for some random day one or two weeks ago)

Im assuming most of these are webview/platform stuff on ios?

yeah, probably mostly the iOS versions of the apps

If I scroll a bit down I also see Pale Moon 30,892 0.00%

What reasons did those customers give for opting in to JXL support? Like, I want to know the corporate incentives to adopting this "new" tech <:BlobYay:806132268186861619>

No idea. They don't have to give reasons, it's just clicking a checkbox in their settings 🙂

ohh, i thought at least some of them would've posted or communicated about it or something

anyway, still great numbers

that is a surprisingly high number of palemoon usage xD

Basilisk 2,374 0.00%

so basically JXL images are almost entirely served to Safari, and usually the mobile one

Waterfox 2,817 0.00%

it's total number of requests tho, so if every Palemoon user saw a total of say 10 images that's 3000 people. If they got more images than that, it's even fewer people.

Here's the top "browsers" _not_ having image/jxl in the Accept headers: Chrome 2,574,088,266 17.39% Chrome Mobile 1,247,689,372 8.43% Mobile Safari UI/WKWebView 1,089,589,664 7.36% Mozilla 739,952,529 5.00% Edge 607,373,972 4.10% Mobile Safari 564,490,648 3.81% Android 541,269,236 3.66% Firefox 334,544,421 2.26% Safari 290,444,942 1.96% Chrome Mobile WebView 258,302,222 1.74% App 207,736,179 1.40% Bytespider 191,633,822 1.29% Samsung Internet 180,777,403 1.22% Facebook 178,610,359 1.21% HeadlessChrome 161,579,167 1.09%

one reason would be webdev against web-accessible test sites and serving their own content to their own desktop and mobile apps. analytic suites can give odd numbers for a number of reasons, like a web service being accessible **only** through its own app (analytic scripts arent only included in websites)

still quite a bit of Safari that either hasn't upgraded yet, or I guess is making image requests in a way that doesn't send the right Accept headers (e.g. fetching via javascript will not send the Accept headers for images, I suppose)

Some websites that are using Cloudinary and are delivering quite a few jxl images: https://www.aroma-zone.com/ https://www.truereligion.com/ https://www.aritzia.com/ https://www.luisaviaroma.com/ https://fcbayern.com/ https://suitsupply.com/

https://www.gents.se/ https://www.thescore.com/ https://gp1tickets.com/

it's quite fun to be able to run queries against a huge amount of CDN logs

Is there an incentive for customers to enable JXL? Like, are they billed on aggregate traffic or something?

It's a bit complicated — in the current pricing model, they pay for bandwidth but also for number of encodes and for storage of the encoded images. In the new simplified pricing model (that we're only just beginning to roll out), they'll pay per view and it becomes our problem to make the trade-off between bandwidth and spending cpu/storage on making more variants.

that makes sense

I suppose that means if a site is say predominantly apple, you could, in theory, choose not to serve avif at all to that site, if a site is more chrome/android not serve jxl, and a healthy mix serve both?

why does this sound like an infection

“I got a particularly recalcitrant JPEG XL from wget”

Looks like a quote from crocodile dundjee(xl)

Is this true? https://www.instagram.com/trentsizemore/p/C5CyizDrP2G/

Found this: https://engineering.fb.com/2024/03/26/android/instagram-threads-hdr-photos/ But they did not mention JPEG XL/AVIF or high bit depth, only HDR. At least in text, I did not listen to podcast.

afaik its actually ancient jpg combined with a gainmap, which google calls jpeg-r despite being an 'extend' of jpg or ultrahdr

I don't have Instagram app, so I can't test if JXL is uploadable

try saving any 'ultrahdr' with a really low quality and youll realize its actually trash even though hdr data is added - no better than regular jpg

jpg takes a lot of storage and even though a gainmap doesnt add a lot, jxl should consistently generate such photos at half the filesize and higher quality too

the big win for the ecosystem is that like on iphones since a few models, android now *stores* hdr data so it should be easy for camera apps to generate images from that in jxl or avif. previously iphones didnt display hdr intent even if it was captured and screen could show it

anyway social apps cant viably serve massive and share 10+ megabyte jpgs unless they capture it themselves and gainmaps are unreliable and result in mismatch after even just small metadata changes, nevermind image manipulations on the original file more complex than crop, resize, rename

https://gregbenzphotography.com/hdr-photos/instagram-now-supports-hdr-photos/ Here is mentioned that HEIC and AVIF uploads are supported via Instagram app (not website). Maybe JXL is also supported then, at least in iOS?

unconfirmed but facebook allegedly allowed jxl upload 2 years before. keeping up with adoption is a pain cuz its usually not disclosed or passively obtained from devs updating their builds of image libraries they already use like ffmpeg. snapcraft and flathub are completely untracked too

Got an Unsupported Format error when trying to use a JXL on Android, so need someone on IOS to test

test what? if its a website, use cromite for images, theres a 3rdparty build of fossify gallery with a 5min patch integrated

Did you use the latest version of the app?

No updates available

So it's not supported. A shame

odd jon reported it worked 2 years ago. try again with a jpg converted to jxl, stored as contained instead of naked codestream. through website - afaik the apps do some silent preprocessing so they need formats supported in fresco

Thought I'd ask if anyone knew of C# OpenImageIO bindings or other image libraries with one. Trying to find an excuse to get JXLs into VR :P https://github.com/Yellow-Dog-Man/Resonite-Issues/issues/1562

JXL upload worked fine for me ~1 year ago on Facebook Desktop, haven't tested recently

JXL compressed DNGs are now supported https://github.com/LibRaw/LibRaw/commit/12b0e5d60c57bb795382fda8494fc45f683550b8

Now we just need to wait a year for a new release... And then for applications to update their libraries 🥲

We are ata good point

https://www.phoronix.com/news/Linux-Mint-22-March-2024

hopefully the package pulled from debian is fresher. debian's many derivatives are stuck on 0.7.0

It's ok. 0.7 is more stable!

Honestly it's kind of dangerous how fast they're updating things. Would be safer if they used 0.6 or 0.5 and just backported security fixes themselves during packaging

That's the only way, if you're a serious, server OS

I always disable updates on my system for maximum stability, personally.

The more years out of date everything is, the more stable the system

When is out for beta?

Yes 0,6 is the best

I Unlocked a new image

Strange how much time 6 days I stayed to do This when aomedia would be faster than me

As I shown could expect

Improved fast speed avif jxl is worse

Wrong channel again

Aomedia learned by Trucks

I working on de-ringing e5-e9

https://opensource.googleblog.com/2024/04/introducing-jpegli-new-jpeg-coding-library.html

but <:Thonk:805904896879493180> https://github.com/libjxl/jpegli need some redirection

fixed 😛

Doesn't bit depth of 10 bit break backwards compatibility with current jpeg implementations?

no no

it's still a regular jpeg

if SW dev has taught me anything it's that there will always be at least one implementation that does things incorrectly, even for basic stuff

how does it work?

https://www.rxddit.com/r/Android/comments/1bux9se/introducing_jpegli_a_new_jpeg_coding_library/kxxdtuu/

xnviewMP added support for Jpegli encoder in 1.7.1 if anyone wanna check

xnview mp also now works in Wayland I just noticed

had issues with that for a long time

Lightroom on iOS export in jxl with hdr support (hdr gain I guess) And a iOS itself pretty well understand that jxl files

I wonder is JXL can use Jpegli to increase it's own adoption. Like "hey, this is Jpegli encoder and it even comes with JXL encoding for free" 😄

coverage needs more depth and actual live demonstrations from users with notable gains made for jpg->jxl conversions, i presume having the original jpgs generated properly using jpegli would result in higher quality more visually pleasing final jxls but some conversion tools could mess their own integrations

maybe adoption should track integration quality. many convertors dont use lossless transcoding from jpg so not only do conversions take time but also either lose detail or result in huge lossless jxls. enthusiasts would expect the main selling points of jxl to be consistent gains and be surprised when they arent realized or oddly way less efficient than supposed to be

I agree, this would help everyone to make a good first impression.

Yes, that seems like the obvious path forward to me.

But it isn't really promoted much.

For example, not even libjxl uses it!

For some inexplicable, incomprehensible reason, libjxl REQUIRES headers from libjpeg-turbo in the third party folder in order to properly compile. You can't even tell it to use system-installed headers like you can with brotli/gtest/hwy/lcms2

Even though libjxl already comes with an AMAZING and capable libjpeg, it laughably refuses to use it and requires libjpeg-turbo instead

One thing that would help with jpegxl adoption, would be if the libjxl build system were modified to make it easier to build multiple versions of libjpeg at the same time. API level 62 and 80, for instance. Those are the most popular.

Then it would be easy to install it as a drop-in systemwide replacement for libjpeg.

if there's anything that'd help its adoption is having less complicated build system or at least a version that can be easily embedded without having to deal with monstrous c++ build systems

There are static builds that you can use

I meant adoption among software developers, C++ build systems are an incomprehensible mess, there are a bunch of dependencies and builds are only available for some platforms

updated adoption in progress for Telegram (currently flathub, snap, desktop, likely all apps and website soon). seems theyre updating libjxl from 0.8.2 to 0.10.2 and also swapping out mozjpeg to jpegli

IIRC, that's because it doesn't just use its headers, it uses its headers' templates, so that it can do its own substitutions

system-installed libjpeg-turbo doesn't have it

Most of the time, codec libraries are written in C with minimal dependencies. Like opus, zstd, brotli etc

With the intent of having the absolute minimum amount of barriers for the maximum number of projects to adopt it

Heck even libaom

I was pretty surprised that libjxl doesn't follow the same pattern

Since it's written in C++ it should be possible to incrementally reduce its dependence on C++ over time and simplify its build process

Incrementally reducing the use of C++ features until it's just plain C

literally negative value work

if you have a C compiler, you have a C++ compiler

Definitely not true

it's not like there is no value in this, but Im not sure *how much* value there is in this

true of 100% of platforms that you might want to use libjxl on

it's really not, C++ has a light of hidden headaches that cause issues that greatly hinder portability

even embedded devs working with 8 bit microcontrollers use C++ these days

*some*

pashifox and c++

dude SHUT UP

I have an extreme dislike of C++, but what's the point of re-writing a complex library in C?

I would rather stick stick a toothpick under my toenail and kick a wall then do embedded c++ work lol

that being said, you probably would find more benefit to just doing a decoder/simple encode in whatever language you need. a lot of times you don't really need all the bits and bobs

you would find more benefit not caring about the language people are using

I think there are bigger, more important low hanging fruit that should be done first, but in the long term, there is a reason why literally every other codec library is not written in C++

hey people, calm down 😉

NO

we do the right thing and migrate to the lord language the one and only crablang

idk, it's just with jxl there is much higher barrier to entry, for example opus I had 0 problems building for all platforms and adding to project but with jxl I had trouble figuring out how to build even for windows (since I'm not using visual studio and the build guide is for visual studio only as far as I can tell)

~~time to add meson support to libjxl~~

and that has nothing to do with the language

I didn't say it had anything to do with it

that's something we could improve, maybe open an issue? it is not because of c++ though, nowadays that's a problem mostly only on weird microcontrollers 😛

mostly the build process is complicated

I like language ecosystems that officially provide build tooling, rust, go, dart/flutter etc

uhh BLOAT

who wants to help me re-write libjxl in Rust let's goooo

someone already did

actually I've already said that I might port the jpegli decoder code to Rust

not sure about quality of it

Yeah, there are more important low hanging fruit to worry about than what language it's written in. Like always reporting error conditions instead of invoking undefined behavior or aborting

no, that's an independent implementation of jxl decoding. Quality is very good from what I've seen.

I just think simplifying build process would greatly help with adoption among developers

developers dont even need to build it

i dont think that's a real issue

one of these days I'm gonna get a CHERI computer, and I'll compile with options that turn 99% of UB into aborts and it'll be great.

write up what difficulties you ran into in an issue? thanks 🙂

if we port it to C first we can do c2rust like rav1d

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

what if you want to use it on platforms for which there are no binaries

then you dont use it

then that platform doesnt matter

:p

Ideally you just have a `libjxl.a` archive you can just link

I do think that a high quality, performant Rust decoder (and encoder, eventually) would be great to have 🙂

jxl-oxide seems pretty great!

How is jxl-oxide?

the greatest issue I had was I think highway or rust refused to statically compile for android and I spent half a day pfaffing about with that

it's mostly there in terms of perf, it's still behind for sure, but its more then usable

not fast enough yet 😛

well, last time I checked

pretty sure it uses more memory too

it seems to be faster then libjxl for me on a very specific set of jpeg->jxl images ill see if I can find them again

that's a bit surprising (but definitely welcome)

Ideally you would cross-compile an archive?

also Rust doesn't (yet) have a good highway equivalent, which makes performance portability harder

I think I would use the not yet final portable SIMD thingy, accepting that it won't be as widely usable as it could be until that's done (and maybe provide valuable feedback about it before stabilzation)

rust is old news, it's all about zig now

Shouldn't something like libhwy be ideally built into the language primitives?

well, the *biggest* issue with rust is the lack of a good rust native cms crate

There is the crappy one Firefox uses

That's probably the best one

well I did say good [av1_dogelol](https://cdn.discordapp.com/emojis/867794291652558888.webp?size=48&quality=lossless&name=av1_dogelol)

I think that is being increasingly off-topic

that also doesn't help xD but you don't *need* to use one...

ok so here's the todo list: * port good cms code to rust * port jpegli to rust * get some good SIMD thiny going * port libjxl to rust

Zig? I heard zig is pretty cool B)

and then some new hip language is going to come along and youre going to say port it to that

(I may or may not be doing something abut 3 😉 )

c++ is good because it's actually standard

and not some fad

jxl-oxide is still very slow in comparison, even wic jxl (winthumb) has gone from something useful to something completely unusable for me because slow

I hate rust

I always hated it from day 1

ok

I had some prototype code for that as well, but no definitive design to further develop on

I'm eager to hear more

that must be a rough life to live mate

i hate rust and rust users

I couldn't find any information on how to build for windows without visual studio or msys2 (just clang/cmake/c++ build tools installed), I guess this isn't a big problem for most people since you would expect most people having it but that was one thing, I also couldn't make crosscompilation from windows work in any way, no matter what I tried it didn't work but I tried quite some time ago so I don't remember what exactly were problems; I didn't have any problems with opus for example, it was very easy, but it's also much smaller and had no dependencies

It's just C++

tfw every new GPU driver in Linux is written in Rust but actually it's just a fad version of C++

I hate everyone equally.

Rust allows you to guarantee memory safety at compile time, which is *great* for adoption - avoids people requesting sandboxing, avoids people complaining about safety, and avoids things like the libwebp bug which was found after 8+ years

unsafe

uses of unsafe can be proven safe

once I try again if I run into any issue I'll write it up I guess

speed wise jxl-winthumb should be faster after v0.2.4, when was the last time you tried it?

thanks 🙂

I just put it away a while ago specifically because I couldn't make build work but now that I'm focused on it I'll eventually need to build it for other platforms

it's not functional so it's immediately not safe

also honestly people complain about Rust being complex but I find Rust codebases much easier to understand than anything moderately complex in C or C++. Much easier to contribute to a Rust project without accidentally fucking up some invariant somewhere.

Rust would be cool... if it was trying to replace C instead of C++. If it were trying to be as simple and portable as C so it could actually replace C.

ah here is one where I found jxl-oxide to be marginally faster, Mind you I think jxl-oxide is compiled with more optimal settings, but it's hard to do a 1:1, both use cpu=native though ```ps ➜ Pictures hyperfine --runs 2 'djxl ina4k-no.jxl --disable_output' 'jxl-oxide decode --num-threads 12 ina4k-no.jxl' Benchmark 1: djxl ina4k-no.jxl --disable_output Time (mean ± σ): 531.0 ms ± 21.9 ms [User: 5549.8 ms, System: 76.4 ms] Range (min … max): 515.5 ms … 546.4 ms 2 runs Benchmark 2: jxl-oxide decode --num-threads 12 ina4k-no.jxl Time (mean ± σ): 405.5 ms ± 4.8 ms [User: 3687.9 ms, System: 75.6 ms] Range (min … max): 402.1 ms … 408.9 ms 2 runs Summary jxl-oxide decode --num-threads 12 ina4k-no.jxl ran 1.31 ± 0.06 times faster than djxl ina4k-no.jxl --disable_output ```

But they aren't trying to replace C sadly, and C does need to be replaced...

Rust replaces both C and CPP in a LOT of use cases

And it would be a lot easier than trying to make yet another C++

keep in mind the only thing rust really needs to replace C is nostd, force that everywhere and you are pretty much there

It would be an easier and more-needed task to replace C than C++. That's the whole reason why people got excited over zig

the main thing I've seen Zig people say they dislike about Rust is the safety features

unfortunately untrue - llvm *is* a limitation since it doesn't quite support all the architectures

the argument being that constraining the programmer makes their work slower

yeah typscript was also a fad

and I don't think rustc-codegen-gcc is quite there yet

faster, but still not fast enough for large and lossless images, because for some even libjxl speed isn't quite enough, but if it's something even slower, it goes from being somewhat not enjoyable to almost impossible to use

not yet, but it is getting close, and ofc gccrs will come eventually

the gcc stuff + something like [eyra](https://github.com/sunfishcode/eyra) will eventually wind up covering a large basis

that line of reasoning IMO is fairly dangerous

The main complaint is not safety features, it's that it's hard to learn, slow and not portable.

programmers are bad at doing the right thing, it's half the reason we have types 😛

Zig is not more portable, nor faster. And idk I found Rust easy to learn?

hard to learn I can agree with, slow to compile possibly too, but not portable?

although tbh it's not *that* hard to learn

it's 50:50

Well, compared to C... I'm not that familiar with Zig but I heard it's popular with C programmers since it is compatible with C and comes with a C build system

on all of the points, I personally really don't like zig, and took to rust almost immediately, but I know many people who are the opposite, cant take to rust at all, but zig was almost instant

not 100% but it is at least complete enough to compile Linux Rust code. I think language-feature wise it's pretty complete, but backend completeness isn't great. E.g. it only has SIMD for x86-64 at the moment.

I haven't tried Zig yet, but their target audience seems to be C devs...

my mental model of Zig is "better C(++?)", which IMO not quite what we truly need

cargo has some really silly debugging defaults. you can compile debug rust much faster by doing things like incremental=false using cranelift, using mold for linking etc.

We do need to replace C though, we have been needing a good replacement for decades now?

Zig is C with fewer outright footguns, but with no safety guarantees, and a pretty nice compile time code feature.

Zig is a good short term solution, but IMO rust will wind up winning out, it simply has too much goodies.

C has some ways of doing things that could be made slightly better without shaking it up too much from its essential straightforwardness and simplicity

sure, but doing that doesn't save you from having memory safety vulnerabilities lurking for years 🙂

And of course more compile-time sanity checks are always great to have in a language

Compile time memory/thread management is a cool idea

but it's an entirely different language. Slightly-different but you still need to re-write doesn't seem like a huge win.

A very logical one

Well it's only a huge win if you get something really valuable out of it like static safety checks at compile time that guarantee no undefined behavior for example

I believe you are describing Rust 😉

Well rust would be great if it was as simple and had as many compilers as C does...

But that's just my opinion...

I also think simd data types and operators should be language primitives

shouldn't you be telling us about how Zig isn't good because it doesn't have many compilers? :p

Well I don't know much about zig... if it's not complicated then it's more likely people write more compilers for it, even a useless language like brainfuck

great for building though

the language itself is not stable enough to use though

<@179701849576833024> <@184373105588699137> if I were to try my hand at a CMS impl for Rust, do you have any thoughts on where to start? Would porting an existing library's code be the best bet?

So people DO like static guarantees after all :)

?

I think people would be more excited if Zig had more guarantees akin to rust

I really don't think safety is what's holding Rust back. Rather, it's the only thing it has going for it.

Little-cms is mostly C, it could be a really neat idea to try to c2rust it I guess, but personally I would do it from scratch, then you can use things like glam's vector handling for better SIMD support

it definitely is better C, not C++, it's great for building personal C/C++ projects though since it's also a build system

for context, rav1d is c2rust of dav1d and it worked fairly well for them

and a much more sane one at that compared to most

then I'll need to do a lot of reading up on CMSes 🙂

imo it's probably worth it, note that color handling is a pretty complicated process, especially when you get to tone and gamut mapping, but you can find a lot of stuff here to get started http://www.brucelindbloom.com/

CMSes are complex though

porting lcms might be a good idea, idk

porting lcms would probably be the "fastest" way to get a good cms, it might not be the best way, since it requires a lot of unsafe -> safe workand initial debugging, but it could work fine

yeah I have heard that they are quite complex, so porting has a lower likelihood of being too much

https://github.com/kornelski/rust-lcms2

Wrapper

https://github.com/immunant/c2rust

I don't see what's the problem with just linking a C lib into rust

lcms2 is supposed to be pretty damn good

If you want a pure rust one, here's a possible starting point... https://github.com/FirefoxGraphics/qcms

It does not support a lot of features

it's better when to use native rust when possible because you get the safety gurantees right through, that being said at the very least `rust-lcms2-sys` compiles lcms2 statically using the cargo build system so you don;t have build issues there

https://github.com/kornelski/rust-lcms2-sys/blob/main/src/build.rs

How does it compile static C on Linux? glibc does not support static linking, so it probably uses musl?

Actually, does rust support static linking on Linux?

yes

actually I ran into a funny problem with both Rust and Zig: both build systems assume(d) that if you're using Musl, you're doing static linking 🙂

I heard that musl has excellent performance when paired with mimalloc

if you want a gnu target to get static you need `-C target-feature=-crt-static`

eyra cant come soon enough

glibc itself can't be statically linked, but obviously all the other C libraries, like lcms2, can be statically linked.

musl supports dynamic linking, but I think it's less common since people normally use musl for the very reason that it supports static linking

many distros use musl

I don't want GNU anything

Tbph

personally I'm more likely to use S 'n' M alloc, which funnily enough is also a Microsoft open source project

unfortunately musl is still very much a second class citizen for a lot of things

I want to try using relibc to spin up a distro one day [av1_dogelol](https://cdn.discordapp.com/emojis/867794291652558888.webp?size=48&quality=lossless&name=av1_dogelol)

It's unfortunate, glibc is basically the #1 source of compatibility problems on linux distros. I expect there will be less and less reason for glibc to stay relevant... musl is better at everything except the builtin simple malloc implementation is slow... but easy to replace with something faster than glibc

compat issues due to glibc sounds unlikely

unless you're compiling against a newer version and try to run on an older version

(musl is also like that FWIW)

I run into old stuff all the time that can't be run on new versions of glibc

Like Total War Shogun 2

At this point not only is musl better at everything and smaller and simpler, it's even more compatible now too, since at least musl just works

glibc is just pain

Red Hat pain

musl literally breaks compat more often than glibc

musl is less flexible in feature set and performance, unforunately it's not a true replacement for glibc

meanwhile I've run 20+ year old copies of blender without issue on modern linux

I do want to replace glibc though, we really should be using a meory safe libc

When was the last and only time? Time64?

you can say that. firefox still does not support icc v4 to this day and bases their misleading announcement of its support since v108 on a flawed test they never replaced

all blink/chromium/webkit based browsers are xyb-decode capable in compareason. same for almost all android/ios galleries i tried, oddly on windows theres tons of apps with no color management or disabled by default - decades old defaults that were never revisited perhaps

When you replace the simple malloc with a real malloc like mimalloc, the performance gap completely vanishes.

I've tried many alloc solutions and non have been able to do so sadly

Why do xyb jpegs look okay in firefox for me? Does it just "look" like it passes?

I haven't tested it myself but I looked at several benchmarks from different people and organizations, which show glibc has no advantage after malloc is swapped out

note that musl's memcpy is also terrible

I didn't see a significant difference in perf in the memcpy benchmarks I saw

try displaying this image in any app youre interested checking (browsers, galleries, thumbnailers, editors) https://littlecms.com/img/blog/stress.jpg

The benchmarks I have seen show that after replacing malloc, glibc is often slower at various complex tasks

if supported, no white lines or yellow text should be visible

Yeah, I love these test images

My iphone 15 fails

At all of them

https://www.tweag.io/blog/2023-08-10-rust-static-link-with-mimalloc/

In this test, glibc was slower.

click the full preview, discord's thumbnailer oddly doesnt color correct and misleads

it doesn't work on my iPad

Bellsoft also published a bunch of benchmarks

however, all the text is blue, unlike on Firefox and Discord where the colors varied

Yeah not even the image gallery works

It's like there is zero support

for color profiles

afaik v4 is supposed to work in safari and does here but i guess it works differently there or incomplete

there's definitely support for color profiles...

just not 100% complete V4 support

compiled jxl-oxide with eyra and posted the results in jxl-oxide, but I'm kinda surprised since it actually just worked

Anyways... glibc performance is overblown. What do you expect from an ancient and unreadable, insane spaghetti mess? If you compare how the same functions are implemented in glibc vs musl you will wonder how glibc is able to functionally do anything at all, let alone how anyone is even able to read it to hack on it

It looks like obfuscated code

both are bad, rust rewrite when

My iPhone can't even load the most basic tests.

it should display *something*

if it doesn't your phone is broken

webkit L?

what iOS version are you on?

this hurts my eyes

Whatever version is on my iphone 15

17.whatever

im on 17.whatever

I was pretty surprised that it can't even do such basic tests even the laughingstock Firefox is able to pass

well nothing uses icc 4 so whatever

Anyone able to see this? Or does my phone even upload it incorrectly?

This is v2 lol

This isn't even v4

oh i meant for this

on my destop ff

https://littlecms.com/img/blog/check_full.jpg

Here's the link

what do you mean by "able to see"? I see text saying that it isn't working, when looking at it in Discord, and text saying it works when looking at it in Firefox, and text saying it sorta works when I use my iPad.

For some reason it looks different to me than my direct upload

Does it look different than the link version?

I suspect it might get mangled after I save it to apple's photo gallery

Just curious if it is how it should "correctly" look?

That's how the v4 test should look

no

For me it does. Weird.

interesting

A perfect result

Seemingly

https://littlecms.com/blog/2020/09/09/browser-check/

It's a great place to test

Testing is safe and affordable! Get tested today!

I used to have old libjxl-based jxl-winthumb installed, but I purged almost all Explorer extensions when explorer.exe started to crash intermittently.

I do wonder if JXL will make it into Windows 11 24H2

the old one still works, I don't have any issues

So do I 👀

eventually when ms' raw addon integrates jxl decoding from adobe's dng 1.7 sdk freshly updated by libraw. WIC activity suggests itll come through a store addon like with webp and av1 but no decoder leaked so far

I thought it was moved to the system32 codec pack, suggesting it will be a core codec?

Yeah

Unfortunately libraw only releases once every year and a half, so it'll be quite a wait...

just my guess, either way is fine as long as it decodes out of the box. i presumed its possible theyd go for a store codec to more widely deploy for machines not running the latest win10/11 release

I'm hoping they backport to Windows 10, otherwise I might finally have a reason to update :P

Chrome codec lead Jim Bankowski: But don't you know there's no ecosystem interest?!?!!?!???!

since JXL is now out of IANA's provisional list onto the main one maybe someone could get it added to nginx's default `mime.types` config? https://nginx.org/en/docs/contributing_changes.html

isn’t the open-source community switching to freenginx?

https://www.phoronix.com/news/Nginx-Forked-To-Freenginx

https://arstechnica.com/information-technology/2024/02/nginx-key-developer-starts-a-freenginx-fork-after-dispute-with-parent-firm/

i think we need to give it some time before we adopt it

why? it’s the same codebase, by someone who had been working on it quite a bit until then