JPEG XL

first

Second

https://en.m.wikipedia.org/wiki/LMS_color_space

Not only that <@386612331288723469>, but the transformation from one gamut to another is a linear transformation

so if I have colors represented in sRGB between 0.0 and 1.0, and have accurate out-of-gamut colors represented by having numbers less than 0.0 or more than 1.0, then I can take that RGB weight vector, and multiply it by a matrix, and get a vector in another space, say, BT.2020's gamut

So it’s just a change of basis?

that's exactly what it is

choosing different primaries is literally a change of basis

So that’s why they’re called matrix coefficients

matrix coefficients are something else

XYB is basically: Y is M+L (luma-ish, but a bit more yellowish) X is M-L (red-green chroma) B is S (but usually encoded as B-Y, so blue-yellow chroma)

Nevermind LMAO

matrix coefficients refers to YCbCr <-> RGB

which is also a linear transform

So kinda similar?

just a different one

So it’s a linear transform from LMS?

"matrix, primaries, and transfer" are the three things in cICP matrix refers to the YCbCr matrix, which is just a different representation of the RGB data. It's the same data. JXL doesn't use matrix because it doesn't deal with YCbCr outside of restructured jpegs, which uses the jpeg matrix

"primaries" refers to the choice of primaries and white point, or gamut

[XYB] doesn’t really have a concept of a gamut or range or midpoints?

XYB is approsimately biased LMS but not quite

Not quite linear, there is also a transfer function involved that models how cone activation is not linear

Is it just arbitrary values in no specific scale/range?

if you start with linear light colors with rec709, the way you get XYB is by multiplying the [r,g,b] vector by a matrix to convert it to "approximately lms" and then applying a biased cubc transfer

Grayscale colors have X and B (or rather B-Y) at zero

Does JXL always store B as B-Y?

it doesn't really have one. It's defined in the spec to be a linear transform of rec709 colors. But remember that colors can be out of range, and to transform between two spaces is also linear. so it could have been defined as a linear transform of rec2020 primaries, with a different matrix, and actually just be the same definition

https://discord.com/channels/794206087879852103/824000991891554375/1282281959946584186

i.e. if you take the rec709 -> XYB matrix, compose it with the rec2020 -> rec709 matrix, you get a rec2020 -> XYB matrix

which is equally valid to be used directly

this is also why it's very easy to decode XYB to any primaries, because you figure out the XYB -> rec709 matrix and the rec709 -> foo matrix, and then compose the matrices, so you can then just use that new one to decode XYB->foo

without any extra computing

cause you only need to compute the conversion matrix once, and then you use it for every pixel

These are some slices, four different values of Y, with X on the horizontal axis and B on the vertical one

for example, the conversion matrix to convert colors in sRGB to colors in BT2020 is this: ``` [[0.6273918, 0.32928905, 0.043318883], [0.06910729, 0.919537, 0.01135542], [0.01638554, 0.0880046, 0.89560986]] ```

like it's just this matrix

if `(r, g, b)` is a vector with colors in the rec709 space, and you multiply by this matrix, you get a new vector, which is the same color, but represented in the rec2020 space

it's a change of basis

I'm so so glad you called it a "change of basis" cause that really hits the concept on the head

this is the change of basis matrix for rec709 -> rec2020

note: only works with linearized, i.e. not "gamma"-encoded values

Yes, I should specify, this only works in *linear light*

Can you just apply the EOTF?

yes, that's called linearizing

but if you do not do that, none of what I said works

all of what I said about primaries is a linear-light-specific thing

generally to do any kind of color space transitioning you have to linearize everything first

the only operation i'm aware of that "just works" in gamma space is scaling, i.e. multiplying by `a` in gamma space is equivalent to multiplying by some `f(a)` in linear space

Is XYB linear of gamma?

also not true

XYB is defined as you take rec709 linear, transform it, and then apply an almost-cubic transfer

more specifically, if the "gamma space" is actually a pure gamma curve, sure

that's why i didn't put gamma in quotes

because `(ab)^x = a^x b^x`

ah, I missed that

most spaces are not actually those true gamma curves though

sRGB is notably *NOT* equivalent to a pure gamma curve

and it's the most common space

neither is rec709, rec601, or rec2020

or PQ

actually nothing really is

except DCI ig

afaik when doing color space math, you usually use 2.4 for bt.709

nah

bt709 has a linear segment like srgb

that's the OETF

what you're describing is bt.1886, which is supposed to be how you invert bt709 for the purpose of *display*

but if you're inverting bt.709 for the purpose of *encoding* then you should invert it by using the inverse of the OETF

because the EOTF and OETF for bt709 are not inverses of each other

the EOTF is specified in bt.1886

and the OETF is specified in bt.709

a calibrated (oled or similar) bt.709 display is calibrated to 2.4 gamma, so to be clear i'm only talking about display-referred (?) math related to that

if you take a video that's encoded in bt709 (like, say, most dvds) and try to do any kind of arithmetic on it though, like extract a frame, convert to srgb, edit the image, etc. then ideally you just invert the OETF

