JPEG XL

why favour the F5-owned version?

here's the equivalent contributing page for freenginx: https://freenginx.org/en/docs/contributing_changes.html

ah, the comments on ars technica seem to contain some interesting insight

That's rare

On arstechnica the comments are most of the time of high quality... Except when they aren't

there are some issues with jpegli, but also <:monkaMega:809252622900789269> https://github.com/telegramdesktop/tdesktop/pull/27734

<https://github.com/libjxl/libjxl/issues/3486> <https://github.com/libjxl/libjxl/issues/3487>

There's still a lot of bugs and yet people are mass adopting it already. Even the alpha bug still happens on optimised PNGs for some reason

if chromium had jxl out of the box cloudflare would happily ditch generating and serving avif the following month. till now they still have to generate webps because the cost of generating and serving avif is too brutal even for them

perhaps ever rising energy costs could be leveraged for compares in domestic use and cloud. like, how many images can you process to final output given a certain energy budget/full battery life, or how much itd cost you to convert a billion images

quasi-instant jpg->jxl would turn heads compared to full conversions sacrificing either quality (lossy) or bloating filesize (lossless)

Then throw in the cost of thumbnail generation vs progressively loading a partial JXL file too

not long ago it recall someone did test for generating an album's thumbnails in multiple formats and the results for avif were ridiculously bad - like the difference between max 2 seconds each to 35secs... couldnt find it again

I keep hearing that, but none of the web browsers support that.

JPEG XL if you read <#805176455658733570> other bugs are in

And there is an article jpeg xl and the use case that explains in which phase is libjxl

I made a fresh patch for chrome: https://chromium-review.googlesource.com/c/chromium/src/+/5454316 so that chromium based browsers can use it. Please let the developers of those browsers know, and let me how we can support them...

<:PepeHands:808829977608323112>

https://github.com/telegramdesktop/tdesktop/issues/27765

So they had to release v4.16.8 as soon as possible

already, I mean, it's sad that switching to jpegli has been reverted

It's inevitable if they can't resolve the crashing issue

<https://github.com/desktop-app/patches/pull/192>

😱 This is bad publicity

I've been using Telegram longer than Discord and that's pretty bad news

<:smileywithcrossedarms:1088561504430850118>

I'm sure it will be fixed. Proper handling of all error conditions is the last major thing we need for libjxl 1.0, and it looks like jpegli has some problems with error handling too but they'll probably be dealt with too.

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

telegram should also have made some more test before releasing with such a change

The pace of updating minor versions of Desktop is much more frequent than iOS, Android and macOS clients

you can test on a branch an merge to production only when ready

They should've used pre-releases however

Yeah, running in Beta for a while would've been wise

They've published pre-releases many times but I don't know why they didn't this time

maybe some commercial support focused on maximizing adoption and guaranteeing big implementors like cdns and image hosts end with working efficient implementations that can serve as demonstrators? troublesome when early adopter candidates backpedal at the first errors employees have no idea or way to urgently fix

I am worried that jpegxl has a very serious and substantial chance of simply... not getting adopted by other software projects, because the library aborts instead of detecting and signalling error conditions, and because it's a pain in the ass to compile.

Luckily I think the situation is getting better and it could be worse...

it's a pain in the ass to compile <:WhatThe:806133036059197491>

I haven't had issues...

Compared to other codec libraries.

It is a lot more complicated than every other image/video/sound/compression codec library and adds a lot of complexity to the build system of any potential project that wants to adopt libjxl

Also probably the only one that requires signing a CLA

the process for building other codecs: 1. download code 2. run the build system setup commands 3. run the build system compile commands the process for building libjxl: 1. download code 2. run the build system setup commands 3. run the build system compile commands

I guess some SW doesn't need the setup commands, but it's not a big deal to run a script to fetch everything you need

If you don't see any difference between libjxl and literally every other codec library in terms of complexity of the build process then idk what to tell ya

I regularly compile libaom, SVT-AV1, rav1e, vvenc, and libjxl (all without using ports/AUR), and the worst one of them *by far* is vvenc

I have to patch the cmake file every time because it just installs to the build directory, but other than that, they're all pretty much the same

anyway if you have something akin to FreeBSD's ports or AUR support on Linux, neither is difficult as long as there's a maintained port/script

maybe, but from a legal perspective, it could be necessary... that said if it's just fixing a typo, it probably doesn't have a MR and thus there's no need to sign the CLA

Paint.net filetype plugin guy have given up on updating libjxl because API is too unstable. He's waiting for 1.0. My guess that it's not the only case.

How often breaking changes gonna happen after 1.0? If new major versions would appear every quarter, that would be bad news for everyone.

there was one major change, streaming support in 0.10 and it's like after a few years bad api or being stuck on an old limited api is much worse than some changes or updates and it doesn't happen that often

help needed then? contributors familiar with jxl could update the code in his place

Nice idea! I think this would be the most effective way to spread the gospel

Even if I would be unable to help given my lame proficiency in C++

<:Hypers:808826266060193874> https://github.com/telegramdesktop/tdesktop/commit/bea715b41c2155796949f4b35f9fbba0e83eeb7f

but still not for windows <:PepeSad:815718285877444619>

anyone familiar with debian packaging? debian and all derivatives have been stuck at 0.7 since forever. kinda bad for adoption since it has massive reach and downstream derivatives lack the expertise to do more than use what debian hands them down

debian experimental is at 0.8.2

experimental is a dev branch (used like but not equivalent to actual rolling releases) and should normally be consistently close to upstream to get issues fixed soonest. derivatives like ubuntu and its downstreams are based on the branches shipping 0.7 (stable and unstable as indicated above)

above tracker is not exhaustive or consistently correct on an aside. mx linux releases since 21 testing (now 23.2) are at 0.7.0

lmao

what is a debian?

When I look in the dictionary I get a picture of a bag of manure labeled "100% stable!"

ask them what version of firefox are they on

