JPEG XL

`cjxl -x color_space=XYB_Per -d 0 Olo-XYB.pfm Olo-XYB.jxl`

What will be displayed depends purely on how the clipping is done, no?

reminds me of ycbcr 0, 0, 0

I wonder, if you use XYB_Abs, do you get any different results?

`lib\jxl\fields.cc:426: JXL_ABORT: AllDefault should never fail`

I did however realise that lossless effectively hands the color management to the viewer, using lossy makes it into a saturated green

huh, I don't see anything in the spec that would make absolute rendering intent not work with XYB, weird that there's a crash 😅

We had to apply this old PR too, otherwise it stays dark green https://github.com/libjxl/libjxl/pull/2506

Doesn't surprise me that trying to encode/display non-physical colors ends up in issues

*Theoretically*, without clipping, this file is Olo... Maybe. The B channel may need Y subtracted from it depending on what version of XYB libjxl was interpreting it as

hmm, I'm just getting the darker variant on viewers I have, except that GIMP completely refuses to decode it

if you haven't bought one yet: https://www.ebay.com/itm/227135976963 (unclear from that pic if it goes up to 2k or 1k nits, good price either way though)

Oh, that is a really good price, thanks!

*checks wallet* seems I already spent way too much money tho 🥲

https://github.com/dylanraga/win11hdr-srgb-to-gamma2.2-icm

when you stumble into something that works, dunno why, and draw your own conclusion

alternatively, for sdr content only: https://github.com/ledoge/dwm_eotf

this one is more neat IMO, i hate the word gamma so much lol

it works great until chromium switches between outputting sdr and hdr every few seconds

turns out there's a lot of stuff on the web and discord that's tagged as p3 or something

I really wish chromium was just always HDR when HDR mode was enabled

why?

i'd guess they stay in 8 bit sdr for lower power consumption

because sdr on hdr is buggy and looks not so great no matter what you do, also chromium iirc uses monitor bitdepth anyways

doesn't look like it https://source.chromium.org/chromium/chromium/src/+/main:ui/gfx/color_space_win.cc;drc=e8bd5419c4cfa034da3ded7c5016402c6f884fd8;l=350

and there's nothing buggy about it afaik, it looks 100% identical between rendering in sdr and hdr

the only real tell (other than actually seeing wide gamut/higher luminance colors) for hdr output is that if you change the windows sdr brightness slider, it only affects chromium when you focus it again

because it fetches the value on focus, as opposed to sdr mode where windows is responsible for applying it and it changes it instantly

I've found that it can flounder pretty hard in some spots personally

🤔 that's probably a bug in chromium then

How does the Wide Gamut Webkit P3 display test work? I've never seen an instance where the webkit logo renders, even if I manually download and open the image in an external viewer

My color picker also tells me that all images are completely 255,0,0 red

your monitor needs to support wide gamut colors and you need a ICC profile setup in the OS to tell it that the monitor supports more colors then sRGB

picker from which software? you’d have to make sure the colour picker is not operating in sRGB or in display space

Well I was doing it from screenshot which I guess would be display space

since I wanted to look at all four without downloading them and opening them seperately

I guess it's because using like the cheapest 1440p 144hz monitor from 5 years ago with no special color profiles or shit

it’s possible that it actually is wide-gamut, just unprofiled so the software side doesn’t know

96% sRGB

even without a colorimeter, it could be interesting to see what kind of ICC profile DisplayCAL creates from the EDID

ah, then maybe not

https://www.amazon.com/GNV27DB-2560x1440p-Curvature-G-Sync-Ready-Zero-Tolerance/dp/B084CYSSBG

(I mean, even with a smaller volume, maybe the primaries have a slightly different hue or something, but, eh)

Like the one time I wanted to look into higher color depth shit (in this case it was a 10 bit panel like 7 or more years ago) I got ripped off, so like I don't particularly care about it anymore, other than wanting to confirm it's not like a bug or me going insane