this is my code for it (fairly basic, I know)

```java public static TransferFunction TF_BT709 = new TransferFunction() { @Override public double fromLinear(double f) { if (f < 0.018053968510807807336D) return 4.5D * f; else return 1.0992968268094429403D * Math.pow(f, 0.45D) - 0.0992968268094429403D; } @Override public double toLinear(double f) { if (f < 0.081242858298635133011D) return f * 0.22222222222222222222D; else return Math.pow((f + 0.0992968268094429403D) * 0.90967241568627260377D, 2.2222222222222222222D); } }; ```

it has a linear segment just like SRGB

(values taken from H.273)

but that's not going to give you the same absolute color between bt.709 and srgb on a properly calibrated display each

When doing image processing, it kind of depends on what you're doing what will be the best space to do it in. Linear light models the physics of photons, so if you're e.g. resampling it makes the most sense to do that. But transfer functions model perception, so if you're e.g. trying to make a nice-looking gradient, a perceptual space will work better than doing just interpolation in linear space.

that's actually not mentioned in Rec 709

https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.709-6-201506-I!!PDF-E.pdf

(bt709 is a free pdf from itu.int)

Is any of this annoying edge cases in jxl ?

It does say tihs

> In typical production practice the encoding function of image sources is adjusted so that the final picture has the > desired look, as viewed on a reference monitor having the reference decoding function of Recommendation > ITU-R BT.1886, in the reference viewing environment defined in Recommendation ITU-R BT.2035.

but this is straight up a statement that production practice ignores the spec

(bt.1886 is just gamma2.4)

right, that's technically specified in bt.2035 along with peak white being 100 nits

However, rec 1886 does specifically say that if program interchange is not required, they suggest an alternative EOTF to use

(the alternative they suggest is the inverse of the one in rec709 btw)

> that an alternative EOTF may be used in some cases where programme interchange is not required, a suggested equation is contained in informative Appendix 1.

but the "regular" bt.1886 eotf is the one that's recommended for HDTV production, and that is what's used in hollywood etc.

It makes it seem like rec709 is entirely useless doesn't it <:KEK:1283989161111715913>

idk, is the OETF actually used by cameras?

sounds a lot lke LAB

The concept is quite similar, yes.

Main difference is Lab was created by letting people compare relatively large patches of colors to try to make it perceptually uniform, while XYB is more suitable for pixel-sized patches of color

https://discord.com/channels/794206087879852103/806898911091753051/1288787358740779028 > you also realize here that "white" is relative. There's no perfect concept of pure white, so you have to pick one. The most common choice is the color that an object at a temperature of 6500 kelvin would radiate, or D65. nit: since D65 is meant to be daylight, it has a slight green tint off of the ideal black body radiator of the same temperature.

https://en.m.wikipedia.org/wiki/DCI-P3#/media/File%3ACIE1931xy_gamut_comparison_of_sRGB_P3_Rec2020.svg

not even sure it is, considering how common it is to treat sRGB as gamma 2.2 on both the encode and decode side

for decoding, yes, as specified in bt.1886

note that the red primary of p3 is just barely outside of the bt.2020 gamut

probably doesn't really matter in practice but i do find it interesting that it's technically not a subset

(despite hdr content commonly being "p3 in a bt.2020 container")

No. Unless it's live TV capture, which is the only place where the scene-referred Bt.709 OETF is used.

No, absolutely not.

I mean, that's often just not correct.

The bt.709 OETF is just a hack to boost dark areas for direct camera to screen live TV, and is probably normally not even used anymore for many years now.

Since we now have better more advanced real-time processing, and customers have better TVs.

Very uncommon for anything that applies DSP to the video capture. Very common for old analog TV cameras.

Yes, though I doubt that the difference between pure P3 red and the closest you can get to that in Rec2020 is very big. While the difference between pure Rec2020 red and the closest P3 approximation of that is probably noticeable.

I wonder if there is something somewhere that can show that can render a chromaticity diagram close to correctly, say using many lasers that each produce a specific spectral color and together form a polygon that fits the curve well.

Even if you could you can’t take a picture of it

I would just like to see what is still missing from rec2020

https://youtu.be/0XTgz5Z1bhE

So you're saying for most purposes the thing in H.273 should be ignored

for encoding? yes for decoding bt.709, h.273 recommends bt.1886 anyway

for rec709 tagged content, yea

hm

surprised he didn't mention The Matrix, which is well-known to be mastered in bt.2020 gamut, and has plenty of greens exceeding P3.

the greenest movie anyone has ever made

I think that's mostly the excessively green-tinted Blu-ray grading

the UHD blu-ray looks more natural

wait a sec and ill show you something crazy

top: original theatrical bottom: blu-ray

scene-referred anything is just a terrible idea in the modern world imo

checks out

lol

very green

for the original, they made it a bit greenish inside the matrix with set design and lighting

for the sequels, they used digital color grading and were like "HOLY SHIT WE CAN MAKE IT SO GREEN"

so when the first movie was re-released they changed it to match the sequels

I see

I found the sequels quite meh, story-wise

but I watched them a very long time ago

