JPEG XL

All the gain maps lately make me wonder how different things could be if they had adopted JXL a little sooner, seems like everyone has agreed on a workaround right as a real solution is here

JXL doesn't have a solution for gain maps, traditional HDR and gainmaps are pretty much two seperate things. Gain maps give you a very "close to traditional HDR" experience while also being fully compatible with SDR, which is not something you can do with a transfer function + tone mapping. you are simply missing the required data

dog whistle

Yeah. I wanted to see how he'd explain it. He has posted and "explained" several dog whistles in the past.

How's it a dog whistle if that guy is pretty famous for saying that lol

I was pretty sure you guys would get the joke

Is it considered a "dog whistle" now to make fun of WEF and Klaus Schwab?

Wow shame on me, I'm gunna cry in the corner now :(

If you guys want to take a break from "um, yikes"-ing about state-enforced letter capitalization, then check this out: After adding support for MPEG1, H.264, Opus, modern compression methods, and much more, the chad Rasky mentioned he could (and might) add JXL support to the N64 console via the FOSS SDK he's now lead developer of called LibDragon.

I played with libdragon a bit, it's neat, could be nice to have

I'm really interested to see initial and then optimized benchmarks. Most JXL features wouldn't be useful in this context, I think. But, I'm suspecting that the frames/layers could be leveraged somehow.

it could be neat to make custom roms that have the kinda dynamic resolution stuff

partially decoded textures for n64, and on emulators that use higher rendering resolutions have the full 4k or 8k or whatever textures

Are you a part of the N64 Homebrew Discord?

nope

I don't really do homebrew stuff since like, gba

I still tinker every now and then, but only as far as examples

It might be useful to have your input on these matters.

I wouldn't even know if it would be possible on libdragon to do something like that

I think a lot of the members don't. They're just there to see what's going on. I don't code or do any development, right now. But, I sometimes ask questions or give input anyways.

From what I've seen, it may not be out of the realm of possibility. The only issue is just getting X feature to run on hardware.

well, ill check it out eventually

It'd be cool to see you or any other JXL people there. It's been really amazing seeing new developments almost literally every day. Some of the tech demos are pretty awe-inspiring. Like, the guy who was working on Portal 64 did a successful implementation of John Carmack's megatextures running on real hardware, as just one recent example.

Yeah, it's a feature that allows HDR images to be displayed and scaled appropriately on monitors with different amounts of headroom or brightness settings... From the sound of it, it seems like a pretty essential feature and Apple is even trying to get it to be part of the ICC standard. Which is funny considering how their devices utterly bomb these tests: https://littlecms.com/blog/2020/09/09/browser-check/

oh no, not more ICC fuckery

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

https://www.iso.org/standard/86775.html

this is gonna cause some headaches lol

We are adding a box for gain maps, it will be discussed at the upcoming JPEG meeting. I am in favor of this, if only just for feature parity. But fundamentally, I don't like the idea of essentially having the option that the SDR image and the HDR image are potentially very different — I am more in favor of standardizing tone mapping with some parameters for artistic control, and having only one master image at the highest fidelity from which the renderings on less-capable displays are automatically derived.

Gain maps might be nice from the point of having artistic control over delivered images, but for a processing pipeline it is a nightmare. Cropping and rescaling is still doable, but what does it even mean to apply operations like sharpening or color adjustments on an image that is really two images?

i agree and think that makes sense, although i am not very knowledgable in this field. it does seem more sensible to have a system for converting HDR to SDR from the image, instead of having 2 images that create one.

There are many tone mapping algorithms to go from HDR to SDR — from simple global curves to fancy local tone mapping. Some of them are available in the libjxl repo, and the libjxl decode API does implement some of it if you request to get an HDR image at a lower max_nits than the image.

what's your opinion on HLG gamma curve as a backwards compatible solution?

The issue with tone mapping algorithms is that they might make artistically 'wrong' decisions, which is why gain maps can bring an advantage since they can spell out the exact way a local tone mapping has to be done. But realistically, I think very few people will actually generate custom gain maps, and instead they'll use whatever algorithm their software is implementing — so we're spending bytes on encoding the result of an algorithm, as opposed to just signaling "use this algorithm".

i guess there's no harm in supporting gain maps, although aren't they already an option by using another channel?

HLG does define a generic tone mapping that takes display brightness and ambient light into account, which is both more and less good than what you can do with gain maps. Gain maps cannot take ambient light into account, but HLG only defines a global tone mapping.

We could simply define an extra channel (or multiple, in case of 3-channel gain maps) to represent gain maps, but we're going for the separate codestream in a separate box approach, which makes it easier to add/change/strip gain maps. The idea is that in JXL, gain maps would mainly be used in the inverse direction, i.e. the main JXL image is an HDR image, and the gain map only describes a local tone mapping for rendering a nice SDR image — so it is in a way not really needed, and the 'real image' is just the main image. This is different from how it is done in JPEG (UltraHDR) or iPhone HEICs, where the main image is an SDR image and the gain map is needed to reconstruct the HDR image. Though the gain map spec TC 42 is working on will allow both directions, and so will JXL.

oh, so hdr will act sort of like JPEG bitstream reconstruction

Gain maps remind me of this feature of PNG to store a palette (and even a histogram that goes with it) in a truecolor PNG. This dates back to the time when many displays could only render 256 colors (or even less), so displaying a truecolor image often required reducing the colors and doing dithering and all that. So these PNG chunks for palette/histogram were useful since a viewer could use them to render the image more efficiently: instead of doing its own 'pngquant'-like thing, they could just directly use the signaled palette. Though I think most software would just ignore the signaled palette and do its own thing anyway, since that needed to be implemented anyway. So basically it ended up being a rather useless chunk that just takes up extra bytes without anything really doing anything with it. Once HDR displays become more common, I think gain maps might become something similar.

The whole concept of spelling out explicitly in an image file how to render an image on a device that is not fully capable of rendering the image is just not a very good idea imo. You could also start adding auxiliary images to have a custom 16-shade grayscale image included for e-readers, or custom local mappings to CMYK for printing the image, or low-framerate versions of animations, etc etc. I think it will only add bloat and be likely to not be used anyway, since there will always have to be a generic rendering implemented too for such devices, and in terms of code plumbing it will generally be highly nontrivial to have such custom "bypass the generic thing and use this custom thing instead" methods.

The internal colorspace used in lossy JXL is general enough to represent anything human eyes can see — it's not based on current display technology, it's based on the limits of the human visual system. I very much like the concept of having image files that just represent the visual information with the highest possible fidelity (gamut, dynamic range, precision only limited by the capturing technology, the limits of human vision, and when doing lossy also the amount of acceptable distortion in the anticipated range of viewing conditions), and then it is up to the rendering technology to figure out the best way to reproduce the 'ideal' image with whatever limited means it has to render images — although I am not opposed to having some signaled info for high-level artistic control over how trade-offs should ideally be made (e.g. like the rendering intent field in ICC profiles, but possibly with some parameters and preferably with normatively defined behavior so there is consistency between implementations).