Does anyone know why this patch is broken if used in modern Firefox? https://codeberg.org/librewolf/source/src/branch/main/patches/JXL_improved_support.patch It seems to work in Waterfox (115 ESR) and the patch was basically ported from Waterfox. It breaks compiling in 125. I can't find any mention of those two in Firefox 115 ESR using searchfox, and the only mention for Waterfox from the commit the patch is based off of

just use my build

Here's Waterfox vs Firefox 125 with basic JXL support The patch enables transparency and animations, and well they work in Waterfox so I know it works for them

What's your build? ~~I forked Firefox for more than just JXL~~

https://grass.moe/firefox/

I'd publish the updated patch for jxl but lazy/nobody asked

gimme

<:nachocutepls:907420002527887421>

gonna have to wait a week

~~Also firefox is MPL, so not providing source means they could go after you~~

umm akshually

not sure what the full extent of compiling being broken is however someone posted a patch in a comment here that apparently fixes one of the issues (no clue if there are other issues) https://bugzilla.mozilla.org/show_bug.cgi?id=1709814#c5

<:yay1:1097749673780973588> it works now

However it seems the JPEG XL Webkit image example is broken now where the logo was visible before

if you have an sRGB screen, then the logo should not be visible. If it is visible on an sRGB screen, it's because no proper color management is done. The jxl should look the same as the others.

idk if my screen is sRGB, but I can see it in the previous example here Waterfox has the same patch and it's invisible there too

I can't force it to be visible playing with contrast or curves or anything so I assume it's the patch

pre patch vs post patch

All visible on Safari

<:RengeShrug:1147646888791777413>

I guess Firefox sucks at drawing color and fixing JPEG XL made it work more proper?

Since if it's all the same in Safari, and now all the same in Firefox that would make sense

My display is applied with its own ICC profile and it's 10-bit (8-bit + FRC)

I just use stock whatever

I was going to have a 10 bit display but acer fucking lied about that

Or it requires additional settings as well as newer HDMI or DisplayPort

No, they like later just removed all mention from the listing and I've tried multiple GPUs and shit

Mine is from ASUS and it's claimed to be sRGB 100% and DCI-P3 90%

Hmm maybe it's also Windows color rendering being ass because I just tried Thorium and saw the same

firefox uses qcms which doesn't support more than 8bpc afaik

Heh, my 98% DCI-P3 monitor also just shows red in Chrome/Edge and Windows thumbnails, but works fine in Imageglass <:thinkies:854271204411572236>

Funnily enough even Discord seems to work

https://jpegxl.info/test-page/Webkit-logo-P3.png

Hmm, yeah

It shows in Discord

huh

Wonder if it's because it's always compressed in Discord and the compression brings the color out

That is it, because it just disappears with my zoom plugin

yeah, stripping or ignoring the icc profile would cause the logo to emerge even on an sRGB screen

<:Think2:826218556453945364>

Of course this should work on macOS well

That icon is WebKit

Finally tried IacobIonut01/Gallery for jxl files, but it doesn't really support "Gallery" part of the gallery app, and opening pics manually just shows gray gradient/blur. Image Toolbox opens them just fine, so images are not corrupted.

just tried it and it doesnt work at all for me, just a black screen

https://github.com/T8RIN/ImageToolbox/releases/tag/2.8.0

Also I tested it on my JPG photos, 20% reduction seems exactly right, down to the last percent. I can't wait until it apps catch up so I can actually use it.

That wonderful, but I'm kinda wary of the "212 commits behind" message.

yeah, if I find the motivation. I wanted to publish to lib on maven but the procedure seems ... complicated

Huh

Visible on the thumbnail

As soon as I focus they disappear

is there any android viewer that supports hdr jxl

So randomly I was testing some things out on a M1 MacBook Pro with an HDR (Liquid Retina XDR, blah, blah, blah). Preview app displays HDR JXL without the HDR. As does Safari as far as I can tell. Photos app displays them correctly. I thought I was going crazy. 3rd party on the Mac: Pixelmator Pro displays correctly (and has some fun tools to work with – but no export yet). Affinity Photo 2 seems to display ok, but the files it exports as HDR don't display as HDR in Pixelmator Pro. Going to be interesting getting all this sorted out.

HDR makes sense for full-screen viewing, but in windowed mode (especially for thumbnails) a lot of them would be either completely black, or mini-Suns. Eyes can't accommodate if UI have different light level from image.

No, that's not true. You just need to define the white level of the SDR parts properly. The current standardization seems to be converging to putting SDR white at a nominal 203 nits (where the HDR content typically goes to a nominal 1000 nits in HLG and typically 1000-4000 nits in PQ).