soundtrack is amazing, though

I don’t actually remember whether I’ve seen The Matrix

> Friends don’t let friends say “gamma.” https://hg2dc.com/2019/05/28/question-6/ man I hate the term gamma we should let it die

My developed photos after 30 dreadful minutes of trying to figure out how Darktable works

when you linearize images you typically want to *undo* the encoding function, not rendering it out. This isn't always an important distinction, but if you use sRGB it is, because rendering it out actually causes a somewhat harsh degree of dataloss

don't get me started on this <:PepeHands:808829977608323112>

the spec is the spec, but no one cares about the spec, now we have a bunch of derivative specs with inaccuracies

sRGB needs to hurry up and die. It's ecosystem is such a mess it needs to be taken out behind the shed and put down

gamma 2.2 being the most common standard for displays has good reasons

So OETF^-1 ?

sure, but we don't tag stuff as gamma 2.2 we tag stuff as sRGB, but half the time encode it as gamma 2.2, and then displays do really funky shit shit as well, why? I dunno, hell if I know, I don't think anyone knows

I tag my images as gamma 2.2 🙂

based as fuck

why can't more people [pepehands](https://cdn.discordapp.com/emojis/1075509930502664302.webp?size=48&quality=lossless&name=pepehands)

the issue is more so monitors

But it really is a terrible mess. The future is proper color management, including transfer function, throughout the system. But for that you need properly tagged images in the first place...

Well, that can be fixed by the consumer with changing one setting in the OS ideally...

it would be nice if most people could do that but 99% will just be "well this looks weird"

imagine if displays could say what they did with edid

yeah

will happen over time

but mistagged images will stay mistagged forever 💀

for me, the biggest thing is jack holm's quote in the massives aces thread > In most cases SDR video displays should be calibrated to the ITU-R BT.1886 EOTF.

This seems pretty cut and dry that it's time to bounce lol

are there that many mistagged images? my impression is that lack of monitor profiles is a greater problem

(or of taking it into account)

In the past at least I know a lot of programs Photoshop included would actually encode them using the 2.2 encoding instead of SRGB 2 part but tag it as an SRGB

The displats are for sure still an issue, but I'm still not 100% convinced that Displays are supposed to use a peer 2.2 function. I have been convinced of it, but I'm not 100% sure. I do wish I could read the actual specification myself. The clips I've seen are pretty convincing, but without the full context I obviously can't say for sure.

there’s an argument to be made that if the author created the image as an sRGB file and it looked fine to them, maybe, in some sense, it really is an sRGB image

they applied a “g2.2 interpreted as sRGB” filter to the image and they liked the result

(dare I actually make that argument? I’m not sure)

I agree with that assesment as far as the creative side goes, Does not really apply for conversion (IE screenshot from a video rendered to gamma2.2 but encoded as sRGB)

but if it's rendered gamma 2.2 decoded as srgb then it's how the creator intended

so it's fine

I'm not sure I understand, can you reword that?

it might be wrong(mistagged) but it's not incorrect

what's incorrect is every display panel being very different and not profiled

actually causing images to look different

to be sRGB, it needs to be encoded with the piecewise function. This is important when doing the sRGB -> Linear, because you undo the piecewise function. if you do 2.2 -> Linear using the sRGB function it will cause dataloss, which will then be compounded when converting back to 2.2 or sRGB

ofc display's decode with a pure 2.2, but we don't do that when doing sRGB-> LInear because of the data loss

hmm obviously if you have a tool that's supposed to capture and it's changing the image, it's wrong and incorrect

man I hate colour, they had to go and make everything so confusing T.T

just calibrate and profile your display

and tag your screenshots with the display profile

i have auto color management on so desktop is srgb

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

but don’t screenshots still capture the result of converting that to the display’s colorspace?

depends on the app

windows ACM doesnt

i.e. windows assumes non-tagged stuff is sRGB and converts it from sRGB to the display space to make it look correct, and then the screenshot tool captures that

for non color managed apps, I don't have to do anything

for color managed apps like firefox then it will be incorrect

ah, the screenshot tool gets the pixels earlier in the chain?

yeah, it's magic to me

many applications can handle screenshotting themselves

windows photo app the only one that can do cross-monitor and screenshotting it with anything captures original color

windows by itself doesn't do any color management (except with "advanced color", i.e. sdr auto color management or hdr enabled) color management on windows is done by the applications transforming the pixels before rendering them

though that sounds like it might be an exception to that? idk

oh i missed that you did talk about having ACM enabled

that happens in the DWM or via a color space transform in the GPU display pipeline

yeah I imagine it's in gpu compositing

you can actually mess with that (the DWM case) by messing with the shaders, see <https://github.com/ledoge/dwm_eotf>