if you ever plan on trying again in the future I'd recommend looking for a display that's certified VESA DisplayHDR™ because monitors with that have to actually adhere to minimum specifications set by VESA instead of the manufacturer eyeballing it and slapping "HDR" or whatever else on the product https://displayhdr.org/performance-criteria/

Yeah for me it was Acer claimed the monitor was 10 bit, but I bought it right when they did a cheaper refresh of it without 10 bit and didn't update the page and then because I was using [chlamydia](https://cdn.discordapp.com/emojis/1440694258679025856.webp?size=48&name=chlamydia&lossless=true) GPU I had no idea if my monitor was 10 bit or if the GPU was artificially restricting me from using 10 bit

are there any good introduction guides to gamut mapping with an emphasis on actual practical implementation? something oriented to beginner coders or something

~~I learned gamut mapping with libjxl~~

yeah, someone asked me about it, i kinda feel like looking at other code is just how people do it lmao

https://github.com/GPUOpen-LibrariesAndSDKs/FidelityFX-SDK/issues/41 bruhhhhhhh

That's unfortunate, if he is correct

right now im optionally clipping scrgb since I just want a cheap hack, but im wondering how *should* i map scrgb gamut?

maybe it's better to scRGB -> XYZ -> XYB? <@206628065147748352> any idea if this would play well with jxl-oxide when requested gamma2.2 output? I honestly have zero idea but I think it would? the issue would be Y < 0.0 ?

I'd do tone mapping in XYZ or XYB, and gamut mapping in Oklch if it's feasible

but I'm not an expert either

actually now that I think about it, is the matrix in https://cdn.standards.iteh.ai/samples/35876/24e0310d04e54233abf5d067e49a8eb7/IEC-61966-2-2-2003.pdf even applicable to microsoft's scRGB? I honestly don't know

> The encoding transformations provide unambiguous methods to transform between CIE 1931 XYZ tristimulus values and 16-bit values for each channel of scRGB. The CIE 1931 XYZ values are scaled so that the sRGB black point to white point luminance is 0,0 to 1,0, not 0,0 to 100,0. Y-tristimulus values less than 0,0 in CIE 1931 XYZ space represent values below black. Y-tristimulus values greater than 1,0 represent values brighter than relative white. > > The scRGB components that range from 0 to 16 384 encompass all visible surface colours (from −0,5 to 1,5). The range from 12 288 to 65 535 is used to encode an extended specular range of colours (from larger than 1,0 to 7,4999).

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

ofc, we know that microsoft exceeds 7.5 regularly

just calculate the linear srgb -> xyz matrix yourself from the srgb xy values

ah, sorry, I mean the prep to the matrix

I think it's simply not necessary to normalize

I think I can just apply it and call it good

*i think*

yes

ok, imma try that, just raw dog it directly to XYB, pump that to jxl, decode it with jxl-oxide and pray LMAO

well later me will do that

looks like xlibre HDR is actually being developed

I'll believe it when I see it

https://github.com/orgs/X11Libre/discussions/251#discussioncomment-15585471

heres the POC

>X11 >HDR that's a thing?

I was under the impression X would never be HDR

it has been for a long time, this is just the beginning of work of making it usable for desktops, but for those of us who needed HDR kiosks long before wayland was usable, a simple mod can make xorg output PQ or hlg

but realistically speaking 99% of the issues with x11 are specifically because of xorg, not because of x11 itself

You wrote "HDR doesn't work great on KDE because KDE messed up the SDR on HDR", could you give some more context regarding this? I found SDR to be fine, personally, but also haven't had much exposure to HDR in general

SDR apps on KDR all look off in really weird ways, it's not too noticable when you are just doing normal use, but it's really hard to tune right, when you change SDR application brightness on KDE, it influences HDR application's brightness, and SDR RGB channels don't seem to be properly synced when changing luminance which makes it feel really awkward