so the UI white more or less corresponds to a diffuse white like a blank sheet of paper, and SDR images look like images printed on that paper would look like (can't get brighter than the paper itself), while HDR images can get brighter than the paper. But it can still be a reasonably pleasant combination.

but if you have a 400 nits white hdr on the screen and your eyes adapt to it, the sdr will start to look too dark

And yes, <@594623456415449088> , I have the same experience on my MacBook Pro. Only some applications are capable of rendering HDR images in HDR — and Safari is not one of them yet, at least not still images (for video, it can actually render in HDR)

yeah, I’ve seen HDR images casually embedded in an Element (Matrix) discussion window, and it often makes the SDR white suddenly look dull

it’s a weird experience

“is it the same brightness as before?”

adaptation is a funny thing — this is also why phones typically change their brightness according to ambient light

designing websites or other visual experiences with a combination of SDR and HDR elements will certainly be non-trivial, and I expect we'll see quite a bit of pages overusing/abusing HDR, that will in a few years look like those flashy pages from the 90s full of animated gifs and marquee/blinking text

There should be software analog of ambient light compensation, only for UI instead of IRL light.

I like that. If I have a dark mode interface, you cannot put too bright images in it — small highlights are ok but not large bright areas

this is part of proper color/tonemapping that is rarely done, android now does it

not really talking about this, but many of the points apply https://www.youtube.com/watch?v=bYS-P2bF2TQ

it's almost like we should stay with sdr

no, we should hard shift to pq

SDR is a mess still, srgb, dcip3 all of these specs have different "nominal" peak brightnesses, but unlike PQ, these are all suggestions is (1,1,1) graded for 80 nits? 120 nits? or 203 nits? literally no one knows. also you have srgb vs pure gamma 2.2 which is it's own can of bees

and video is bt.709, which should be treated as gamma 2.4 but only if your display has perfect blacks (see bt.1886)

HDR would be great if it weren't for all the headache of support issues around it

absolute nits make sense in a controlled environment like a movie theater, but I don't think it makes that much sense when the viewing conditions are variable (like a home environment / outdoors)

grading for absolute nits gives us a common baseline, even if we need it to be more flexible for outside or indoors, we can always take absolute nits and expand it up and down. an absolute nit system still allows us to derive a relative system from it while giving us a hard constant in which we can use to be a guiding factor. This is just a little useful on its own, but where it really comes into shine is when you have additional information. Say you're on a computer, while the computer can inform you whether the application is a game, a media player, a web browser, so on and so forth. When we mix an absolute knit system with this additional metadata, it gives the compositor a lot of flexibility and knowledge in how to properly map everything so it's cohesive with itself.

We can say, okay, this frame wants 1,000 nits, which we know we need to tome map down to display a side by side with other content.On the other hand, if you use just a realitive nit system, like most SDR-based transfers, then you have kind of a wild west. You can only make a best guess at how much you should tone map one thing to another, and this causes very sub par results

Yeah, I have to say when an HDR images is properly displayed on a great monitor, it's breathtaking. The interface does look dull when the image is up, but it only takes seconds to look normal again once the image is gone. EDR mode on the Mac might be making things weird too. If it's fully turned on in an app, it's using any monitor's extra headroom (i.e. if you don't have it turned up to max brightness - even on an non-HDR display) to display the HDR portion of images. I just don't think it's turned on in many places yet – and hard to know what's really happening. Also looks like some of the apps may not be interpreting the HDR color profiles properly.

i thought EDR only worked on built-in displays in some macbooks as apple knows how those are calibrated

EDR's definitely a flex for apple's vertical integration

You might be right. Referenced in this video: https://developer.apple.com/wwdc21/10161?time=327 "EDR's adaptation provides a number of benefits. Perhaps most surprisingly, this results in EDR creating a true HDR response, even on conventional, standard dynamic range displays." But in the chart, they only mention 'typical' HDR10 displays.

I got among my first impressions of HDR by setting an SDR monitor to max brightness (about 400 nits iirc), tonemapping HDR videos (https://youtu.be/aFp6w4eL2gE, https://youtu.be/BRqyaZiq_LA) to that, and displaying the result fullscreen

so it wasn't a crazy idea!

I did the same with a 400 nits display then a 1000 nits OLED and decided HDR is a meme

it's not terrible but the low end can really suffer when you do that. that being said, it's not like there are loads of great HDR content, and the good HDR content that is out there looks good on SDR too

the takeaway was that HDR type content doesn't need to be "HDR"

and then I realized HDR is just a transfer function and they decided to also put it on the display side when they didn't need to

which consequently makes everything incompatible so they can sell more tvs

aside from no longer having control over brightness

what about 10bit and wide gamut

Apple already doing that with sdr

Apple was right once again

isn't sdr defined as 8bit and rec708

can what you are referring to really be called sdr?

8-bit sRGB is for me the prototypical SDR

if it's not HDR transfer

then...

then it still might not be sdr?

would wide gamut 10bit be a bigger DR than SDR?

precision and range are not the same thing, and gamut is a bit of an orthogonal issue — you can have grayscale HDR and a very wide gamut with a narrow dynamic range

but obviously a bigger range requires more precision if you want to avoid banding, and so does a wide gamut

SDR is typically something like 0.5 to 200 nits, so 7 stops of dynamic range or so

arguably, they kind of did – if you just use a relative 0-1 range and scale everything linearly as with SDR, it doesn’t really scale well, say, from a 300-nit monitor to a 1600-nit one

I don't think there's a clear boundary between SDR and HDR, but I'd say you need at least 10 stops to call it HDR

you can get away with it if the target environment is well controlled, as with cinema > In traditional imaging, the range allocated to these highlights was fairly low and the majority of the image range was allocated to the diffuse reflective regions of objects. For example, in hardcopy print the highlights would be 1.1x higher luminance than the diffuse white maximum. In traditional video, the highlights were generally set to be no higher than 1.25x the diffuse white. Of the various display applications, cinema allocated the highest range to the highlights, up to 2.7x the diffuse white. — https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.2390-11-2023-PDF-E.pdf

but not really if you’re netflix and sending content for everyone to watch on their phones, tablets, computers and TVs

I don't really get why Netflix is using PQ and not HLG — the way I understand it, PQ is more suitable for controlled environments (like cinema) while HLG is more suitable for unknown/variable viewing conditions.

I've sort of detached the literal meaning "high dynamic range" from the name HDR. To me HDR just refers to some standards that are packaged together to form the next standard for video that can go beyond the limitations of SDR (8 bit, not wide enough gamut).

Dolby Vision and HDR10+ attempt to address this; maybe Netflix is using one of them

yeah I think of HDR as having any HDR transfer function

seems like it (https://help.netflix.com/node/13444 )

So in that sense I do think of 10-bit and wide gamut as "part of" HDR

Even if they can exist independently of achieving high dynamic range

you need the "HDR" transfer to retain enough detail at the low end of the spectrum when you start dealing with anything above 1k nits. sRGB/gamma2.2 just barely retains enough detail to make it usable at those brightness ranges

no you just need hbd

perhaps if you are working with 16bit+ but for 10bit it's not enough

Hdr is also 10 bit for that reason

then again, they can make some transfer that's good for that for sdr

12bit might be getting close to the good enough range I suppose

And I think 2.2 or whatever is already made to track with eye

changing the transfer isn't going to flat help detail or banding or whatever

hdr one seemingly is just for light

with gamma 2.2 you don't have enough steps to make dark colours smooth without doing some real funky color hackery unless you are well over 10bit, as I said, maybe 12bit could be usable with a 2.2 transfer.

proof

you can say that about anything

just make the whole thing brighter

details in the dark for that long is just going to make eyes adapt and appear bright

stop cranking your contrast

stupid best buy tv display effect

PQ is more efficient. Also, on an HDR display, PQ vs HLG makes basically no difference usually, content is tonemapped to display peak the same way. And there are more displays supporting PQ than those supporting HLG, because UHD Blu-rays are everywhere, while HLG TV is much more rare.

ew no

disgusting

you shouldnt have to blind yourself to enjoy HDR

im talking about your dark colors thing

you dont want to encourage creators to do stupid shit like maxing the contrast

what do they attempt to address...

No. You can have 12 bit wide gamut SDR content.

yes i will not read the entire conversation

That's true for SDR movies in the cinema for example.

They absolutely needed to do that, displays before that had no concept of absolute brightness.

bro

yup, even setting aside the more data alloted in darks by PQ, having an absolute transfer function alone is a massive step in the right direction

absolute transfer is not it because of ergonomics

<:av1_KannaWhat:654080962233106432>

something exact lighting conditions

something brightness slider

it's like having atmos only audio

absolute transfer function just means that as per spec, each value has a set reference nit value of 1.0 - 0.10000, unlike hlg, and all SDR transfers I know of, where brightness is a 0.0 - 1.0

yeah but what's the point

I see I have mixed up many terms. Sorry

it gives a solid value of reference when you need to scale and mix different content. it also is a proper guide because PQ is not dependant on the display technology. when grading an image for say sRGB, if you grade your image for peak of 120nits it will look fine on "most displays". but on other displays, the brightness levels will look off, especially if you are on a 400 nit display. it's pretty common to see banding on content graded at lower nits, especially if you grade for 80nits per srgb spec

PQ on the otherhand will never have that issue unless it's a mastering issue because 400 nits is 400nits, 200 nits is 200 nits etc. we always have the proper intended nit peak so we will be able to handle scaling it properly

Displays (or compositors) will always have the information needed to adequately be able to handle it which is a massive step in the right direction

the grading thing is superficial. dark things are still dark

yeah that example is bullshit

it is true that humans are contextual beings, but images(or videos) do get graded for specific references brightnesses, and this often causes banding. a good example is looking at images graded for CRTs with a nit peak of 80 on modern displays of 400 nits or greater, they look like shit

bring the brightness down on the display and they look fine

and humans grade t hem

and?

it doesnt matter how bright the display theyre grading them on

thats just plain wrong lmao

there is a reason why a big part of doing a color grading setup involves setting even your environment to a proper brightness

yeah and it's only for ergonomics

I gotta be getting trolled lmao

PQ is specifically optimized to minimize banding across the entire 0 - 10k nits range, and at 12 bits per pixel there should be no visible difference between adjacent code values anymore (see https://www.color.org/hdr/04-Timo_Kunkel.pdf, specifically slide 17) on the other hand, HLG is designed to be backwards compatible with BT.2020, i.e. it should still look normal on a display using BT.2020 primaries and regular ~2.4 gamma since (limited) backwards compatibility is the main selling point of HLG, it makes more sense to deliver proper BT.709 to SDR displays and BT.2100+PQ to HDR displays (the fact that PQ uses absolute luminance is kind of its own can of worms, but most TVs nowadays have modes that overbrighten PQ content to compensate for ambient light)

I guess PQ vs HLG doesn't really matter if displays are not taking the absolute nits from PQ literally anyway. What I like about HLG is that it is defined relative to SDR brightness, so compositing HLG with SDR content makes more sense. But it doesn't really matter if in practice PQ gets interpreted as "203 nits is SDR white" where the actual brightness of SDR white can still be adjusted by display brightness settings / ambient light compensation.

that PQ doesn’t specify exactly how to tone-map content with a higher peak than the display is capable of

DV gives content creators some control over the tonemapping

as well as an automated mode that analyses the content ahead of time, yielding metadata that can guide the tone mapping

dynamic metadata (can change from scene to scene)

Dolby Vision and HDR10+ don't eiter, to my knowledge. They just provide more information, that potentially improve tonemapping quality.

all that per-scene metadata

Often only the dynamic peak metadata is used.

But if you're in a dark room on a good display, the other dynamic metadata isn't needed anyway...

AFAIK, at least DV does

it lets you manually adjust how the tone-mapped version should look

that would be a bit pointless if it didn’t actually do that

hmm, interesting, wonder if that's just a recommendatation, though...

manual adjustments require a $2500 yearly licence, though

the free version gets you only the automatic analysis

interesting

(which might be good enough)

I'm pretty sure HDR10+ does not specify how the metadata should influence tonemapping...

although there are a couple of recommendations

That plot on slide 17 is interesting indeed

It would be interesting to add the XYB tf to this, for various quantization choices (e.g. the DC quant step of libjxl d1 with max_intensity 1000 nits)

(it would also be helpful to show the curve for 8-bit sRGB, for both its nominal luminance range and the actual luminance range of current SDR displays)

superimposing an actual plot might be annoying but we can compute a few points of interest by hand

for example, middle grey (about 18%) is (118, 118, 118) in sRGB, giving Y=18.1164 according to `transicc -i '*sRGB' -o '*XYZ'`

the neighbouring (117, 117, 117) and (119, 119, 119) have Y = 17.7888 and 18.4475 respectively

that’s a step of roughly 1.8% at 14 nits (80-nit sRGB) or 54.3 nits (300-nit sRGB)

Remembered that message and just tried it... Wow, surprised how well it worked, especially if I used my monitor's poor viewing angles to 'dim' the backlight bleed too. Actually looked better than my phone's 'real' HDR (Still not convinced it actually works)

idk enough about how jxl works, but i tried to recreate their plot in python and think i got close enough (not sure why the gamma doesn't match exactly, no power i tried was an exact match)

the code, if anyone wants to try hacking on it (shoutouts to chatgpt for helping with the plot setup)

Nice!

when using modular XYB, the quantization factor for luma (before doing any further lossy quantization e.g. by quantizing squeeze residuals) is currently 2048, so that makes the Y effectively 11-bit at an intensity_target of 255 nits — if the intensity target is higher, it will keep the same precision in the SDR part but just go to higher values. So I think that would look something like this:

this is with the current libjxl, this PR https://github.com/libjxl/libjxl/pull/3563 is proposing to use 12-bit luma in modular XYB (before any additional requantization) — it is very much an encoder choice what kind of precision you want there so the above lines are by no means inherent to XYB, it's just the current libjxl choice when doing lossy modular

Was checking OIIO again and noticed this <https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/4252/files/694ecfe5055b6ffb916dfe7e79ff893817e0fdd9#diff-9c6a890053a7ddcbea694adbfec0197954afe3c25e114314dfa25ce630a68269R1272> > * - ``jpegxl:speed`` > - int > - Sets the encoding speed tier for the provided options. Minimum is 0 > (slowest to encode, best quality/density), and maximum is 4 (fastest to > encode, at the cost of some quality/density). Default is 0. > (Note: in libjxl it named JXL_ENC_FRAME_SETTING_DECODING_SPEED. But it > is about encoding speed and compression quality, not decoding speed.)

I mean... It's not *technically* wrong, since it limits the encoding options used to speed up decoding

But still feels like an odd way to word it, may lead to people using it instead of effort when they shouldn't

explanation can be confusing indeed. 0 is generating jxls the normal way, other values generate images in a way to maximize their decoding speed but at sacrifice of compression efficiency (unpredictably larger final filesize but jxl still prioritizes maintaining the visual quality matching the selected effort)

Especially lately the fast decode settings can cause exponentially larger files, 5x larger https://discord.com/channels/794206087879852103/804324493420920833/1232814800891805786

Some time ago I asked author of desktop background switcher I use to add jxl, and today he released new version with jxl support <:BlobYay:806132268186861619> https://johnsad.ventures/software/backgroundswitcher/johns-background-switcher-5-8-release-notes/

Amazing! I won't change my wallpaper though. Uniform pure black has my preference

I use my photos of nature

I haven't checked if macOS Sonoma supports JXL as wallpapers

Looks like it does. The wallpaper does not show HDR images in HDR though (not in any format so that's not JXL specific — same with Preview and Safari, only Photos shows HDR images in HDR it seems)

imagine a peak hdr brightness wallpaper with sdr apps on top

Yeah I wouldn't even want to have a bright sdr wallpaper, but still, could be fun to have e.g. a sunset with deep superreds as a wallpaper

I hear KDE's SDR on HDR is decent

Correclty mapping SDR on HDR is really simple.

only thing questionable is target peak luminance

Any intelligent enhancements beyond that have high risk of making things worse for well-tonemapped SDR content.

is not so simple, its easy when you are just doing gamma2.2->PQ mapping. but when you are compositing with other things it becomes a headache.

just map everything onto PQ, then do the compositing (ideally in ICtCp), easy

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

Sony is asking the community what to add into their next generation cameras: https://twitter.com/SonyAlpha/status/1790759056187199561

Generating an ai image based on the photo you just captured would be rad, especially with some possibility to preserve faces

Could beat chip-level filtering and produce higher grade images even on normally weaker cameras

In other words you want AI denoising/upscaling

Not quite, thatd be just filtering. I meant using a local ondevice llm to generate new images based on the one you just captured, like if you submitted an SD prompt against a user-submitted reference image

that's filtering with extra steps

So you want the camera to capture an image that's vaguely similar to what you're pointing it at, but with random details missing and random things incorrect? Why would anyone want a camera like that?

Smartphones are doing almost this already. I. e. adding moon details, beautifying portraits, adding OOF blur, etc. And (almost) everyone is happy

https://news.artnet.com/art-world/bjorn-karmann-ai-camera-paragraphica-2313584

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

would be very dumb to do on-device

eh, tpus are getting cheap enough and small enough

I think it's unavoidable that all audio/visual material used as evidence will have to be reviewed by experts.

Provenance, integrity and fidelity will certainly become more important as it becomes easier and easier to tamper with media.

I remeber a solution proposed about embedding steganographical hashes which neat in theory.

Chromium just closed the jxl bug as won't fix

What do? Realistically no existing browser can overtake chrome

And recently apple ios europe users can install non webkit browsers...

big web services can bypass browsers' slow adoption pace of jxl if they have desktop or mobile apps

moreso if the *only* way to consume their content is through their own apps

imo other cdns need to be brought onboard since a huge part of their reach goes through mobile (mobile versions of websites, webview embeds)

Yeah i guess i'm underestimating how many people use apps vs webpages

pitch is easy. without any quality loss, your image-heavy site/app now loads faster than your desktop website stacked with jpegs

quicker loading progressive images would make content *and ads* load even snappier

in compareason, all image recompressions have one of 2 shortcomings

A: either quality is sacrificed with no guaranteed lower filesize than the original (reduce quality further to guarantee it)

you don't have to, just get most of the major players to support it, firefox would still be a big win, yes it's small in perentage, but it's still well over 170 000 000 users monthly

which is significant

B: conversion to lossless *massively* increases filesize (worse bloat if done from a lossy original). jxl is the only format that actually *guarantees* smaller filesize for a lossless conversion from a lossy source

preinstalls and integrations will take their time but imo its content that should be focused on

however way you have to view jxl is degraded if the content isnt distributed by creators, platforms, mobile apps, cdns

even if browsers dont natively decode jxl, the files should still be made available for **downloading** - if just for only a small percentage of or your most popular content - people mistakenly assume a conversion has to cover the totality of their content and with zero fallback

when jxl's reversible lossless jpg conversion is almost instant in both directions (all but efforts higher than 7 take less than 50 milliseconds here for sub-4k image resolutions and negligible cpu cycles). this would consume like x100 more energy per image if done using other formats and the cost of energy has significantly risen for consumers and datacenters

if youre running a barely balanced or even deficitary service, just the savings jxl enables could pull you into profitability

Just to mention - jpg.jxl decoding is much faster than original jpg, at least on my pc. For large images difference can be 3x-4x

thankfully, CDNs are distributing content, the issue is that the browser has to accept and decode the content to get it. A good example is when you download a image that is a `https://file.png` but it downloads to a webp, that's the server's proxy service working as intended. (This might actually be happening with some CDNs now even with apple devices, dont have one so can't check). the "biggest thing" that could realistically happen is either windows merges support and starts to default to JXL when possible, or firefox supports JXL which would make 2/3 major browser engines support it

Huge impact would be if iPhone camera app saves JXL instead HEIC.

I recon Apple put a lot of work into implementing HEIC and trimming their camera to the performance it has. So why would they switch, if it ain't broken don't fix it? This would likely be a enormous task for them, I don't think they are willing to do that especially right now?

Encoding performance might get them to take notice. The faster they can write a whack of images coming off the sensor, the better the specs on the phone look. If anything, it would be a nice option to chose over HEIC. I'd really love support to turn all my old JPEGs in Photos into XL's. I have a Photo Library that's 552GB. Over 24 GB are JPEGs. I could use a couple of those back. Also I should probably edit that sucker down.

the only thing stopping me from converting all the images on my phone to JXL is actually consuming them. currently on android, the gallery app I use aves is open source but the dev doesn't accept PRs lol.

If JXL is capable of Live Photos

Isn't the "Live" portion just a video?

Live Photos are just an image with a video, yeah

Although there may be some clever stuff with intra frames being used as heic images or something

Google seems reluctant, not just Chromium team, but company as a whole. Otherwise there would be at least some activity on Android side.

Isn't it more similar to animation? Live Photos lets users pick up any of images within it

but it's also a video with sound, so im guessing it might be a video with lots more intra (single self-contained) frames instead of Long-GOP

🙏

praying hard on that one honestly

It was already quite a shock to see them implement it in their OS

It's rather silly that a format that Google helped create is being used more by other companies than by Google themselves

As much as i don't like Apple, i'm so happy they support it now, because it means Google will be obliged to support it one way or the other eventually

Quite functional like other image formats although the Photo app doesn't label JPEG XL

Including this https://support.apple.com/guide/iphone/iph9b4106303/ios

Mozilla is pretty clear their stance is that jxl should not be added to browsers, according to their "neutrality" statement. If you read their actual statement, they say they think it should NOT be added to browsers but avif should be instead. They also refuse to merge simple bug fix pull requests that fix basic display bugs with transparency and animation and color profiles in firefox

They couldn't be any more clear and unambiguous that they intend to obstruct adoption on purpose, believing it to be the right thing to do.

It seems to me that they are paid by G. to do this and other things that can not be explained by any logic

It's pretty suspicious how completely mysterious and unaccountable their decision making process was and how lockstep it is with the decision of former On2 tech lead and current Chrome Codec Team lead Jim Bankowski

Almost like mozilla really doesn't want anyone to know what their decision making process even is for some reason

Just more "trust me bro. I... WE uh, 'discussed' this with uh, our uh, top experts and uh, industry partners and whatever, and they begged us not to include jpegxl. Trust me bro. I mean us. Trust us."

Same exact story from both mozilla and JB

What's that? Who are these industry experts we spoke with? I'm sorry I don't think I can hear your question. NEXT!

who exactly do you imagine that employees of a private company would be accountable to

Everyone wanting to know how they made such an unexpected decision that impacts everybody

I guess "private companies" if you can even call Google that, are supposed to be accountable to customers and shareholders and anyone else who gives them lots of money

Pretty sure Google's a branch of the CIA though 😂

I think, ultimately, it won't matter

a decoder can be written in wasm and distributed on any page that wants to display JXL

that's still really rough since it won't effect CDNs and wasm decoding is fairly slow and buggy

wasm in general is horribly supported for sending images and stuff

sure, but it might convince Google to add decoding when their browser is slower than <browser_x_that_implemented_jxl_here> on <some_major_site/CDN_here>

JXL is practically made with multithreading in mind, and WASM is... An experience, to get multithreading working

The problem with Chrome is that it is big enough so that if a website is slow due to Chrome being stupid, it will not be considered a problem of Chrome, but a problem of the website.

even with multithreading, wasm is just horribly implemented in both chrome and firefox

But to be fair - modern sites are often terrible. I saw sites where uMatrix shows hundreds in script counter, and disabling everything unnecessary speeds up loading by many times

I can picture a little section at the bottom of each website: "This site is 40% slower on Chrome. See why here!" And I'm not lawyer, but since they are now considered a gatekeeper in the Europe, if someone was willing, there may be a way to sue them into compliance. They're ranking web site speed based on flawed info. That has a direct affect on monetary outcomes of those sites.

I don't have Chrome in any of my devices

this banner would be a fun way to advertise against chrome 😄

i feel like firefox adoption & mozillas income would both get a big boost if they just sold like. a really good pair of fox ears headband

Afaik they are not even exploring the idea of becoming independent of Google

Google slaves forever

telegram desktop on Linux obviously uses jpegli, I saw following in the console: qt.gui.imageio.jpeg: ./lib/jpegli/decode_scan.cc:535: Incomplete scan detected.

yeah, would be nice to make it for windows as well, but jpegli still needs some fixes and also not that easy to compile as a standalone library for all platforms https://github.com/telegramdesktop/tdesktop/pull/27734

https://github.com/libjxl/libjxl/issues/created_by/ilya-fedin

yes

as we all know, this is Google's fault

browsers couldve been bypassed by working with web services' popular apps to facilitate their adoption of jxl inside their apps. big selling point for apps when mobile apps load the same content so much quicker than on desktop and mobile browsers, at some points browsers would need adopt it themselves since the jxl content would already be existing (generated initially for the mobile apps)

90% of web service's applications rely on system codecs

or webview codecs

thats just an optimisation. every library not present in reference systems is shipped by apps anyway

haha funny

most app devs would rather just pick their nose instead of doing extra work

using a redirection addon, you can force lemmy to serve jxl images to you

tested a couple instances, all worked

https://cdn.discordapp.com/attachments/719811866959806514/1245605285507104768/Redirector.json?ex=66595bd2&is=66580a52&hm=d13192a1d45e3715f31cadaaa80cab6bc56bdd5c98604c111aa42f31e1226a5a&

the redirector im using

I'm currently using mercury, but I'm very annoyed that it doesn't use any patches to fix the JXL bugs in firefox

Which firefox forks have less broken JXL support?

I just use waterfox

Does waterfox support animation and transparency?

https://jpegxl.info/test-page/

Did they fix the crash when displaying some jxls?

I don't want to waste time installing it unless I know for sure that it doesn't have those embarrassing bugs that were still never fixed upstream

yes and it has since late 2022

Good. Looks like I have no choice but to switch since no other firefox fork has such basic fixes

waterfox, floorp (and its derivatives - soon to rebase from upstream ESR to regular stable) support jxl well, including the jxl art with glowing morphing text. heard mercury wasnt all that yet

Jpegli is used on Windows too, there's just no commit for some reason. The subsampling changed from 4:2:0 to 4:4:4 (jpegli's default) around the same time as Linux switched

strange, because there are only changes for linux version, if that's true, then jpegli should be used for decoding as well if there are any obvious signs for jpegli decoding on some images, i think it would be easy to check

Confirm. No subsampling when sending photos via Telegram on Windows

Apple for some reason still doesn’t support animations

What glowing morphing text

I believe that Telegram Desktop on Linux has libjxl 0.10.2 + jpegli. jpegli is visible in Telegram binary. But on Windows, libjxl 0.8.2, no jpegli. "mozjpeg version 4.1.5 (build 20240313)" is visible inside Telegram.exe

From https://jpegxl.info/art/, demonstrating animation and splines. Basic support for the format is a given but wether jxl art handles well sets apps apart since conformance is only tested for some decoders and not the integrations

Nope

If you're on Windows, r3dfox is based off of latest and should be as similarly optimized as Mercury

https://www.eclipse.cx/projects/r3dfox

Hoping this is the correct place for this... does modern FF Dev Edition support JXL? I see it in the accept headers yet when I set the image type to that, it freaks out and never loads it...

nope, only ever worked in Nightly and not since touched by Mozilla

ff dev is the beta with extras. jxl is only built *by mozilla* in nightlies (the flag works only there). if you use 3rdparty builds, they can have that support available in other channels - for example fedora has firefox-jxl in COPR that adds jxl support in stable firefox and replaces the repo's firefox release, and you could find Floorp more interesting (floorp and its derivatives is currently based on ESR but soon rebasing on the regular stable)

someone should rebase and re-submit so we can get a fresh ~~excuse~~ reason

Only helps a little, I use dev edition and it's sending the accept JXL header to sites... but refuses to load them... I need to make sure that this is just my issue or I will have to make some funny user agent detection before serving the correct format from my backend

I would recommend disabling the flag in non-nightly Firefox, it breaks many sites.

only Firefox nightly has decoding support compiled in which is why nothing is loading because the browser is saying it supports JXL but can't actually decode it

is the flag enabled by default, if so... that's <:abyss:794689002061299782>

idr if I enabled it or not lol

No, it's not enabled by default

if only it were possible to support it via a plugin

oh wow, there is one? <:FeelsAmazingMan:808826295768449054>

looks a bit out of date <:Thonk:805904896879493180>

it doesn't matter, its wasm so it's brutally slow

Okular on Windows should be able to open JXL https://cdn.kde.org/ci-builds/graphics/okular/release-24.05/windows/

143 Mo ! Qt is so lean and beautiful

mega octets

Octet is a word in English too and it's not a bad word to use when talking about 8 bits. Byte is not a word in French. If it were, it would probably be pronounced like the French slang word "bite" (which means penis), and I imagine something like "megabyte" would have strange connotations to native French speakers..

I didn't even noticed my frenglishism here 😅

megabi/yte goes almost unnoticed in the everyday vocabulary in french... but it still make chuckle those under 12 years old 😄

for me it's especially strange and funny that that word is female — ce n'est pas mon bite, c'est ma bite qui est mega

does it make more sense if you tend to speak to it ?

It was my mistake, I was thinking in french, I should have said Mb

Gendered nouns don't make much sense to me in general, it's a good thing English got rid of that. It's a major headache for those trying to learn French or German to have to know the gender of every noun, especially when it's not particularly logical like "la bite". Dutch is somewhere between German and English in this regard: male and female words are indistinguishable (no "der" and "die" or "le" and "la" but just "de" for both, like English has "the" for both), but Dutch still does have neuter words (like the German "das", there is "het").

you have just a distinction between with and without gender ? convenient indeed. I'm afraid this tendency to gender object comes from latin... It will be hard to get rid off. French people would say you just have to learn, that there is no logic, but they never learned it, they don't know 😄 I once found a site like this : https://frenchtogether.com/french-nouns-gender/ which gives some 80/20 rules to get genders right

actually, you should've said MB, Mb is megabit!

(what is french for bit?)

you are right ! "bit", since with use "octet" in good french. I may be a word imported directly from english though... (hypothesis confirmed by the wiktionary)

Things different from one's primary language generally tend to be subjectively "not make sense".

Slavonic languages: hold my beer 😅 Every noun has gender, but no help words (der, die) to determine it, and at the same time you must know it to use all other sentence parts correctly

native French speaker here; doesn’t make sense to me either

I envy English

Try Swedish. Instead of three genders (masculine, feminine, neither) we have two (either, neither), which makes even less sense.

I even don't know what is correct translation of our "third" gender 🤔 Direct translation is "middle" but idk

English is like 30-40% French, but it's still much worse <:YEP:808828808127971399>

have you heard of ULTRAFRENCH? https://www.reddit.com/r/badlinguistics/comments/34mous/sanskrit_discussion_in_rlinguistics/cqwk5lw/

(let’s maybe move this to <#806898911091753051>)

Let me introduce you to Finnish where nouns have no gender and there are even no gendered pronouns 🙂

so it's kind-of a RISC of the languages 🙂

The introduction of my language grammar: "The language almost entirely lacks inflection; words typically have only one grammatical form." So simple

does Cloudinary pick JXL automatically when using `f_auto`?

Depends on the user settings. Currently not by default, only when the user has opted in to allowing jxl as one of the f_auto formats.

this looks to have stalled, unfortunately: https://projects.blender.org/blender/blender/pulls/118989 <:FeelsSadMan:808221433243107338>

I've been checking on it every week. They made 2 PRs, and both times never made any progress after a few days of comments

OIIO did get more of the JXL features implemented after those draft PRs too, so now it can actually encode 8bit int instead of only float. So it'd probably need a new PR anyway, or wait for even more PRs OIIO side

Is there any information about Windows adopting JXL in the future?

Other than registry entries and an SDK, nothing new as far as I know

in the meantime jxl_winthumb.dll is as good as it's gunna get

Is the <:JXL:805850130203934781> API stable yet? Mozilla is using it as an excuse to not include it: https://www.rxddit.com/r/firefox/comments/1de7bu1/were_the_firefox_leadership_team_at_mozilla_ama/l8h74g0/

Didn't Jon say elsewhere in that very thread that the decode API is stable

literally in reply to that post lol

The last message in <#822105409312653333> even

oh, whoops, hadn't scrolled down far enough

interesting that so far there are only 🦗 noises in response to wb's post

Bitstream and specification are fixed stable with longterm forward compatibility, decoder was essentially "1.0" since like 2 years. Its just the encoder and decoder have the same versioning instead of the decoder being versioned separately.

except it isnt

so it's all fail

To be honest, I've seen sentiments towards libjxl not being considered mature until 1.0 release outside Firefox.

Yeah me too, we should get a 1.0 out just for those who think version numbers magically make software more or less mature.

Firefox added avif support in 2021. Libavif v1.0 was released in August 2023. Chrome added webp support in 2011. Libwebp v1.0 was released in April 2018. I get the point about wanting a v1.0 release before integrating something, it makes sense, but it feels like this argument is being used somewhat selectively.

I think finishing of the aborts would be a perfect v1.0 release :D

See also: <https://0ver.org>

just version it by a single number or the date

anything else is just roleplaying

Firefox did not use libavif. They made their own implentation of AVIF by extending their MP4 parser.

Did they give that a version number? 🙂

A French humorist said people marry once they have nothing more to discuss about so they have something again to speak of the rest of their days... You may publish a 1.0 when the jxl is trending downward to relaunch the communication around it...

and it still took them how long to support animated avif? [av1_kekw](https://cdn.discordapp.com/emojis/758892021191934033.webp?size=48&quality=lossless&name=av1_kekw)

This is how it look in the beginning: https://hg.mozilla.org/integration/autoland/rev/9804951497f9 Not too much code added, because AV1 decoder was already available.

They were obviously busy with other things.

the answer is about 2 and 3/4ths a year and then some after that to enable it lmao

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

I think there was some controversy about whether avif was supposed to allow arbitrary av1 payloads or not (i.e. all kinds of inter frames too, which would not be needed for just still images)

I think there was a little bit, but that would have been resolved far before firefox added support

https://aomediacodec.github.io/av1-avif/v1.0.0.html this version of the spec still has intra-only animations

While the current version removed that constraint to intra-only: https://aomediacodec.github.io/av1-avif/v1.1.0.html

The date on the first avif spec that allows full av1 payloads is 15 April 2022

That's about half a year after the first Firefox release with avif support

was v1.0.0 intra only? I must have missed that, where does it say it? i'll have to re-read it

I am assuming that `still_picture` implies intra only

ah I see, as far as I remeber `still_picture` means that the sequence only has 1 frame so I suppose the avis would be a bunch of single temporal units. However you still need to decode it as you would a video itself since it's still the typical sequence of units as far as demuxing is concerned

I think [Hmm](https://cdn.discordapp.com/emojis/1113499891314991275.webp?size=48&quality=lossless&name=Hmm)

Mozilla implementation of JPEG XL when??

mozilla made rust so does that count?

jxl-oxide 1.0 when??? /joke

I wonder how this ISO draft for Adaptive HDR metadata could apply to JXL https://developer.apple.com/videos/play/wwdc2024/10177/

:( “ISO” is meant to be pronounced as a word (“iso”), not as “I, S, O”

it’s not an initialism

Yeah it is?

Also "eisou" sounds a lot like I,S,O anyways

no, that’s a common misconception https://www.iso.org/about#:~:text=Many%20languages%2C%20one,are%20always%20ISO%2E

also heard at 1:03 in https://youtu.be/N6ZLzzAZ_nQ?t=1m3s

It's kind of weird how every single standard nowadays needs to advertise how the standard helps advance Agenda 21 or whatever the Davos Group or WEF calls it nowadays

(sorry, I originally pointed to the wrong moment in the video)

ISO does use the backronym International Standardization Organization nowadays, but yes, it's originally from the Greek prefix iso-, and was a compromise between the French and English ways, which would be IOS and OIS or something I guess

If it's not an acronym why is it spelled with uppercase letters?

maybe so that all letters are equal, too

You vill be happy

?