To me, gain maps go too far in the direction of just storing two separate images (an SDR one and an HDR one). If you have a 3-channel, full-resolution gain map, you can effectively make the two images completely unrelated. If you only have a 1-channel, heavily downsampled gain map (as is now done in UltraHDR and iPhone's HDR HEICs), then this comes at a cost in fidelity, at least if the main image is SDR. Either way, SDR+gainmap is a less-than-ideal way to do HDR, and I think the only reason they're doing it is to have "graceful degradation" (i.e. it "works" in non-HDR-aware applications, which will just end up ignoring the gainmap). But in my experience, graceful degradation usually ends up paying bytes and mostly getting only the degraded experience in practice, since the incentive to upgrade software is too small (it already "works", so mostly they won't even realize they need to do something).

I agree--it's better to just store them as 2 separate images (or as separate channels in a single image)

if you want a single image that displays well in both SDR and HDR, allow storing some tone mapping parameters/metadata to show how to convert, but that's it

with over 4K channels it seems like there's little reason to flag something specifically as a gain map when you could just store an already computed image there

*.ico files support all that

I suppose it was a transition era

ICO is pretty much what you do if you cannot get SVG to render nicely to small dimensions, so you just store several rasterized versions. It's like raster fonts. Maybe justifiable when there is not enough compute oomph available to do something better, but that era is decades in the past.

The Haiku Vector Icon Format supports selectively adding or removing details at different sizes. Each shape has two parameters for this, "min LOD" and "max LOD".

Very little compute oomph needed

it also becomes less necessary as screens get so dense that even small physical sizes can render plenty of detail

I'm not a fan of the implementation either, but at this point In time, We really don't have anything else. And we do need something pretty much now. It's been a long time coming in creatives have wanted something really anything to give them real solution and game maps is the only thing that's actually viable cropped up.

Thankfully, at most it will be a pain because it will either stick around and tools will develop for it or it will die off and you'll have to use a special tool to convert it. But once the conversion is done, it's done.

and ofc, its only really a stop-gap until HDR actually takes off

Arguably, HDR has already taken off. Linux is lagging behind, software support in general is still rather flimsy, and obviously many computer screens currently out there are still SDR, but for TVs HDR is already the norm, and the same is true for recent Apple devices, high-end phones, monitors for gamers, and high-end monitors in general.

What do you mean by "we don't have anything else"? Basically every image format except for webp can just represent HDR images directly. Gain maps are mostly a way to encode > 8-bit using an 8-bit image + an 8-bit gain map (kind of like Radiance's RGBE), but even JPEG in 8-bit mode actually has enough precision to do HDR, and certainly JPEG 2000, HEIC, AVIF, JXL can just store a HDR image directly. The other reason for doing it the gain maps way is to make it "work" on legacy software that does everything with 8-bit buffers (of course it doesn't really work, you only get an SDR image, but at least that SDR image looks OK), but to me that seems like a strategy that will delay the push to get everything HDR-ready rather than accellerate it.

True HDR monitors are still expensive, unfortunately.

Even my "HDR" monitor is merely 120% sRGB.

That's gamut though, not dynamic range.

I'm still not convinced my phone is HDR and isn't just boosting saturation and setting brightness to max

the issue is that legacy software and legacy displays are still king, around 25% of all android devices which are "mobile and tablet" are still android 10 or lower according to apilevels.com which pulls froms statcounter, as of april 27th. Windows 11 still doesn't have good support for HDR globally, firefox has zero support etc. SDR is still massively important, and needs to be a first class citizen, it cannot be a second class one. currently as a creator you have three options, you either distribute both SDR and HDR separately, which most at least that I deal with simply won't do. even mastering aside, the actual delivery of images in this regard is just too great a hassle for many. you serve just HDR and treat a large majority of people as second class citiziens. keep in mind that android only actually got good SDR/HDR interop in A13 as A12 support was mediocre at best and relied on subpar tone mapping, A13 accounts for less then half of current android users. or they just serve SDR, which is what most creators do. Software is still a massive bottleneck, regardless of whether or not I agree about the state of HDR displays (many of the HDR displays are not even HDR400 compatible still). SDR will still need to be treated as a first class citizen for many years to come, Gain maps let creators treat both HDR and SDR consumers as first class citizens.

Hence HDR in quotes.

Windows 11 HDR experience is a joke. it's just *really bad*

HDR is a "general" term anyways, at minimum it should be treated as the transfer, however HDR generally means both a large range transfer as well as a large gamut

in the end HDR is just a bad marketing term

HDR isn't very widely deployed on Linux yet, but arguably, HDR is already better on Linux than on Windows. (Idk about MacOS). KDE has a good HDR implementation that first shipped on the Steam Deck OLED.

All that I got from that is that this monitor is supposed to have ~306 levels of sRGB.

even disregarding linux, because its safe to disregard, the state of HDR is poor

There's a reason for why it isn't widely deployed on Linux: Xorg does not support it, and many people want to stick to it because Wayland is still a mess, and then you get Wayland fanatics.

also it's not like HDR but not HDR displays are a *massive* issue, even on a bad HDR10 display, as long as the display handles it somewhat OK, HDR should still look decent enough, at least as good as SDR in most cases

Technically speaking you can do HDR with Xorg it just sucks a lot.

even when using a massively overcooked video like this one https://www.youtube.com/watch?v=pYt1TFQNi8Q HDR still looks more or less fine on my crappy LG HDR10 monitor

The solution on Wayland is to treat apps as sRGB by default and map that to the HDR output.

that's not a solution, thats a hack lol

wayland has no solution, wayland is totally treated as sRGB, whether the compositor does something special or not is up to the compositor

So legacy apps that expect sRGB should magically be HDR somehow??

there is *no* solution yet

That's not a hack that's just what you need to do to support old apps...

as in, no HDR at all

it just out right doesnt exist right now

There literally is though

KDE implements their own hacks

it's not a part of wayland

Those aren't "hacks"

yes it is, they use a vulkan layer shim to get the metadata and forward that to the compositor

There is no agreed upon standard yet, but you can literally do HDR today

thats about as hacky as it gets

*you* can do HDR, Wayland cannot

there is a very significant difference

also afaik only kwin can do it

*I* don't need to do anything. Apps that want to do HDR can do it that way and it'll work. If you're on KDE ;)

*some* apps can do it on KDE

what specifically do you think is wrong with it?

SDR apps look like crap, the default peak for HDR on windows is 1500 nits, (and is a wee bit of a pain to fix) and it also uses a fixed transfer that all applications have to map to, but they don't often map to

https://wiki.archlinux.org/title/KDE#HDR currently limited to vulkan applications

Yes

which granted, a good amount of HDR applications are vulkan aware, but that's still very limiting

for *wayland* to support HDR, there needs to be a protocol

Yeah. But that'd be the case literally no matter how it's solved. *Any* solution will require apps adding support.

there is a stark difference between "wayland" supporting it globally, and using a custom protocol and custom vulkan layer that ads support for just VK apps

Wayland can't support anything globally since it'd be optional

although I think the layer now uses the draft PR protocol

But yes having a standard way of doing it would.be good

either way, we need a real protocol or else we get more fragmentation

SDR applications "only" look wrong if you're used to something other than the sRGB EOTF (but to be fair, most people are used to something like ~2.2 gamma) i think most monitors nowadays have proper static hdr metadata in the EDID, so you should get the proper peak brightness by default. though for whatever reason, TVs usually just have `0` in those fields... still, i'd argue that using the windows 11 hdr calibration app isn't really any more of a pain than the equivalent calibration menus on consoles not entirely sure what you mean by the last point

i've yet to find an sRGB application that doesn't look like trash when HDR is enabled on windows 11

also I've yet to see any HDR monitor on windows not have windows default to 1500 nits

a real easy way to see what I mean by the last issue is take an HDR movie, play it in MPV with metadata on in windowed, then let MPV take over, often times you will notice a shift in color/luminance

if your monitor displays HDR signals accurately (within its gamut/brightness limitations), it should look pretty much exactly the same as in SDR mode (when the monitor is in an sRGB emulation mode). though that will most likely look brighter near black than you're used to

I have never seen any monitor do that properly

and i've tested quite a few

which models specifically?

I dunno it's not something i've ever gone out to check, the latest one that I remeber was some 600nit gaming monitor

afaik DisplayHDR certification mandates that those values are present in the EDID, so that surprises me

Speaking of Windows. My BenQ monitor looks really weird under Windows. Not using HDR or anything. Just, the colors are wrong. On Linux, and on my other monitor, they look alright.

just on KDE?

iirc kde swapped to using a gamma2.2 transfer, maybe that?

is windows downloading the display profile and the others not?

? No HDR anywhere here. It just looks wrong with Windows and always correct with Linux.

but yeah, loads of people still have issues with windows 11 HDR mode, and it doesn't look like they will be fixing it any time soon, Android 13 finally fixed HDR tonemapping stuff and has two implementations for it now (you can see the updated tonemapper here https://cs.android.com/android/platform/superproject/main/+/main:frameworks/native/libs/tonemap/tonemap.cpp;drc=7a577450e536aa1e99f229a0cb3d3531c82e8a8d;l=437) OSX and apple has decent support, I never tested it in depth and have no apple devices to test on now Linux is well, linux So supporting HDR as first class and SDR as second class is a ways off

not referecing HDR, just making note of the fact that KDE as a compositor defaults to a pure 2.2 transfer instead of an sRGB one now

I think Windows is getting a profile from the monitor or something that's just wrong. While eternally wise Linux ignores / doesn't support using that data.

is possible

windows doesn't do any color management by itself (except when using HDR, or the newer SDR Auto Color Management)

I don't understand the relevance. If you're not in HDR mode, the pixels that the application renders just get sent to the screen unaltered.

are you sure windows isnt the correct one and everything else isnt wrong

I believe kwin internally does colormanagement but I might be wrong, it's something I could probably test later

Sending application pixels directly to the screen is not a great approach, that means all applications need to 1) have some way to figure out the display space, and 2) implement proper color management. Which is almost surely just not going to happen.