the default to a 2.4 curve? [Hmm](https://cdn.discordapp.com/emojis/1113499891314991275.webp?size=48&quality=lossless&name=Hmm)

oh yeah, that makes sense, it's just removing the linear section

just a personal preference because i don't really "believe" in 2.2 as a standard (whereas 2.4 is at least the standard for video)

yeah gamma is subjective

and relative

not quite how it works here. as 2.2 2.4 etc. are actually hard coded standards. In this case it's talking about how to transform sRGB -> Linear -> PQ/scRGB/HLG etc

this is only for eotf

note this is talking about transfer, once again the curse of the term gamma is striking hard

note they also don't really have the right terminology as the EOTF for sRGB would technically be 2.2, what windows does when converting to HDR is use the inverse sRGB encoding function

sRGB doesn't define a real eotf, but it does define the reference display as a pure 2.2

"they" is me btw

time to remove gamma from the readme [av1_pepegun](https://cdn.discordapp.com/emojis/659513552033415188.webp?size=48&quality=lossless&name=av1_pepegun)

gamma is a horrible term, see

it means too many things, and it's best to be explicit

idk i guess i put that there to make it easier to understand for people who don't know what an EOTF is

and it is a gamma function

how about i rewrite it to EOTF ("gamma")

not like you can make it anything but gamma

nuke gamma from oblivion, there is a reason why specs like sRGB use the term transfer function instead

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

because it's not using gamma?

i think "gamma EOTF" is a meaningful term though

"gamma" is a catch all term when talking about luminance... stuff

not really

I mean, it would be better to say "changes linearization function from the inverse OETF to a pure power..." in this case

or you can say gamma

that's just yap

There is a reason why gamma isn't a very often used term professionally any more, it's vague and has no proper definition, if it is used at all, it should only be used after the proper terms like "transfer function"

but this is not so important as changing " the sRGB EOTF is effectively replaced with a "normal" gamma EOTF." because they don't use the "sRGB OETF" they use the inverse sRGB OETF

semantics 🤷 waste of time

it's actually not because as I said it's outright wrong

eotf should be done in the vcgt anyway 🤷

the "implied EOTF" in sRGB is a pure 2.2

yeah but what it was doesnt matter because the tool replaces it

<:clueless:1186118225046540309>

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

why would the piecewise thing not be an EOTF when it's defined in the section of the standard called "Transformation from RGB values to CIE 1931 XYZ values"

you my friend have been hit with, "what does the spec say, but which spec"

IEC 61966-2-1-1999.pdf

do they even mention EOTF in the section? because keep in mind the EOTF is what the display does

as troy sobotka elegantly said "Displays have EOTFs. sRGB is an OECF / OETF, built atop of the notion of implicit management chains."

it dont look like a pure 2.2

that's why when decoding sRGB to linear, we use the inverse OETF, because the "implied EOTF" as per the spec is gamma 2.2

they don't call it anything, they just say that you calculate R' G' B' from R G B via the piecewise function

right, but in the explicit steps to go from RGB to XYZ they most certainly use the piecewise function

and that's exactly what happens in an ICC color managed workflow

so while i can see how you can argue purely from the spec that a display should be 2.2, i don't think it makes any sense in practice

yes, as I said, when converting stuff around, we use the encoding function as a basis

it's not how ICC color management works and it's not how windows works either (as it uses the piecewise function in advanced color)

and (can't verify this myself) apparently the "reference" mode on apple displays also uses the piecewise function

there is a reason why sRGB is such debtated topics among nearly all color groups, here is an absolutely phenomenal forumn thread on the topic by some of some really great colourists and even this is a thread over 170 posts https://community.acescentral.com/t/srgb-piece-wise-eotf-vs-pure-gamma/

but in the end, when undoing sRGB you "undo" the encoding function. when a display "renders" the image it uses pure 2.2

"but wait, that sounds stupid, and this will cause a mismatch won't it" Yes. yes it does, and it's explicitly acknowledged.

again, i can see why you can make that argument based on the spec, but with how the practical implementations have worked for decades i don't think you can argue that it's correct specifically: if you have an sRGB image, and you view it through ICC color managed software, the result looks the same as if you took the "raw" pixels with no color management and sent them to a display that uses the piecewise EOTF

Properly managed displays use the pure 2.2 EOTF. Most displays out there OOB use the pure 2.2 EOTF, not all, it's a minor majority in my experience.

if all displays just used one eotf, or the other eotf, then the issue of sRGB wouldn't be so massive as it is now, hence the talk about improperly tagged displays

um no?

filmlight's daniel had a good talk about stuff like this https://youtu.be/NzhUzeNUBuM?t=985

displaycal made my profile use srgb 🤷

particularly this

ok, but according to the sRGB spec, it's a pure 2.2 function, so that would be accurate

god I hate the term gamma [megareee](https://cdn.discordapp.com/emojis/1075610558805594162.webp?size=48&quality=lossless&name=megareee)

but according to srgb spec it's piecewise

the encoding function, not decoding function

as I said, there is a mismatch between them

the sRGB specification *explicitly* defines seperate encoding and decoding, and as I said, acknowledges the mismatch between them

https://www.color.org/chardata/rgb/srgb.pdf

🤷

note that the sRGB specification was designed to be compatible with video, which at the time was a 2.4 power function as again daniele says > If we agree that Video EOTF is 2.4 then sRGB EOTF can only be 2.2 Gamma, Annex B will describe this in greater detail: https://community.acescentral.com/t/srgb-piece-wise-eotf-vs-pure-gamma/4024/169

also my profile doesnt look like gamma 2.2

and now we are back to 3rd party re-written specs

ofc all of this would be different if sRGB spec actually defined an EOTF which it does not.

<:Poggers:805392625934663710> https://en.wikipedia.org/wiki/ScRGB

the most chad of colorspaces

i don't understand how the function used in converting from RGB to XYZ could *not* be an EOTF

you don't need to worry about linearization if you are already linear [av1_chad](https://cdn.discordapp.com/emojis/862625638238257183.webp?size=48&quality=lossless&name=av1_chad)

because most typically an EOTF is what the display does to display the video

quite literally the electrical to optical transfer function

no it's what you do to a signal for the display to create the color

in which case, as per the sRGB spec, the display uses a pure 2.2

ok sure but we dont care about what the display physically does

on its own

uh what? That's literally the vast majority of the issue here...

then what is the RGB -> XYZ conversion supposed to be used for?

RGB to XYZ is just that. just like encoded RGB -> Linear RGB

this is why we use the 2 peice function for that

well in the end, since the sRGB spec doesn't specify an EOTF, we can just, most accurately, say there is no EOTF with sRGB

whether or not one is implied or not is irrelevant

the point is, when converting sRGB to linear, you do not do it the same way displays do it, which is a point of confusion

you mean rendered/encoded to gamma 2.2 and tagged as sRGB...

i can see the point you're making there (it not defining the function used by the display), but i don't think it makes sense to define "EOTF" as something narrower than it literally means. that just seems wrong

I believe so

No, creators do that because most displays are gamma 2.2, and gamma 2.2 decoded as sRGB looks better than the other way around.

EOTF is that, an EOTF. quite literally the function used to convert electrical signals into optical signals. This is the process that happens in the TV/Display

I just re-iterated what spider-mario said, how if it's what the creator was seeing then it doesn't matter

the creator was probably working on a gamma 2.2 display as well

I suppose there could be an argument for saying that any conversion to "linear" is a conversion to an optical signal. However I have only seen it used in reference to displays

but a full color management pipeline in the future will decode sRGB correctly, and the picture will look wrong

but if they made it to not look wrong to them then it wont look wrong to others

often times where there is no mismatch, it *can* be used to convert to linear, but the intent is for it to be used via the display as far as I am aware, but then again, I haven't actually ever seen it as a hard definition in a proper specification...

that's what i was trying to say, yeah, but now i'm not entirely sure if that's correct

but the image is incorrectly tagged, which does not matter nowadays because sRGB images are usually displayed nowadays, but this will probably change in the future

Imagine if color people would just properly define terms in publically availible documents

well they wont be changing how it is rendered

we know they wont

they will

proof?

new Android versions are already doing it

iirc android properly uses the inverse sRGB oetf for linearization unless tagged otherwise

Firefox as well, although it just targets sRGB because it doesn't know what the target display uses

or you can profile your display

that was always a problem

like, if I load one of my images correctly tagged as gamma 2.2 in Firefox, it will convert it to sRGB and it will look wrong

The future is full color management from display to OS to applications

and (iirc) there's an option to treat video as being sRGB-encoded, which is on by default

in practice that just means that if you don't have an icc profile, the decoded RGB values from the video are passed through without doing color management on them

who encodes video as sRGB unless it's screen cap [av1_monkastop](https://cdn.discordapp.com/emojis/720662879367332001.webp?size=48&quality=lossless&name=av1_monkastop)

I think it comes with the newest Windows as well, you can actually easily set your display to DCI P3 there for example, without loading a display ICC profile...

firefox still doesnt do anything for video

and when you turn that setting off, it uses the inverse of the BT.709 OETF iirc

which is terrible

man PQ can't come soon enough

no, all of you need to profile your display

you know if there is an option to set my display trc?

well, I don't use Firefox anyway...

pq wont do shit if your panel is completely wrong anyway which it is because of the nature of displays

use an icc profile? not sure i understand the question

in Firefox I mean

there is a lot less shenaigans going on though [av1_yep](https://cdn.discordapp.com/emojis/721359241113370664.webp?size=48&quality=lossless&name=av1_yep)

or can Firefox read my display ICC under Linux?

it should be able to? if not you can set it manually in about:config

you should be able to manually set the icc profile

hmm

I have never done any system-wide color management...

All I know is that I have to set target-trc=gamma2.2 in mpv config to make my videos look god

the shenanigans dont matter at all when faced with the bigger problem

the shenanigans are pretty much the biggest problem ATM

tonemapping do be a close second tho [av1_dogelol](https://cdn.discordapp.com/emojis/867794291652558888.webp?size=48&quality=lossless&name=av1_dogelol)

mpv should be able to generate using display profile

The YouTube app on Android 13 does gamma correction to my display.

noticed some weeks ago

that's dope

man monitors should at least use 1886 <:SadCheems:890866831047417898>

related question: with the new "SDR dimming" or whatever they call the improved HDR support on android, does e.g. starting an hdr video in youtube now not affect the rest of the display?

i like (?) how i can tell that a video is in hdr on my phone because the appearence of the entire screen slightly shifts

it should

last I checked it was pretty bad while multitasking

you get bt1886 when you ~~profile~~calibrate your display

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

yeah that's what i'm saying

otherwise everything else you do doesnt matter

Here is to hoping that KDE unfucks their SDR on HDR when colormanagement protocol lands

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

Florian Höch suggests 2.2 for general use https://sourceforge.net/p/dispcalgui/discussion/932493/thread/58431a55/#1d1b

I use default video preset

(with all that said, I picked sRGB, but I often wonder whether that was the right choice)

I think in practice doesn't matter

oh, it matters a lot

someone in this thread https://hub.displaycal.net/forums/topic/srgb-vs-2-2/ originally postulated that “For most users the effect will not be visible.”, but then posted another response saying: > I am wrong 🙂 > > I take back what I just said about discernabke differences between true sRGB and G2.2. I just went through the exercise I described in prev post and softproofing G2.2 against true sRGB creates a readily visibke diff! > > So I am wrong according to my own logic

(it’s rare to see people so readily admit their errors on the internet and I admire that)

sRGB and gamma 2.2 looks almost the same in graphs, because those are mapped on linear light, making the curves look very different from how we actually perceive them.

it's in the dark regions where the difference between gamma 2.2 and sRGB is huge

I was thinking along the lines of the latest post in the thread

the display is also profiled so it doesn't matter

like you open a video and it's 1886 with 2.4

I actually havent looked at the code for argyll so I don't know what it means when it says gamma 2.2 vs sRGB. but I assume it is talking about whether your display uses the peicewise or the pure function

iirc argyll is entirely software gpu based calibration

sRGB vs 2.2 is extremely visible when looking at stuff like nighttime content, again back to this master class of a forumn thread https://community.acescentral.com/t/srgb-piece-wise-eotf-vs-pure-gamma/4024/118 this scenario is an intentionally exaggerated issue due to my selective screenshotting, but you can see a massive discrepancy

sRGB is gamma 2.4 with a linear part in the dark area, that together approximates gamma 2.2

for the encode function, decode (Display side) is a pure 2.2 function as per spec

but many displays use the peicewise function inverted

sRGB EOTF basically boosts severely boosts dark content below ~1 nits. sRGB OETF crushes dark areas when decoded as gamma 2.2

wait, really??

yes

wtf

see here

the encoding mismatch is because 8bit pipelines would kill a bunch of the data

this is why the mismatch exists and in their own words "the advantages of optimising encoding outweight the disadvantages of this mismatch

which would have been true were we still using CRTs

*this is why* it's better to encode your image/video in a pure 2.2 function, when you can properly tag it. because it's a 1:1 ratio, no dataloss in a 2.2 display pipeline. This is the best case scenario because with an 2.2 monitor (as per sRGB spec). When you use the inverse sRGB OETF on an pure 2.2 encoded image, it won't look great, but it's still usable. This won't be an issue in any managed pipeline however.

note with what it is, it's not like it really matters, make sure to calibrate when you can, it's around slim majority for displays to be a pure 2.2 EOTF so both users need to be accomodated for

people use srgb mode?

~~not willingly~~

I spent 2 hours in RawTherapee the other day just trying to figure out the UI. Eventually I made an ACES 16 bit JXL file (From a PNG) with probably too much denoising and not enough saturation

I need to find a simple color grading tool that works with touch and mouse primairly [av1_dogelol](https://cdn.discordapp.com/emojis/867794291652558888.webp?size=48&quality=lossless&name=av1_dogelol)

So are ICC color profiles just unusable useless garbage then?

Is it even possible for them to be used correctly? :(

if you have a properly calibrated display, properly colormanaged application/compositor, and finally a properly tagged image, then you are fine. if any one thing is not done properly, then you will get wrong colours

FWIW, from my experience, depending on the situation, some of those three may have a different “weight” on the outcome. The more they stray from sRGB standard, the more. Again, from experience, the one that most often than not matters least is “properly calibrated display”.

Maybe the other way of saying it would be: just like one can perform colour correction “by the numbers” on a black and white monitor, one can produce correct colours on a wildly miscalibrated display. The lack of hardware should not stop one trying.

lack of uniformity can be a greater problem for example

if you profile the centre of the display, and therefore output correct colours there, but the edges of the screen have a cooler colour temperature, that’s not ideal

This is especially a problem on VA panels. I've been looking in to adding a screen filter that darkens the edges to a uniform level with my display

the only solution is oled and co [av1_chad](https://cdn.discordapp.com/emojis/862625638238257183.webp?size=48&quality=lossless&name=av1_chad)

mini-LED / microLED ftw

Wouldn't necessarily solve this issue as the LCD panel type producing off axis irregularities is totally independent of the backlight. The problem manifests itself the most on single blocks of color. The display manufacturer would have to purposefully dim/brighten the outer backlights on single color images and perform some basic level of signal analysis

I just meant that as response to “the only solution is oled and co”

But at the same time VA exists because it has much deeper blacks compared to IPS, which would be kind of pointless with microled

I prefer them in principle for not having to worry about burn-in

Yeah burn in scares me

VA is a downgrade in every other aspect to IPS

that's very fair. qled seemed promissing, I think it was qled, Im not sure any more. too many terms.

to be entirely fair, I’m probably overstating the issue

still, it’s always a bit at the back of my mind

although I do sometimes worry about uneven mini LED aging as well

I wonder how much of a problem it is

oled burning is still an issue, unless you run are talking about the switch's panel, I don't know what black magic they do, but it's insane

My phone is 8 years old, still no burn in

do you have always on display?

Not enabled

Color doesn't exist. Y'all are just hallucinating and crazy

based

images aren't real, it's just a bunch of numbers in a wire

no one in this group is real, it's all a psyop

the government is hiding the true next generation image format, jpeg xl is a coverup for a larger conspiracy

I should be careful about engaging in sarcasm of the sort, lest it be interpreted as official statements

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

Official statement from official JPXL dev: color is government hoax

Like, the XL files, I want to encode... With murder and skully

If I have RGB data, and I have R_alpha, G_alpha, and B_alpha, and transform the RGB data to YCoCg, would it be valid and useful to transform the alpha data in the same way to get Y_alpha, Co_alpha, and Cg_alpha? Obviously it's reversible so you could just go back to RGB if needed, but would the YCoCg data be sensible? Would compositing in YCoCg give a sensible result?

in the case when Ar = Ag = Ab = 1, transforming in the same way will yield Ay = 1 but Aco = Acg = 0 which isn't desirable; it should be fully opaque after the transform but it's not

I think my strategy to answer this would be to implement blending with the two approaches in a CAS like Sage and see if the resulting expressions are equivalent i.e. “is `inv_ycocg(blend(ycocg(pixel), ycocg(alphas))) == blend(pixel, alphas)`”

(or just seeing if the left-hand side looks sensible, independently of the right-hand side)

that's a sensible method

Tirr provided a rather convincing argument that it wouldn't work for compositing. Could use a CAS to try to find a different transform that makes it work though, "find an `f` that makes `inv_ycocg(blend(ycocg(pixel), f(alphas))) == blend(pixel, alphas)` true"

Or perhaps a different blend equation, though I presume it would be less efficient than the standard one.

Ay, Aco, Acg does have a sensible interpretation at least, I think. Ay presumably being the total proportion of photons that will make it through, and Aco and Acg weighting which specific photons are the ones to get through.

Ay lmao 👽

(sorry)

lol

Not sure about compositing in YCoCgYACoAChA (should be easy to check if the math works but I am tired atm), but for just storing the data that would make sense, assuming the three alpha channels are generally correlated similarly to how RGB is correlated (i.e. the values are the same for the "unsaturated" case). So I think it should generally help for compression. It's for this reason that we allowed RCTs to apply to any three channels: it might be useful to decorrelate other channels as well.

ah, very nice :)

And yeah, I would assume that even in 3-channel alpha images, most semi-transparent areas will be non-tinted

Gonna try to make a crate to handle common CICP stuff me thinks, I would do ICC but ICC hurts my head, and a goal of this is going to be making a lot of the code with gpu interop in mind using rust-gpu. at the very least, the CICP stuff I plan to be "good enough" for conversion to and from "major" display colorspaces

gonna be neat since programming for both cpu and shaders at the same time is a little bit of a weird situation

Color is quite interesting. We humans think that other mammals are "color-blind", while in reality we can't see many colors ourselves. I'm not talking about colors in infrared/ultraviolet range, nor about fancy things like polarization. I'm talking about good ol' colors. For example monochromatic yellow and [red+green] are distinctly different colors, but we can't distinguish them. Many birds and reptiles can, in fact, distinguish them, and if they had a language they would call them with different words, instead of both being "yellow". In general sense RGB is not enough to define "color", you would need a full spectrogram for that. A simple experiment can prove it: two identically looking yellow paints would look different if the light source is monochromatic yellow light. Monochromatic yellow paint would stay yellow, while [red+green] paint would darken.

Someone should make an image format that supports storing non human colours (ie for radio captures)

Could be helpful as a sort of “RAW” format for light

There are RGBY monitors, but they're still trichromatic, not tetrachtomatic. Kinda similar to CMYK in that regard.

I hate colour, the more you learn the less you know

You are describing multi spectral imaging, which is something satellites do all the time. In JPEG XL you can use extra channels for this.

I’m more thinking continuous spectral

Like 3d data

Each pixel contains an entire spectrogram

Only thing is I still don’t get is why can’t you have triplets of extra channels use Var DCT

You can't. We could have allowed that in principle but it adds some complication.

Ah, yes then you'll get limited by the 4099 channel limit

So if I want lossy then I have to use Squeeze?

Yes, squeeze+quantization or other lossy modular methods, like lossy delta palette, or just reducing bit depth

https://github.com/w3c/csswg-drafts/issues/10998

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

those are sort of different phenomena: the former is observer metameric failure, whereas the latter is illuminant metameric failure (https://blog.kasson.com/the-last-word/metameric-failure/) and could occur even if you captured the full reflected spectrum under one illuminant

to avoid it, you would need to measure the paint’s reflectance spectrum, and then calculate the final emitted spectrum by multiplying that with the illuminant’s

spectral yellow in theory should still look more saturated...?

I prefer gray the colour [av1_cheems](https://cdn.discordapp.com/emojis/720670067091570719.webp?size=48&quality=lossless&name=av1_cheems)

Is there any android gallery app that supports displaying 12bit images?( My phone has a 12 bit display)

<@401816384109150209> in this thread that is a big discussion about the sRGB shittery https://community.acescentral.com/t/srgb-piece-wise-eotf-vs-pure-gamma/

bigger snippet from bottom of thread

note, it's possibly quite important that they do explicitly state a CRT for a reference display

daniele has a great point to really hammer home the fact that it's supposed to be displayed on a pure 2.2 display > The primary goal of sRGB is to be compatible with video. > And a piecewise EOTF is not compatible with video. Video in this context being rec709 encoded footage which was often gamma2.4 or gamma2.2

I feel dirty for saying gamma

and to repeat my point too: in an ICC color managed workflow, there is no ambiguity as images will always be decoded with the piecewise EOTF and not something like 2.2 gamma - for me, that's reason enough to argue that it's objectively the correct interpretation, but you can draw your own conclusions

well depending on what you define as the eotf [av1_dogelol](https://cdn.discordapp.com/emojis/867794291652558888.webp?size=48&quality=lossless&name=av1_dogelol)

if eotf == inverse oetf then yes if eotf == gamma2.2 then no but this distinction is ofc made clear by the context you gave

but yeah, as far as my understanding goes Monitors: Decode sRGB with a pure 2.2 any software converting formats: inverse OETF

this has some leeway, some stuff when mastered on an sRGB monitor, for sRGB monitor may want to choose to convert to linear using a pure 2.2 transfer, but generally I find it better to use inverse oetf

I’m not actually sure how I would go about “grading for ‘sRGB interpreted as 2.2’ ”

I suppose I could grade it as usual, then add a step “convert to gamma 2.2 but don’t attach a profile with it”?

(after two failed attempts at posting that in the correct channel, here we go…)

I _have_ noticed that content I grade on my computer tends to have its shadows somewhat crushed when I look at it on my phone, so maybe I should in fact do just that

I can't wait until PQ becomes the standard, I don't care about PQ so much specifically, but I don't see anything else happening before it, and I just want *something* that isn't the mess that sRGB is

I love how color.org's sRGB spec is wrong. I also love how the "web standard" spec for color is paywalled. Like, I can get paywalling other things, but perhaps, maybe the the most basic of things that is used for the ground work of 90% of other things shouldn't be paywalled

Sadly all HDR implementations aside from MacOS are pretty bad

And HDR specifications are also quite a mess

IMO a HDR 400 certification shouldnt even be a thing because it's too dim

HDR on Android is also bad

Creating an HDR image is easy, but properly viewing that image is a struggle

I find HDR fine on android, the issue is when you mix in SDR specifically which A13+ fixed, at least from what I have seen

Depends on the application I guess but some HDR sample images just did not display properly on a few gallery apps I've tried, inclduing the samsung gallery

Only chrome tonemapped the image, but it still looked improper

a lot of apps just out right don't support HDR

yes, sadly

one thing that has confused me endlessly is how many versions of ImageMagick have interpreted gamma2.2 PNG files as being sRGB, to the point that `identify -verbose` would pretend that it is sRGB while really it isn't.

I think it just always prints sRGB

the problem was in the other direction: it would turn sRGB PNGs into gamma-2.2 ones

because it would write only the “fallback” gAMA chunk and not the actual sRGB chunk that it's meant to be a fallback for

right but then it would take gamma-2.2 PNGs and convert them to jpeg or ppm or whatever without any conversion so it would be interpreted as sRGB again

all this makes me glad I wrote umbrielpng

png tag canonicalizer

does graphicsmagick also have that problem? I always thought gm was a cleaner, more precise version of im

HDR 400 is a clear improvement over SDR for well-mastered HDR sorces that don't overdo it with the brightness.

at least of the display uses decent tonemapping and doesn't just clip at 400 nits...

400 nits is plenty bright if you are in a sufficiently dim room

In cinema theaters the max SDR brightness is around 50 nits, so if you match that, then 400 nits gives you 3 stops of HDR headroom

regular IPS panels with no local dimming qualify for DisplayHDR 400, and those just do not have a high dynamic range due to their terrible contrast ratio (+ IPS glow on top of that)

It is the lowest bar of the Display HDR labels, yes. https://displayhdr.org/

the CTS 1.1 requirements were even more of a joke, as it didn't even require any wide gamut coverage or bit depth higher than 8 bit for the 400 tier

displays typically don't clip lel, they will track as far as they can then use a really harsh tonemapping curve for PQ, for HLG they... scale it, tonemap isnt really the right word