Hm, interesting. Have you considered opening a ticket at the kde bugtracker? If you provide me with more info I could also do it. Regarding SDR in HDR I found that colors are slightly oversaturated in HDR, but it wasn't a massive difference, luckily

some of the issues have already been raised, ill see if I can find the links to them

I don't know how good of a generic guide it is, but this article covers a few approaches to clip mapping to a smaller gamut https://bottosson.github.io/posts/gamutclipping/

could be fun to look at how libjxl’s _ad hoc_ method behaves on that test image

HDR itself doesn't mean gamut mapping is required, you can increase luminance in sRGB just fine, many displays and hardware drivers allows that. It requires luminance mapping or tone mapping

Gamut mapping is required when WideGamut is involved ( Rec.2020, ACES etc) and one want to compress bigger gamut into a smaller one

Usually one can't do that in Oklab since is described by sRGB so it's not directly possible to use this colorspace neither for HDR nor for WideGamut

And as HDR requires manipulation on physical lightness directly so one should compress lightness in linear colorspace or more tecnhically in scene-linear light

and after that if gamut compression is required then perform gamut boundaries clipping in one of huge uniform perceptual colorspaces

The only real problem here is that anyways this is a concept "how to put something big into a something small" so there are no ways to do without breaking something.

Gamut mapping is mostly ignored since display will clip colors anyways. Most of commercial photographic software uses some sort of crude clipping like [this](https://github.com/awxkee/moxcms/blob/5a7db55b988155dc041f329a286c0f80b4289bc6/src/gamut.rs#L45) . If you want to do some sort of "real gamut clipping" [here](https://eng.aurelienpierre.com/2022/02/color-saturation-control-for-the-21th-century/#fitting-hue) is a good article how that works with an example.

I will look into these thanks

some tone mapping methods produce out-of-gamut colours even if everything started in-gamut, so then you do need a pass of gamut mapping afterwards

Yep, but many tone mappers suffer from over compression, especially when applied directly in the RGB color model. Producing out-of-gamut colors from already in-gamut colors usually requires exotic tone mapping that I assume someone starting exploring tone mapping will unlikely to encounter, or applying tone mapping in a different scene-linear color space for example Yrg.

When going from PQ with sRGB primaries to SDR sRGB, you get out of gamut if you try to preserve saturation, right?

it doesn’t require exotic tone mapping; the simple EETF described in BT.2408 (https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.2408-8-2024-PDF-E.pdf#page=68 page 66) will do so in several configurations

This is exactly what I mean exotic as you don't start exploring something by reading ITU-R recommendations 🙂

Depends on working color space, color model and tone mapper. If orthogonal linear colorspace i.e. Yrg is used then yes, highlights almost definetely will be out-of-gamut. If linear RGB is used it depends on tone mapper for ex. Reinhard almost never will produce something out-of-gamut, but some log based tone mappers almost always will.

well, I did

starting with the ITU recommendations seems a sensible thing to do to me, those are standards and they're publicly available

I agree as default Rec.2408 is nice choice

but many people will start with typing to search "tone mapping" and there will be no links to ITU

speaking of 2408 AFAIK it doesn't produce or "almost no produce" out-of-gamut colors when performed in linear RGB and chosen lightness is a correct one and you're not compressing gamut by the way

it should be specified in pdf if I'm not wrong

Yep, it is

> HDR itself doesn't mean gamut mapping is required, you can increase luminance in sRGB just fine, many displays and hardware drivers allows that. It requires luminance mapping or tone mapping it's worth noting that not everyone agrees that HDR is simply luminance, many people believe that "HDR" also encompasses a wider gamut

rn im just wondering on how best to implement gamut conversion from scRGB to sRGB

one thing I don't really get is this: if you have a color like (4.0, 0.0, 0.0), where sRGB white is (1.0, 1.0, 1.0), then is this "super red" inside the sRGB color gamut or not? If you'd render sRGB on a display 4x as bright, this color would just be (1.0, 0.0, 0.0), so the color is inside the sRGB gamut, but then again the value is out of range so you can also think about it as a color that is within the normal brightness range of sRGB — after all it should still have an overall luminance that is a bit lower than (1.0, 1.0, 1.0) — but just much more saturated.

I hate how confusing color is <:SadCheems:890866831047417898>

depends on how you define your sRGB color space. if you go by the textbook definition of 80 nits then it's out of gamut, but if you set the white point at 4*80 = 320 nits (still reasonable) then it's barely within gamut assuming (4,0,0) is supposed to be a triple in microsoft's scrgb space specifically

i think luminance is a red herring here, it makes more sense to think about this in terms of CLL ("content light level" iirc). basically if you take (4,0,0) you say that it has a light level of 320 nits

one of the h. standards explains this, one sec

I think it's hard to think about this in RGB color model. It may be easier to think in some luminance orthogonal colorspace Yrg, JzAzBz where luminance projection doesn't shift hue. In such spaces, increasing HDR luminance leaves hue unchanged, so the color simply becomes "brighter" rather than different. From this perspective, a color like (4.0, 0.0, 0.0) lies outside the sRGB gamut only in terms of its encoded range, not its chromaticity. If you clamp or project the extended luminance back into the SDR range, the color immediately becomes an in-gamut sRGB color with the same hue and chromaticity. In that sense, it can be thought of as an imaginary extension along the luminance axis rather than a truly out-of-gamut color.

it's kinda hard to put in words but the idea is pretty simple (this is from h.265)

This is my understanding. I don’t claim that it’s absolutely true.

this is why I always change to something like XYZ lol

also, regarding mapping from scRGB to sRGB: i think for the result to be sensible you first have to detect the actual gamut spanned by the input, since it's effectively unbounded

an scRGB screenshot can just be the windows desktop without any wide gamut or >80 nits pixels present

(though if it's the windows desktop set to a higher brightness, then presumably you'd just want to scale down the luminance linearly and not touch the chromaticity)

https://github.com/bvibber/hdrfix

maybe this does something reasonable, idk

yeah, I do I think I want to optimize for XYB so jxl can "just werk" with it

to clarify, non-linear is not the problem (YRGB is the linear one; R′G′B′ isn’t); doing it on channels independently vs. “all at once” is

YRGB: compute ratio = target luminance / source luminance linear R \*= ratio linear G \*= ratio linear B \*= ratio can generate out-of-gamut colours if the ratio is not small enough to bring one of the components below 1 (for example, pure blue above 1 which is still not very bright – because it’s blue – so it’s not reduced a lot, if at all, by the ratio) R′G′B′: R in PQ = EETF(R in PQ) G in PQ = EETF(G in PQ) B in PQ = EETF(B in PQ) since the EETF maps the source PQ range to the target PQ range by construction, the end values are naturally limited to the right range with no further adjustment (but because this might amount to different linear ratios per channel, it might shift hue)

What kind of stuff you want to do depends on the wanted rendering intent as well, on absolute/saturation you just clip in some way, while with perceptual or relative you end up trying to map it somehow

(not that deciding on the rendering intent is easy either)

There is also a tone mapping tool here: https://github.com/awxkee/gainforge. It's a bit messy and some of the naming is outdated, but in practice it can successfully perform tone mapping with a bit of effort for everything give or take. I personally haven't worked with scRGB but don't expect much difference to any other HDR colorspaces

the big thing for me is to utilize as much of JXLs capabilities as possible such as encoding a higher quality image like an HDR wide gamut image, so if you need an SDR one, you can just request that in the client.

When I first implemented libjxl it was dreadfully slow so I had to come up with workarounds for almost everything. Many things have changed since then, but libjxl tone mapping during end-to-end decoding still causes roughly a 2x slowdown compared to my previous workaround, so I still prefer avoid this

interesting, for me it's a fairly major feature since "one and done" images are the way to an HDR first future

I think it would be nice for OS to go the same way iOS did, where you can simply tag an image as PQ P3 or PQ BT.2100 and don't worry about tone mapping at all, since the OS/driver handles it, and doing so is very easy. They've supported this since iOS 13, so it has worked "right" for a long time. On the other hand, I have experience with Android and it's a nightmare. While it technically supports tagging PQ BT.2020 on RGBA8888 ( interesting why 8-bit HDR is strictly supported? ), but it randomly panics if you try to tag RGBA1010102 or RGBAF16 as an HDR image. So it's just easier tonemap just completely everything on android than messing with this ( at least it was the state when I was actively developing this ). Considering that libjxl isn't very fast and many Android devices aren’t very fast either, it’s also preferable to take the fastest possible approach.

interesting experience, I have found that neither android nor IOS particularly handle mixing great, but found that android did better. I suppose surfaceflinger might be a bit panicky depending on the rom and hardware it's on top of [hmmmm](https://cdn.discordapp.com/emojis/790799062735257612.webp?size=48&animated=true&name=hmmmm&lossless=true)

I think to me iOS approach "Press F to win" even this "win" is not completely ideal a way better than "we could do something perfect, but you won't guess how to use this". Ofc those panics which was "This is not possible to enhance an image" ( whatever that means )

Well I wanted to say this it was completely undocumented behavior that time but now it is https://developer.android.com/reference/android/graphics/Bitmap#setColorSpace(android.graphics.ColorSpace)

Except that this still doesn't explain why it was supporting 8-bit PQ but not packed 10-bit or f16

If you think of it as xyY, rgb(4,0,0) has the same chromaticity as rgb(1,0,0). So it will stay the same red (no more saturated), but be much brighter

Looking at an OkLch picker, it seems to also mosty agree that multiplying each linear channel by the same amount keeps the same hue, but not luma or chroma

gamut includes luminance to at least some extent

Adobe RGB is capable of reds that sRGB isn’t, despite their red primaries having the same chromaticity

I can't see anything about Adobe RGB HDR from it's wikipedia description, though at least it's white point luminance is set to double that of sRGB

Perhaps the reds look redder in contrast to the expanded cyan and green range, but by itself I can't imagine the red looks any more saturated

I meant brighter even in relative terms (both of them with the same white point)

if you want bright red, Adobe RGB lets it be more saturated

in normalised XYZ (white has Y=1), Adobe RGB red is (0.57667, 0.29734, 0.02703), whereas sRGB red is (0.4124, 0.2126, 0.0193)

(and here is a verification that those indeed have the same chromaticity) ``` Welcome to Rakudo™ v2024.09. Implementing the Raku® Programming Language v6.d. Built on MoarVM version 2024.09. To exit type 'exit' or '^D' [0] > sub chromaticity(@XYZ) {@XYZ[^2] «/» [+] @XYZ} &chromaticity [1] > chromaticity [0.57667, 0.29734, 0.02703] (0.640005 0.329996) [2] > chromaticity [0.4124, 0.2126, 0.0193] (0.640074 0.329971) [3] > ```

Woah what is that tool?

Raku is what used to be Perl 6, and Rakudo is its main implementation

this is its REPL

this session defines a `chromaticity` function that takes an array `@XYZ` of coordinates and returns the first two values (`@XYZ[^2]`, so X and Y) each divided by the total (`[+] @XYZ`)

the matlab/octave equivalent would be: ```matlab octave:1> function chromaticity(xyz) chromaticity = xyz(1:2) / sum(xyz) endfunction octave:2> chromaticity([0.57667, 0.29734, 0.02703]) chromaticity = 0.6400 0.3300 octave:3> chromaticity([0.4124, 0.2126, 0.0193]) chromaticity = 0.6401 0.3300 ```

python (one option): ```pycon >>> def chromaticity(xyz): return tuple(x / sum(xyz) for x in xyz[:2]) ... >>> chromaticity([0.57667, 0.29734, 0.02703]) (0.6400048832460268, 0.3299964485483441) >>> chromaticity([0.4124, 0.2126, 0.0193]) (0.6400744994567747, 0.32997051063169336) ```

man, I've been meaning to learn perl for a long time now, now I have a good reason

I see it now, it must be brighter to offset the green basis that is further away from the white point. Though still, the same chromaticity is the same red saturation

if you're fine with a relative luminance below 21.26%, sure; between 21.26% and 29.73%, sRGB will need to sacrifice saturation whereas Adobe RGB won't

so it’s capable of more [colourful](https://en.wikipedia.org/wiki/Colorfulness) reds / reds with higher chroma

it can be worth noting that Perl 5 and Raku, while sharing some of their “spirit”, are quite different languages (Raku is arguably the more “beautiful” language, but its implementation and libraries are not as mature; meanwhile, Perl 5 has a wide, established ecosystem and is probably the more practical option but it definitely has its quirks)

That makes sense

So it's not inherently more colourful, but can hold onto saturation for longer

While they could find a match with unbounded brightness, if I understand you correctly when bound by the proportions of the white point (nearly always) sRGB red is dimmer than Adobe RGB red, and to match brightness it must sacrifice saturation

almost: colourfulness is distinct from saturation, and same (non-zero) saturation with higher brightness => higher colourfulness

I guess in proper terms, their matches have the same colourfulness until sRGB hits its limit, past which sRGB sacrifices saturation which also degrades colourfulness

unless I messed up somewhere, here is the chromaticity of sRGB / Adobe RGB red at full saturation (right), and the chromaticity of the red that sRGB must fall back to if it wants to match the max brightness of Adobe RGB red

(it is entirely possible that I did mess up)

(first: find the relative amounts of sRGB red / white to match the target luminance, then plot that mixture alongside the unmixed red)

A fairly significant sacrifice

ah, the diagram exaggerates the difference a little because the apparent location of “white” seems to be D50 instead of D65

here is D65

one can also look in 3D

are you using Wolfram Language for all of these?

I've read about it, it's fascinating. It's a shame I can't just download it and try it

yep; the 3D plot is the output of: ```wl ChromaticityPlot3D[{"sRGB", "AdobeRGB"}] ```

aw, these don't work in Wolfram Alpha

Do we have an ICC profile for XYB laying around anywhere? I was thinking of using it to examine individual channel quality in Krita, just for more testing of the B quant table stuff

simply `cjpegli --xyb` then `exiftool -icc_profile -b -w xyb.icc in.jpg`

That's only for decoding IIRC

we haven’t made a profile going the other direction

wait, wdym other direction ?

the above ICC "translates" XYB to sRGB (?), pixel data stored as XYB you want ICC for sRGB → XYB, pixel data stored as sRGB ?

like applying these 2 ICCs back-to-back should not change anything to the pixel colors I guess

Context: https://discord.com/channels/794206087879852103/794206170445119489/1374705416927187054

You can encode test profile like so https://github.com/awxkee/moxcms/blob/xyb/app/src/xyb.rs this is a bit bruteforce but it's fine for testing purposes. I have no idea about exact XYB bounds or even if used conversion is even correct one. However, as a quick sketch of "how to build a LUT profile fast" it shouldn’t be too far.

https://www.dpreview.com/forums/threads/does-anybody-know-where-to-find-the-new-apple-cmfs.4831731/ > Apples has announced a new XDR display. They have also announced that they intend to standardize a new set of color matching functions with the CIE. <:garfieldsurprised:823250154319773727> have they?

Yeah, I don't think the standard is published, though they certainly have a plan

https://www.apple.com/studio-display-xdr/pdf/Studio_Display_XDR_Technology_Overview_White_Paper.pdf

https://support.apple.com/en-us/105101

I'm not gonna lie, I still don't understand what XDR actually is on a technical level. Someone explained it to me as a traditional transfer function with 12-bit bit depth, but as far as I can tell that's not right?

I think they did some tuning to avoid melting customers eyes looking on that display relatively bright display for a long time, though everything else is pure marketing