depends on the application, a lot of higher end applications like MPV, or professional applications like NLEs let you set this, but yeah general consumer applications...

white point and gamma curves should get applied

(things that aren't handled by app color management)

also, the problem with trying to switch from the sRGB EOTF to something like 2.2 gamma is that the end result will always be varying degrees of wrong... e.g. if you're doing photo editing in an editor that supports color management, and you want sRGB images to look like 2.2 instead, you basically have to lie to the application about the gamma of your monitor. so images with a transfer function other than sRGB will then also be rendered too dark. similar issue with web browsers, as almost all content on the web is in sRGB while windows's approach to using the sRGB EOTF for all SDR applications in HDR can look bad subjectively, it's at least technically correct for all scenarios

The Windows colors are way off from how things look on my phone, my iPad, my laptop. My Lenovo screen under Windows matches those other things. Under Linux both screens match the other things. It's just that one BenQ monitor only under Windows that doesn't.

the general approach that should be done is application sends out a standard colorspace, and compositor maps it to whatever it needs. higher end applications can send out to what it's supposed to be, and notify the compositor to not do anything

but you could have changed the settings on the monitor to counter the wrong ness that the profile would have been correcting

i assume you checked if the HDMI signal range is set correctly? (if you're using HDMI)

yeah or gpu setting is wack

But if you assume that the input is sRGB, and that the monitor is sRGB, there's nothing to do. Doesn't stop you from doing something else in other situations. Applications don't get direct access to the screen, compositors still have full control over the pipeline and what is done.

How do you do that on Windows?

it's part of the GPU driver settings, not windows itself, so it depends on what GPU you have

iirc what kwin does now is assume the monitor is 2.2 and the application is putting out sRGB

because sRGB is the norm for apps

Kwin in HDR mode has the goal of making SDR content look the same in HDR mode as in SDR mode

im not talking about HDR mode

But it doesn't do anything in SDR mode

does it not? as I said, i thought when I checked it, it did

With HDR, it needs to decide how to display SDR content, and it does so by pretending sRGB = 2.2

I may have been mistaken, but I opened old kwin and new kwin since the change and noticed a difference when swapping between the two

Maybe they did something weird in SDR mode too. I only heard about HDR stuff.

The idea is that monitors are 2.2, and "sRGB" content is already mastered for being viewed on 2.2 displays (because that's what everyone is already using). So converting from sRGB to 2.2 seems like it'd undermine that.

the issue is that content is not being mastered for 2.2 displays, content is still being mastered for sRGB in many cases

hence the headache between 2.2 and sRGB, if it was just one or the other, so many problems would be solved

treating sRGB content as ~2.2 gamma does often look better, but the problem is that that hack falls apart as soon as color management (e.g. via ICC profiles) is involved

Why does it fall apart?

I mean it falls apart depending on the monitor itself

some monitors are sRGB like mine, some are gamma 2.2

personally, i have my OLED TV calibrated to BT.709 (with the proper 2.4) gamma, which means that movies/videos are displayed accurately, while sRGB content is objectively too dark (but still looks good, subjectively) and for HDR games and movies i can just enable windows HDR, and that's displayed accurately too

false

you cant calibrate oled

what?

https://tenor.com/view/math-lady-old-gif-18904946

maybe if you have it on blast on max white for 10 hours before profiling

<a:trollform:771932238748712979>

On KDE, apps that don't do their own HDR rendering are treated as 2.2, which indirectly means that stuff like sRGB images are treated like 2.2

e.g. if you're telling your browser that your display is sRGB (to make it pass web content through 1:1, without modifying the gamma) while your display is 2.2, you do get the desired effect on sRGB content. but any content with a different transfer function will also be color managed under the assumption that your display uses the sRGB EOTF, while in reality it uses 2.2 gamma -> the end result will be too dark

it's probably a bigger issue for things like photo editing, as in practice almost all web content should be using the sRGB EOTF firefox, by default, treats videos as also using the sRGB EOTF (i.e. it doesn't modify the gamma if it thinks your display is sRGB), don't know what exactly chrome does there

> browser that your display is sRGB (to make it pass web content through 1:1, without modifying the gamma) while your display is 2.2, you do get the desired effect on sRGB content this is wrong, if you are viewing sRGB content on a 2.2 display the blacks will be messed up

this is a significant issue for a lot of folk

by desired effect i mean if we're working under the assumption that sRGB content "should" in reality be viewed on a 2.2 display

as there is some controversy around that, due to some ambiguity in the sRGB standard

ah you mean "I graded my content for gamma 2.2 but tagged it in sRGB"?

yes

well it's a good thing that the people making things are calibrated or using a mac

also there is no ambiguity in the sRGB standard, it's actually really clear, troy sobotka talks about this a lot and even on the "color management for linux developers"

the repo being here https://gitlab.freedesktop.org/pq/color-and-hdr/

<https://community.acescentral.com/t/srgb-piece-wise-eotf-vs-pure-gamma/4024> this thread has some interesting discussion, including one of the people who actually worked on the standard it certainly doesn't help that the standard literally says that the reference display is characterized by 2.2 gamma

which page there specifically?

I want to say it was the eotf issue? https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/12 ???

it's been a while so i would need to dig for it

also the headache it'self, just in general for anyone reading, is worth watching this video, https://www.youtube.com/watch?v=NzhUzeNUBuM

some interesting discussion in there, thanks IMO, the biggest issue with interpreting "sRGB" as having 2.2 gamma involved in the colorimetry is that it would mean everyone's been doing color management wrong for decades. in an ICC color managed workflow, using the official sRGB profile and an accurate profile of your display, you're effectively creating content for a display which uses the sRGB EOTF. so i think you can argue that, even if the original intent of the spec might have been different, the sRGB EOTF has become the reference standard

I think regardless everyone has been doing it wrong since it's really complicated [av1_dogelol](https://cdn.discordapp.com/emojis/867794291652558888.webp?size=48&quality=lossless&name=av1_dogelol)

they’re orthogonal things

having a somewhat narrow gamut doesn’t preclude being a true HDR display

in principle, you could even have greyscale HDR

exactly, HDR is simply the difference between light and dark (and everything in between), while gamut coverage is about what colors can be displayed

Isn't grayscale HDR something that has been used in medical imaging for a long time now?

HDR is basically extended luma range, WCG is basically extended chroma range.

does HDR even *have* a proper definition? I've seen many people consider HDR to require both the transfer and a large gamut together.

They're often confused because both things tend to require more precision (higher bit depth) and proper color management.

I personally consider just the transfer, but I have seen at least the statement "HDR refers to a specific type of colorspace" more then once, which would necessitate taking gamut into consideration

really HDR, in the capture sense, is about how light is quantized on a medium

and while you can have 8-bit HDR, it's prone to banding, so it's preferable to have higher bit depth

I would like to see a proper hard definition from some industry standard group

It's hard to define a specific criterion that separates SDR from HDR. Something like DisplayHDR-400 can have a smaller dynamic range than some SDR displays.

I know, this is why I personally try to be specific in listing HLG or PQ when relevant

but for me "HDR" means about as much as "RAW" does

AKA next to nothing

at least in the consumer (video) world, "HDR" usually refers to BT.2100 ("HDR-TV") or related standards like HDR10+ or Dolby Vision, which all use the BT.2020 primaries

but the technical term HDR by itself doesn't say anything about the gamut involved

ive seen it in reference to dcip3 as well

that's what im asking does HDR have a technical definition anyone can point to? because I have not yet found one

as far as I can tell, it's just "kinda a thing"

Also there is the signal space and then there is the part of it that the display can actually reproduce or that the actual image content actually contains.

I agree, I would also like to know

HDR gives the same feelings to me that I get when I hear "raw content"

the problem is that it's kind of a vague technical term that's used to mean many different things in the context of bt.2100, i'd say the point is to have a higher maximum luminance while also having sufficiently many steps near black to preserve detail there (and across the rest of the range, too)

A display can understand signals in Rec2100 PQ but e.g. have a gamut that is 90% of P3 and goes only to 1000 nits.

this is exactly my point, it's like `raw` what does `raw` mean in photography or video? next to nothing unless you quantify it. to give meaning to this example, video in general is a nightmare, `raw` could mean unmassaged RGB values, it could be a raw sensor reading, Prores output from a camera, DNG, J2k output from a camera etc.

https://downloads.bbc.co.uk/rd/pubs/papers/HDR/BBC_HDRTV_FAQ.pdf

like the term `raw`, `HDR` I would argue has no real meaning unless quantified, outside of that, it's more or less just marketing

this is even worse because of the last bit > A better definition of dynamic range is the ratio between blackest black and the brightest white that can be seen on the display without significant artefacts.

~~now we need to define significant artifacts to use it technically~~

the "high" part of "high dynamic range" is already subjective

man... I just want a technical defintion to refer to, at least as much as "a type of transfer function that can, when given enough data represent a luminance range greater then X or Y"

linear would be classifed as HDR under that though... which I guess...

but that really fits the bill for most transfer functions

I agree, it's kind of a nebulous definition > Conventional 8-bit SDR TV has a displayed dynamic range of about 32:1 Also this is wrong, the best 8-bit SDR TVs can reach upwards of 5000:1

I hate the current situation around this because it's more or less like, I feel like that's HDR and thus it's HDR.

As far as I'm aware, when people talk about HDR, they mean 3 things: It has a higher bit-depth (>8 bits), has a wider color gamut (anything better than rec.709/sRGB), and something about peak brightness, nits, cd/m², or whatever.

It's a mess tbh

generally, the minimum common agreement is the transfer, IE, how bright the video is encoded to be at a given value

peak brightness is only part of HDR

color gamut is the next thing, this isnt universally agreed upon to be determined if something is "HDR" or not. I personally don't believe it necessary, but some people do

it means nothing if you don't have a decent black level and easily discernible levels of grey in between

but yeah, color gamut still has nothing to do with HDR or not

the next thing would be bitdepth, many people believe you require 10bits or greater per color to be HDR, which may have merits quality speaking, but technically speaking I don't agree with. the last thing would be white point, if you subscribe to the idea that HDR refers to a `colorspace` then you need to also consider whitepoint as the three componenets that make up a colorspace are gamut, transfer and whitepoint

the issue is that this isn't defined anywhere that matters

literally any B&W "film" can be HDR (but they *cannot* be WG)

you can disagree with it, but you cannot definitively say it has nothing to do with it, because there is no industry consensus or technical definition

It's a term that has no real meaning unless quantified

needless to say, I don't like the term HDR, as I said, it's just as bad as the term raw

maybe, but it's like the definition of space

we define space to be above the Karman line, but does space just start and end exactly at 100Km? No...

Hell, look at the Wikipedia page: https://en.wikipedia.org/wiki/High_dynamic_range

There are *10 definitions* of HDR depending on context

movies/shows are generally considered to be "proper" hdr if they make good use of the luminance headroom, not necessarily the wider gamut

it's just a convenient point to pick, and what matters is that you can see the difference between older standards for dynamic range, and modern ones

~~all I know is that we should abandon transfer functions and just use linear 32bit data for everything~~

linear should be forever banned from representing any form of luma

I mean, I personally agree that "HDR" refers to the effective range of the video's luminance given the current data limitations and transfer. but I cannot definitely say that

a lot of the "hdr" content on netflix, e.g. the one piece series, doesn't even go beyond 100 nits

exr chads say hello

EXR uses floats

and floats do not have linear resolution

yeah, it's linear float

specifically there are multiple types of `linear` but meh, too technical for me right now

it's the same with audio; it uses floats, but floats make sense, as you don't care about a tiny difference at high amplitude, but you do at low amplitudes

team chad float vs team virgin ints

also scRGB is linear too

honestly integer is fine as long as you're using a transform (e.g. HLG, gamma curves, etc.)

but then you're still non-linear

scRGB uses 16bit integer and works fine [av1_akkoShrug](https://cdn.discordapp.com/emojis/654080960492732435.webp?size=48&quality=lossless&name=av1_akkoShrug)

as long as you have 16 more more bits per color is fine

hah, they make very poor use of the volume headroom when doing sound mixing, so maybe we shouldn't let movie people do visual HDR...

sure, but that's not terribly efficient

who needs effiency when you have have **moar data**

"just throw more bits at it" should never be the first response

What do you mean? Its always my first response. It solved my marriage, got me a job, and fixed my back pain. <:AV1:805851461774475316>

xD

audio is often 24-bit integers

typically, it’s recorded this way, then processed as such or as 32-bit floats, then dithered to 16 bits for delivery

SDR is when the max-value color is a white you can use as a background color for something like a web page or a text document. HDR is when you cannot do that because it destroys your eyes and/or your display will not be able to sustain it for a long time.

thats one way of putting it [av1_dogelol](https://cdn.discordapp.com/emojis/867794291652558888.webp?size=48&quality=lossless&name=av1_dogelol)

high end gear will basically always offer f32 these days

which is the gold standard for capturing as you never have to worry about getting levels correct pre-recording

you shouldn’t have to worry with 24-bit integers either

depends if you're trying to record a mouse's squeak and an atomic bomb in the same recording

144 dB of dynamic range gets you all the way from the quietest environments you will likely encounter to sounds that are instantly damaging to the ears (https://web.archive.org/web/20211114090548/https://www.noisehelp.com/noise-dose.html)

(not to mention, the microphone itself is unlikely to exceed that DR anyway)

>me recording whispers and gun shots in the same audio track

>me recording an ant crawling while on a bomber jet

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

I never did understand how hearing damage actually works, or rather how audio degrades through open air, this chart says 140db is immediate damage, but I've had full size rifles go off right near my head (public range, idiot now banned) and, there is some minor pain, but nothing lasting, however shot a suppressed 22 indoors and it was just about as bad

a large amount of the noise actually comes from the supersonic shockwave

suppressors work best with subsonic bullets

and if you're indoors more of the noise might bounce back at you rather than dissipate

> but I've had full size rifles go off right near my head (public range, idiot now banned) and, there is some minor pain, but nothing lasting, however shot a suppressed 22 indoors and it was just about as bad both of those were permanent damage

I am aware of that, It's just the rifle was *really* close to my head when it went off, I got the whole shebang

maybe, but zero measurable effects

no ears

https://tenor.com/view/my-ears-make-it-stop-loud-noise-quiet-gif-17369234

I would posit that ears probably have a maximum volume they can register

so that anything above that volume sounds the same

like they clip?

yeah, I would guess so

possibly, but in the end, I still regularly get hearing tests and they are about as they have always ever been

kinda like welding with no mask [av1_dogelol](https://cdn.discordapp.com/emojis/867794291652558888.webp?size=48&quality=lossless&name=av1_dogelol)

I got sunburned on my eyelids when I did that

that must have been uncomfortable

permanent cumulative damage isn't necessarily more than just a very small amount of damage. Just don't have guns go off next to your head too many more times!

quite

I don't plan on it [av1_kekw](https://cdn.discordapp.com/emojis/758892021191934033.webp?size=48&quality=lossless&name=av1_kekw)

though occasionally, I do forget earpro, or they aren't on quite right

https://en.wikipedia.org/wiki/Aritzia — these guys are serving quite a lot of jxl images right now

which means most of their customers have an iphone ?

vancouver mentioned

most certainly chinese + iphone

> targeted towards young North American women I think that means mostly iPhones, yes 🙂

but I meant in absolute terms, I haven't checked what percentage of their imagese are jxl, I just see they are serving a lot of jxls

looks like all product images

for a store i guess it's all

and also all the temp placeholder images as well

so basically all images doubled

all the loading/placeholder images are the same res as the final images

yeah I noticed they do a weird kind of loading thing with large placeholders that are explicitly pixelated — there are better ways to do that (use small images, make the browser upscale it with NN)

I wonder if they're going for some kind of artistic effect with that, or if it's just a poorly implemented LQIP thing

`https://assets.aritzia.com/image/upload/f_auto/q_10/e_pixelate:50/c_limit,w_1200/su24-wk10-06-19-hp-pt2-c` `https://assets.aritzia.com/image/upload/f_auto/q_auto/c_limit,w_1200/su24-wk10-06-19-hp-pt2-c` Just seems like a strange way of thumbnailing

I assume they did it for image formats without progressive loading, but in the case of JXL it just makes loading take even longer for worse results

speaking of that reminds me how when the update that fixed Shopify's logic for chooisng JXLs files came out it was also the same update where Shopify forced hashblur for every image (including JXLs) and and only shows the full image once it's fully done downloading

a lot of CDNs and websites do things that just completely nullify JPEG XL's progressive decoding abilities by only assuming full images should be shown once they are 100% downloaded

proof jxl isnt needed

just like webp and mozjpeg

not really it's just proof websites assume all images are only presentable once fully downloaded and feel like they have to dual download placeholders generated of the full image(s)

and that problem is solved

just not with jxl

horrible solution imo I don't like websites downloading a bunch of separate images/files/data that then have to be processed through javascript just so they can be discarded and then switched out with something I was already downloading

just adding unnecessary layers to solve a problem that wouldn't be a problem if image formats/decoders did the work themselves

yeah just like webp

WebP's problem was having downsides that previous formats did not while also not providing enough benefits compared to previous formats hence why Mozilla fought against it back in the day

exactly

why use jxl when you can use multiple jpgs

and it performs faster

Safari doesn't implement progressive loading of jxl at all 😦 — I assume they went for a simple integration of just passing a full bitstream to CoreMedia and getting pixels back, rather than doing a deeper integration like they have for jpeg

all browsers support progressive jpeg so there's no need to use multiple jpegs

the whole "placeholder images" thing is basically an anti-pattern and web devs should just stop doing that, and use progressive jpeg or jxl instead

To be fair, it's probably actually not that real high of a priority for them. given their user base and the current state of the web

Might be intentional. With progressive formats it's not always obvious whether image fully loaded or the source is just blurry, especially on the last couple of "progressions"

JS=based loading bar might be better, though

that's why it's nice that jxl only has 2 passes by default

2 passes means 1. blurry 2. fully loaded?

Do we know what algorithm Apple is using to generate their gain maps? I thought their camera captures multiple images at different exposure levels to generate an HDR image. But if the gain map can be generated from the HDR image with an algorithm, then why is Apple choosing to do something absurd like storing the result of an algorithm instead of just signalling what algorithm to use?

yeah

Sounds good. I hate when websites are badly coded and I try to click some button during loading of media and while I click some image just appears, whole site moves and I click on advertisment accidently 😄

I think the way it works is that it’s an SDR image and the gain map signifies the HDR brightness, so like RGBE. I’m not 100% sure though so could be wrong

yeah, afaik the idea is to store a regular SDR image that can be displayed by any software, and then have the extra HDR data in there that can be used to recover the "full" HDR image (if the software supports it) presumably, whatever computational photography magic they use to generate the SDR image from the HDR data is much more expensive than applying a gain map when displaying an image, so i guess that's also a good reason to pre-compute it

I'm pretty sure it isn't

They do it that way so that old software that doesn't support HDR images will have an SDR image to show

And you can't actually recover the full HDR image, since there will be a lot of quantization errors leading to a lower quality image.

Yeah, exactly. It just seems pretty insane actually, to store a (degraded) output of an algorithm instead of just signalling what algorithm to apply...

Like wb says, I doubt ANYONE is actually manually editing a gain map by hand. And having 2 separate images that could potentially be utterly different scenes if you wanted them to be, seems like a bad idea in general

yes, but the SDR image is what the vast majority of people will see, so it has to look as good as possible though i suppose the relationship between the SDR and HDR image could be relatively simple, depending on where in the pipeline they generate the two variants of the image (or how much they care about the HDR image looking significantly better)

It defeats the purpose of switching to a more efficient lossy format like HEIC. Wasting bytes storing 2 separate images for every image...

Well, maybe not, if they're doing it smart...

Out of all the formats JXL is probably best for gainmaps too. Could use a single greyscale 16 bit extra channel alongside the normal 8 bit VarDCT image to keep the best of both worlds... Although I've just reinvented RGBE...

Yeah that’s basically RGBE lol

The gain maps approach is mostly about interoperability. It makes it easy for applications that don't support HDR to gracefully degrade. Too easy, if you ask me. The downside of graceful degradation is that there's not much pressure on the wider ecosystem to implement the non-degraded feature.

I see it contrarily, currently you have a lot of people who don't "get" hdr. and the few times they are exposed to HDR capable devices, it's almost always just plain SDR content. so a lot of people don't actually really care about HDR since the only real exposure they have is YT videos or netflix on their phones. I think that once people start understanding why HDR is great, the ecosystem will naturally progress towards HDR, it's just a matter of properly exposing folk to HDR.

Sure, but there will also always still be SDR images around. It is hard for a naive end-user to know if an image they're looking at is just an SDR image, or an HDR image gracefully degraded to an SDR image because their software doesn't know how to apply gain maps.

Where wide-gamut images fit into this?

HDR-to-wide-gamut conversion is kinda an obscure thing, for some reason.

HDR to wide gamut isn't really a thing afaik, you do standard range to high range, and standard gamut to wide gamut. an "HDR to wide gamut" image would simply be tonemapping a"typical" HDR image to SDR without doing gamut mapping though I suppose it could be possible that HDR could be better to extrapolate data from then SDR...

Gamut and dynamic range are orthogonal things (though in both cases you need more precision if you want a larger range)

so HDR is more variance in Luma, where as WCG is like more variance in Chroma, correct? and since both involve having more variance, they both require higher bit depths.

Yes. You can have grayscale HDR, while grayscale is the narrowest color gamut you can have 🙂

Grayscale = Ultra-NCG (Narrow Colour Gamut) 🤣

also note that PQ (the most widely used EOTF/"gamma" for HDR content) is specifically optimized to keep banding just below a visible threshold across the entire range, which is why it only requires 10 bits to look good despite the huge luminance range (0 - 10k nits)

i really should learn about these things properly

well, you don't *need* more precision if you want a larger range, but without it you'll get <:banding:804346788982030337> artifacts

or, theoretically, with enough spacial resolution you could simply have 1-bit of depth and dither between to get every possible value, but that's not exactly practical in the real world (for displays) <:NotLikeThis:805132742819053610>

...but it is how printers with only a single color of ink work

Technically, the same precision but with a pallete would work fine, assuming the image doesn't use most of the range anyway

I mean the effective precision you need is higher, however you implement it (spatial or temporal dithering or just having more shades, in the end that's an implementation detail).

in audio, DSD (used in SACD) kind of does that – it’s 2.82 MHz, 1-bit

(from what I understand, this is combined with heavy noise shaping to push the noise to the higher frequencies)

https://sjeng.org/ftp/SACD.pdf is quite critical of the approach, though

> Single-stage, 1-bit sigma-delta converters are in principle imperfectible. We prove this fact. The reason, simply stated, is that, when properly dithered, they are in constant overload. Prevention of overload allows only partial dithering to be performed. The consequence is that distortion, limit cycles, instability, and noise modulation can never be totally avoided. We demonstrate these effects, and using coherent averaging techniques, are able to display the consequent profusion of nonlinear artefacts which are usually hidden in the noise floor. Recording, editing, storage, or conversion systems using single-stage, 1-bit sigma-delta modulators, are thus inimical to audio of the highest quality. In contrast, multi-bit sigma-delta converters, which output linear PCM code, are in principle infinitely perfectible. (Here, multi-bit refers to at least two bits in the converter.) They can be properly dithered so as to guarantee the absence of all distortion, limit cycles, and noise modulation. The audio industry is misguided if it adopts 1-bit sigma-delta conversion as the basis for any high-quality processing, archiving, or distribution format to replace multi-bit, linear PCM.

1-bit audio, I've done that when I've wanted audio output from a microcontroller

That's a good reason for JXL to only support HDR base images...

Well we intend to support both but suggest applications to it that way.

Maybe if it's a losslessly transcoded JPEG it would make sense...

But otherwise it seems like a bad idea and even for JPEG it's probably a better idea to just use a color profile eh?

btw if JPEG can do HDR with a color profile why can't webp?

JPEG can only do direct HDR when using its 12-bit mode (which is not part of the de facto format) or when using a sufficiently precise implementation of its 8-bit mode that can work with higher bit depth buffers (like jpegli). WebP only has an 8-bit mode and moreover it has obligatory 4:2:0, obligatory limited-range yuv, and an internal precision that is lower than the internal precision of JPEG's 8-bit mode. So even if you would write a "webpli" that works with higher bit depth buffers, I don't think you would have enough wiggle room to squeeze enough effective precision out of it for HDR.

Something like UltraHDR (8-bit SDR image + separate gain map) could be applied to WebP, though it would have all of the disadvantages of UltraHDR JPEG and none of its advantages.

yeah, technically possible but probably hopeless banding-wise with PQ; HLG might have a bit more of a chance

libjxl was added to Freedesktop SDK, so it will be easy to use with Flatpak applications. https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/merge_requests/19916/commits Previously libjxl was available inside KDE runtime and GNOME runtime. The presence in the "standard runtime" is even better, because ffmpeg can use libjxl in Flatpak too: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/commit/277f0d65b1f587fc28b81b846ceecf195d5acefc

macOS still dies trying to view large JXL files (at least it can process the 1:8 downsample and then tiled decode the high resolution data)

i'm using this as my "large image"

JPEG XL image, 13284x7473, lossy, 8-bit RGB+Alpha

although i can probably drop the alpha

it is a decently sized image 0.0

here's version with no alpha

Similar to the first year of AVIF on macOS

not sure how new this is, but `WindowsCodecs.dll` from windows 11 24h2 has functions for creating jpeg xl decoder/encoder instances, and also for reading/writing animation frames it references `msjpegxl_store.dll`, which is not present on the image, so the actual codec is probably going to be distributed via the microsoft store (similar to `mswebp_store.dll` etc.)

We were aware of references to an encoder and decoder for a few months now, but the DLLs are new as far as I'm aware

<@98957339243073536> soon

I'm getting crazy corruption in Preview with images over 8 bits. Have you tried that?

unfortunate that there isnt any MS dev here that could confirm us that they really are cooking jpeg xl plugin for ms store

Seeing as we saw registry entries months ago, now actual DLL calls in 24H2 and reference to the MS store, I think it's safe to say they're getting close on finishing support

it can

If you don't mind banding

I think 10'000 nits PQ has significantly less perceptual banding than 300 nits SDR gamma when there are dark regions. sRGB definitely, it's a terrible transfer function...

pq 8 bit would be pretty rough

I think for SDR being the intended range of around 80-203~ nits sRGB is fine, the issue you run into with PQ and 8bit can be played around with using this script, dont mind it working in bt2020, despite everything it wont actually effect the luminance, you could try for yourself with `RGB_COLOURSPACE_BT709` ```py import colour import numpy as np r = 100 g = 100 b = 100 # divide 1023 for 10bit #65536 for 16bit eotf_BT2100_HLG rl = r / 255 gl = g / 255 bl = b / 255 rgb = np.array([rl,gl,bl]) BT2020 = colour.models.RGB_COLOURSPACE_BT2020.matrix_RGB_to_XYZ ##constants RGB_lin = colour.models.eotf_ST2084(rgb) #RGB_lin = colour.models.eotf_BT2100_HLG(rgb) xyz = colour.algebra.vector_dot(BT2020, RGB_lin) srgb_xyz = colour.sRGB_to_XYZ(rgb) print("PQ is: ", xyz) print("sRGB is: ", srgb_xyz) ```

but even a quick test of 100 vs 150 shows a harsh showcase ```ps ➜ scripts venv/bin/python3 lum.py 2> /dev/null PQ is: [ 28.28771187 29.76225521 32.41281472] sRGB is: [ 0.12112952 0.12743768 0.13877963] ➜ scripts venv/bin/python3 lum.py 2> /dev/null PQ is: [ 207.36297014 218.17210481 237.60202175] sRGB is: [ 0.28989044 0.30498731 0.33213119] ```

the one we care about is the middle number

the last number would could reliably use us (191, 191, 191) as (192,192,192) is over the 1knit range, where as with sRGB, you are only at "half" the intensity of whatever nit range you are grading for ```ps ➜ scripts venv/bin/python3 lum.py 2> /dev/null PQ is: [ 926.28780074 974.5720705 1061.36526705] sRGB is: [ 0.49520629 0.52099557 0.56736418] ➜ scripts venv/bin/python3 lum.py 2> /dev/null PQ is: [ 960.21908551 1010.2720791 1100.24463812] sRGB is: [ 0.50102293 0.52711513 0.57402837] ```

ofc you could just say "give me the PQ transfer, but make my max nit range 0..300~" or something like that, which to my knowledge JXL actually supports

have fun breaking 99% of software tho

sRGB transfer is never fine in the dark regions with 8-bit, even at 80 nits peak

I disagree, with an 80nit peak its fine,

for gamma 2.2 maybe

you would be extremely hard pressed to find issues with sRGB on any true 80nit display let alone 80nit CRT (as to which sRGB is designed for)

for modern SDR content which is more like 300~ nits I do agree that sRGB is bad, but PQ is not the answer for that

Just noticed this in the foobar2000 (audio player) beta change log: 2024-05-31 ... Fixed JXL/AVIF/HEIC external album covers not being recognized, even if relevant system image codecs are present.

https://www.foobar2000.org/changelog-win-2.2-preview

and then FFmpeg only support PNG, JPEG, GIF album arts…

The thing with lossy WebP is that it's effectively 6.5-bit, not 8-bit. The green channel is still around 7-bit but the red and blue loses more than one bit of precision due to the conversion to limited-range yuv.

I noticed that libmagic is a bit shy on jxl files

``` $ file reference_image.jxl reference_image.jxl: JPEG XL codestream```

vs

``` $ file reference_image.jpg reference_image.jpg: JPEG image data, JFIF standard 1.01, aspect ratio, density 1x1, segment length 16, baseline, precision 8, 3600x4200, components 3```

is there any background context on this? Or is it just a metter of somebody contributing to libmagic?

the latter

can magic use arbitrary logic to extract such information?

https://man.openbsd.org/OpenBSD-7.2/magic.5

It uses this logic

I seemed to remember something along those lines

I’m not sure it’s flexible enough for that

It is capable of finding matches and going down conditional branches to find additional matches to display more information about a file. It should be able to tell you everything about a file based on the header info as long as it is capable of finding a match

Like it should be able to tell you if it's a raw jxl or a jxl container with multiple boxes, etc, as long as it's not compressed in an encoding that prevents finding matches

offset is in bytes

which strikes me as difficult to make work with JXL

At the very least it should be able to tell the difference between raw and containerized jxl

It can do variable offset by searching for a string or a regex

It can also use offsets read from the file... there's a lot of flexibility so unless everything is brotli compressed or something it should be able to print lots of info

I hope fossify accepts the jxl pr, most images i've tested work. some like my woag testing image I think are too large and trigger resource protection

give me one file like that, I want to test

I think you already have the apk but for anyone else https://files.catbox.moe/7dllzt.apk

mmmmh I just have a "black" screen

at least it doesn't crash the app

unlike the other Gallery app with the package name `fr.oupson.pocjxlgallery`

yeah, I think glide has resource protections when I was looking at the logs but they weren't super clear

it could be that decoding is taking too much ram, which granted anything more then 100mib on a phone is a hard swallow. could also simply be render limitations

Actually, PNG decoding fine, so it's likely a RAM limitations

well, it's some progress https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/128#experimental_web_features

this is still a nightly change

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

firefox's libjxl code was apparently updated to this june's snapshot that covers gainmaps

maybe nightly's support was improved in the meantime

are any websites doing an origin trial (basically force activates certain flags for those sites, handy for testing and especially cdns doing enabled by default experiments)?

it wasn't improved, and also libjxl is just set to somewhat auto update itself in the codebase

havent seen anything major, but I didnt scan much https://hg.mozilla.org/mozilla-unified/log?rev=jxl

It's more like documentation change, to describe what's been happening all this time

The last PR merge seems to be a month ago, so it's possible they're just not helming the wheel, right now. And I hope so, too. Thank you for doing that, btw. Re: large images, what's the "smallest" large image resolution it fails on, that you've seen?

4k works, 16k doesn't, don't have an 8k image on hand

Cool, so it should still handle the vast majority of images people might have.

correct

oh btw, reporting on the issue if it works or not would probably be helpful, I can provide an apk if necessary

Is it the same as linked above?

oh I forgot I linked it, but yeah it is, if you can give it a whirl and reply on the PR it would be nice

https://www.fastly.com/blog/level-up-your-images-jpeg-xl-now-supported-by-image-optimizer/

> SSIM > We used ssimulacra2 to generate these scores. Well, at least they used the right tool

> Migrating to JPEG XL reduces storage costs by serving both JPEG and JPEG XL clients with a single file. Finally sounds like a CDN is actually using the proposed transcoding for legacy clients

Is there something more than just bitstream reconstruction ?

No, that's it, but so far everyone has just been serving either jpeg or JXL instead of transcoding to save the storage

reconstruction in both directions is literally instant at effort 7 and below (here every img below 12 megapixels converted in like 30ms). well doable live by any server, cache or web app. higher effort saves extra kilobytes but any reconstruction consistently saves 20% already

speaking of the reconstruction stuff, does imagemagick support the lossless transcoding?

Will do. Did you also want to share the link in the issue or PR ticket itself, like Oupson did with his test?

nah, it's pretty sketchy to share apks in the first place and some projects really frown on that

Alright. Well, I just tried it and, so far, it works well! Viewing is fairly smooth (no major performance issue like in Oupson's build) and no crash. The only thing I've noticed is that it takes a few seconds to initially load the files in a folder and begin generating thumbnails. But, a HUGE improvement is it detects jxl files natovely and will show a folder containing only them, whereas the other build required a non-JXL image to be present for the gallery to show the folder in the first place.

Update: I tried a potentially breaking action, using the "resize" option to convert a non-jxl file into one and it seems it kept it as a jpeg with a jxl extension and bumped the size from 25kB to 25.7, but nothing exploded. That's good, at least.

yeah, I found perf to be mostly fine, libjxl in general still struggles with some images unless you play around with manual cpu affinity stuff. but generally it shouldnt have too many issues

Cool. Well, I'm going to be daily driving this for a while, I think. I'm also using https://play.google.com/store/apps/details?id=ebusky.jpeg.xl.image.viewer.converter to do conversions on mobile, since it has a number of exposed settings, is user friendly, and is more up to date than the other option on the playstore. But, I don't think it has the 0.10.1 version included, since crashed on a larger image (the RAM issue), and it also doesn't let me select between VarDCT and Modular, but should be good enough until we get a better solution for Android.

Might want to take a look at this https://github.com/T8RIN/ImageToolbox

Also in the play store but I have a bug that stops compressed filesizes showing in the preview

Has JXL transcoding, effort levels, RGB or RGBA selection, custom resizing filters... Almost too many options honestly

Nice. I just was comparing then output from the app I just linked to with the original images and...it appears to do some forced downsizing of the resolution. :/

<@184373105588699137> I think you already mentioned this, but the Gallery app does not get the resolution info from jxl files.

I'm going to use Obtainium to get it. But, I can't see what the difference between the PkayStore version and the FOSS version is... do you have an idea? Maybe no Firebase or something?

If I recall the FOSS version replaces some system called features with open source variants, but I was confused too

Huh. Well, as long as it still works. Lol

Thanks for the recommendation. I had no real clue about it, yet it appears to be, by far, the most developed app of its kind.

No, libraries like that have a pipeline that goes decode -> pixels -> processing -> encode, so the "first-class citizen" is an image buffer (with metadata), not a bitstream. That makes it hard to fit something like jpeg bitstream recompression / reconstruction in such libraries.

ah I see, looks like I'll have to find an open source cdn software I can ~~bastardize~~ mod to use libjxl or cjxl directly then

https://github.com/Pixboost/transformimgs

seems like that's only an image cdn [Hmm](https://cdn.discordapp.com/emojis/1113499891314991275.webp?size=48&quality=lossless&name=Hmm)

any issue with its jxl support?

no idea, I would need to look at it's implementation, but since it is only an image host it's a bit of a lowpri

seems like it uses imagemagick

theres jxl-ready fediverse image hosting scripts if its not cdns with conversion caps you need

I am aware of things like pict-rs but they don't support accept headers

afaik

asked if pict-rs will have support for accept headers in the future

I'm pretty excited about how the momentum seems to be slowly building behind jxl despite the intentional and cartoonishly selfish sabotage by the webp tech lead.

Don't you mean AOM?

Yeah, I don’t think WebP is the problem now

Well, the chrome codec team tech lead, formerly on2 tech lead and brainchild of webp and webm. The guy who unilaterally decided for everyone else that "the entire ecosystem" doesn't have "enough interest" in jxl because it hurts his pride or something. Jim Bankowski.

I don’t particularly see anything wrong with the webM format but WebP can go burn in a fire lol

Well, Android didn't adopt JPEG XL, either, so I suspect the problem is higher in the hierarchy.

And unilaterally removed all the code from chrome in a cartoonishly transparent and flailing bid to derail and snuff the unstoppable and growing momentum of jxl

The chrome file format team and the android file format team are probably either the same team or in close communication with each other though

I don't think so. To be fair, Android hasn't adopted anything. They're still using JPEG...

They adopted AVIF.

I havent even seen anyone make a PR for it or anything

I guess that makes sense. What else are they gonna use? (RE: using jpeg)

afaik the android open source distribution doesn't even have a built-in camera and gallery app