ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
tjaden has joined #wayland
Moprius has joined #wayland
nerdopolis has quit [Remote host closed the connection]
nerdopolis has joined #wayland
eroux_ has joined #wayland
eroux has quit [Ping timeout: 480 seconds]
Moprius has quit [Quit: bye]
Brainium has quit [Quit: Konversation terminated!]
nerdopolis has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
danshick_ has quit [Read error: Connection reset by peer]
mech_pilot has quit [Remote host closed the connection]
mech_pilot has joined #wayland
danshick has joined #wayland
mech_pilot has quit [Quit: mech_pilot]
mech_pilot has joined #wayland
Szadek has quit [Ping timeout: 480 seconds]
gspbirel5684008498790919 has joined #wayland
gspbirel568400849879091 has quit [Ping timeout: 480 seconds]
danvet has joined #wayland
julio7359 has quit [Remote host closed the connection]
julio7359 has joined #wayland
dcz has joined #wayland
rv1sr has joined #wayland
mvlad has joined #wayland
rasterman has joined #wayland
Leopold___ has quit [Remote host closed the connection]
<emersion>
pq, i'm reading up the 3D LUT stuff from Weston, what is the curve offset/scale for?
<emersion>
e.g. the offset is 0.5f / lut_len
<pq>
emersion, ah, that's because of how OpenGL uses texture coordinates.
<pq>
the offset points to the middle of the first texel, because 0.0 would point to the left edge of the first texel.
<pq>
the range from 0.0 to offset will only yield the first texel's value and not the interpolation we'd want.
<pq>
so the usable texture coordinate range is from the middle of the first texel to the middle of the last texel
<emersion>
hm, why do we want to interpolate even the first one?
<pq>
that gives use the linear interpolation we want
<pq>
because this is not texturing, this is LUT interpolation and it just works that way
<emersion>
if i have a 3D LUT, i'd expect (0, 0, 0) to not need interpolation
<pq>
exactly!
<pq>
and it won't
<pq>
but if you sample (0.001, 0.0, 0.0), then you do want a bit of interpolation in the first dimension
<emersion>
but that'll sample in-between two texels as you said?
<emersion>
since the offset is always added?
<pq>
no, it samples the middle of the first texel
<emersion>
oh.
<emersion>
damn
<emersion>
i see what you mean
<emersion>
fun fun
<pq>
if you go off the middle of a texel, then you mix in the neighbour texel(s)
<emersion>
do you have some test ICC profiles btw?
<emersion>
i've been using a random one from a random website and it doesn't work great, but not sure it's my fault or not
<pq>
the weston test suite generates some on the fly, so that we also have their ground truth in precise form
<pq>
IOW, we have a list of test case parameters, for each we generate an ICC profile, shoot what Weston produces with the profile, and then compute manually what the result should have been, and compare.
<pq>
and for each test case, we have a few tests like opaque colors and a semi-transparent gradient in a sub-surface (compositor-specific results, yes)
<pq>
tests/color-icc-output-test.c is all that, but it's also the most complex test code so far in weston, I think
<pq>
I have never really trusted my eyes for testing the correctness.
<pq>
at least in this case there is a defined correct answer...
<pq>
We also test two different types of ICC profiles: matrix-shaper and CLUT. Particularly with CLUT, we introduce error already by simply creating the ICC profile. So we check that too.
<emersion>
hm
<pq>
emersion, colord installs a bunch of ICC files that you could experiment manually with. SwappedRedAndGreen.icc sounds fun. :-)
<emersion>
so there's no easy way to generate a crappy and unreliable ICC profile from EDID?
<emersion>
ahah
<daniels>
pq: we need SwappedRedAndBlue.icc so people can get the big-endian experience
<emersion>
i already have that even without that ICC profile :)
<emersion>
okay, it turns out i copied only dim_len³ * sizeof(float)
<emersion>
instead of 3 * dim_len³ * sizeof(float)
<emersion>
… and the driver doesn't support VK_FORMAT_R32G32B32_SFLOAT
pochu has quit [Quit: leaving]
dcz has quit [Ping timeout: 480 seconds]
<drakulix[m]>
<pq> "if you pick a library like..." <- So for a crappy one one would probably pipe the color characteristics from the EDID into cmsCreateRGBProfile, right?
<drakulix[m]>
How usable would something like that be? Assuming not everybody has a calibrated ICC profile for their monitor, is a profile created like this any improvement?
rtjure has quit [Ping timeout: 480 seconds]
<emersion>
ah, nice, it works on Intel!
<emersion>
thanks for the hitns pq :)
<emersion>
hints*
<JEEB>
'grats
<JEEB>
LUT for output conversion in DRM/KMS?
<emersion>
just in Vulkan for now
<JEEB>
ah
<emersion>
and it's a fat 3D LUT
<JEEB>
if it's on the actual graphics hardware as opposed to some hard-wired ASIC that applies a LUT, I think haasn found out that some functions were actually faster as math VS a lut. although stuff now I think libplacebo uses LUTs for some of the tone mapping?
julio7359 has joined #wayland
<swick[m]>
shader math is cheap, memory bandwidth is not. if you can represent a transform analytically in a shader that will be better but a LUT works for every transform.
<emersion>
yeah, that doesn't really work for ICC profiles though
bodiccea has quit [Ping timeout: 480 seconds]
<emersion>
for well-known color spaces that's a good option
<swick[m]>
depends on the ICC profile
<emersion>
i'm assuming ICC profiles for outputs will be tricky in general
<emersion>
maybe if it's just a matter of applying the EDID color management stuff it's fine?
<emersion>
but for ICC profiles generated from sensor data it'll be tricky?
<JEEB>
also IIRC ICC profiles tend to already have a LUT, right?
<JEEB>
so if you have a thing available, you could just reutilize it
dcz has joined #wayland
<swick[m]>
a transform always connects two profiles. depending on how they are created the transform can contain LUTs, matricies and curves.
<swick[m]>
matrices and curves can be implemented with shader math just fine
<swick[m]>
but because you do not know when you will get a LUT you will always have to handle LUTs
<emersion>
btw, i assume converting to cmsCreate_sRGBProfile() will result in optical values
<swick[m]>
and because you can convert everthing else to LUTs you can support LUTs and be done with it
<emersion>
sorry, let me reword
<emersion>
if i create a transform from cmsCreate_sRGBProfile() to an ICC profile, i assume the transform will take optical values
<emersion>
is there a way to feed electrical values instead?
<emersion>
bleh
<emersion>
i think i mixed things up again
<emersion>
let's use the normie terminology instead:
<swick[m]>
the profile describes a transform from encoded values to XZY
<emersion>
if i create a transform from cmsCreate_sRGBProfile() to an ICC profile, i assume the transform will take gamma-encoded color values
<emersion>
how can i create a transform which takes linear values?
<swick[m]>
you can't
<emersion>
the blending happens with linear values
<emersion>
right?
<swick[m]>
it should, yes
<emersion>
so i need to convert the linear values to something that can be piped into the lcms col9or transform
<emersion>
so the only way is to convert to sRGB?
<emersion>
there's no "null" profile?
<swick[m]>
you want to blend in the output color space on tristimulus values
<swick[m]>
in other words the output color space with the inverse EOTF applied
<emersion>
do i really want though?
<swick[m]>
the problem is that ICC doesn't have a concept of EOTF. you only get a transform from encoded values to XZY
<swick[m]>
where else do you want to blend?
<emersion>
scRGB maybe?
<swick[m]>
scRGB is an basically infinite container
<emersion>
a neutral space not tied to any output and big enough
<swick[m]>
but even then scRGB is non-linear
<swick[m]>
nothing about scRGB is neutral
<swick[m]>
and you don't want big enough, you want the right size
<swick[m]>
because otherwise you're going to have to compress that stuff down again
<emersion>
okay, let's explain my goals a bit
<swick[m]>
and scRGB in particular gives you an infinite space
<emersion>
i'd like to start by touching only the post-blending pipeline
<emersion>
all textures are sRGB, decoded before blending
<emersion>
then i want to convert the blended, decoded sRGB into the output ICC profile
<emersion>
there is no way in lcms to represent that color space where color values or decoded sRGB?
<emersion>
are*
<swick[m]>
I see
<swick[m]>
you'll have to construct one yourself
<emersion>
i will add the pre-blending pipeline too, but ideally later
<emersion>
hm
<emersion>
so i could basically create a custom color space with a linear TF, and otherwise identical to sRGB?
<swick[m]>
yes
<emersion>
via cmsCreateRGBProfileTHR most likely
<emersion>
okay. then later on, the issue of taking linear color values remains
<drakulix[m]>
emersion: But that function does take transfer functions as parameters. If you supply identity functions here, wouldn't that profile operate on linear values? Creating a transform to the sRGB profile or any other output profile should then do what you want, no?
<emersion>
which function?
<emersion>
i can call cmsCreateRGBProfileTHR() with the sRGB whitepoint/primaries, and linear TF
<drakulix[m]>
That is what I meant.
<emersion>
nice
<emersion>
swick[m]: so, if i blend in output color space except linear, i basically still have the same issue right?
<emersion>
so that's where the inverse EOTF comes in?
<swick[m]>
yes, even worse of a problem because the output profile doesn't give you an EOTF
<swick[m]>
by assuming everything is sRGB at the input you already know your EOTF
<emersion>
so what's your plan?
<emersion>
the issue is that the output profile is just an opaque transform right?
<swick[m]>
yes
<swick[m]>
clever maths trying to estimate the EOTF
<swick[m]>
not sure if weston already implements that
<emersion>
hm
<emersion>
is blending in output color space except linear really our best option here?
<emersion>
is there a good name for "sRGB but linear"?
<emersion>
or in general "<color space> but linear"?
<swick[m]>
drakulix: jup, that looks right
<swick[m]>
emersion: I don't think so. It's best to always say either encoded values or tristimulus values
i509vcb has joined #wayland
<emersion>
so linear in regular human wording == tristimulus in color management wizard speak
<emersion>
?
<emersion>
== optical?
<emersion>
and encoded == electrical? (i thought "electrical" was better?)
pochu has joined #wayland
<drakulix[m]>
Depends on the use-case? Electrical/Encoded makes better use of memory, as in uses more bits, where humans perceive more detail. Optical/Linear gives better (as in closer to real world) results when blending. Probably more differences, but I don't think you can call either of them "better".
rtjure has joined #wayland
<emersion>
optical/linear *is* the correct thing to use when blending AFAIU
<emersion>
electrical/encoded for blending is what people are used to because everybody does blending incorrectly
<drakulix[m]>
I am pretty sure some browsers currently expect compositors to do blending in encoded sRGB (like everyone is pretty much doing right now).
<drakulix[m]>
So I would say it is at least debatable, if you should blend untagged surfaces in linear spaces.
<emersion>
in the end it's compositor policy
<drakulix[m]>
Which means an application can't use semi-transparent subsurfaces, if it wants to control blending. (Like browser probably have to, because I expect this is defined in some web standard.)
<drakulix[m]>
I don't think everyone is aware of that.
<JEEB>
emersion: apple uses kCGColorSpaceExtendedLinearSRGB, MS uses the name scRGB as well as the enum DXGI_COLOR_SPACE_RGB_FULL_G10_NONE_P709
<JEEB>
vulkan also has its own enum for it
<emersion>
with NONE being in place of something else?
<emersion>
i think i don't really understand what scRGB is
<JEEB>
yea that is where with chroma subsampling you have the chroma location
<JEEB>
they decided to have enum values defining the whole H.273 shebang
<emersion>
hm, but nothing in that enum specifies that it's *not* encoded?
<JEEB>
G10 for transfer
<JEEB>
"gamma 1.0"
<emersion>
oh.
<JEEB>
compare with YCBCR_FULL_GHLG_TOPLEFT_P2020
<emersion>
i've seen this in the lcms docs as well
<emersion>
but "gamma" is a cursed word AFAIU
<JEEB>
oh yes
<JEEB>
not recommending it. scRGB seems to be in general utilized for BT.709 primaries RGB where it may or may not go under/over 1.0, in order to ease mapping into SDR while keeping HDR capabilities
<JEEB>
generally utilized with linear transfer
<emersion>
right, i see it has both linear and non-linear versions
<JEEB>
vulkan has VK_COLOR_SPACE_EXTENDED_SRGB_LINEAR_EXT if I understand correctly
<emersion>
why do they put "extended" in there?
<emersion>
to mean that values can be outside [0, 1]?
<JEEB>
yes, that was one of the reasons why scRGB was defined. [0,1] being SDR, and then HDR content may be delivered with same color space with values outside of that range
rasterman has joined #wayland
<emersion>
swick[m]: so the reason you dislike linear scRGB for blending, is that it's "too large"?
rasterman has quit [Quit: Gettin' stinky!]
rv1sr has joined #wayland
Szadek has joined #wayland
___nick___ has joined #wayland
<swick[m]>
in theory you can blend where ever you want. usually you want to do it on tristimulus values. scRGB is horrible because there are negative values and it is infinitely big so you need to carry some information about what part of scRGB you actually use. Then there is the issue of the whitepoint. If it is different than your output color space you have to chromatically adapt that as well.
<swick[m]>
emersion: ^
<swick[m]>
If you really do want a single space to composite in then at least use something like bt2020. You won't even need gamut mapping then because everything else is smaller so you can just remap all the inputs to bt2020. The issue is that you then eventually have to compress the bt2020 to the output color space, and even if the input was sRGB you lost that information because the blended data is bt2020 now and your gamut mapping will be kind of
<swick[m]>
horrible.
<swick[m]>
all in all, bad idea
<emersion>
hm
<emersion>
remapping bt709 to bt2020 is not the exact mathematical reverse of compressing bt2020 to bt709?
<swick[m]>
if you want to stay in [0,1], no
<swick[m]>
you loose information going from bt2020 to bt709
<emersion>
even if the input was bt709?
<emersion>
i guess i don't quite get what is involved in color space conversions
<swick[m]>
it depends. if you just transform from one to the other it doesn't loose information but you will get out of the [0,1] range
<emersion>
why do i get outside [0, 1]
<emersion>
?
<emersion>
and why should i try to stay in [0, 1]?
<swick[m]>
because one is bigger than the other
<swick[m]>
and you should try to stay in [0,1] because that's usually what can be represented
<swick[m]>
if a monitor supports a color space it usually means it supports encoded values between 0 and 1
rv1sr has quit [Remote host closed the connection]
rv1sr has joined #wayland
<swick[m]>
if you only do a temporary color space transform it is fine to work with values outside of [0,1] but handling negative values is usually really hard, so the easier way is to transform it to something like XYZ where all colors can be represented with values in [0,1]
<emersion>
what makes negative values hard to deal with?
rv1sr has quit []
<emersion>
bt2020 is bigger than bt709 but i don't get why going bt709→bt2020→bt709 would not give me back the exact same values?
<swick[m]>
you need negative red and blue to get more green. it makes everything much harder to reason about...
<swick[m]>
if your gamut mapping strategy for bt2020->bt709 is clipping then it does
<swick[m]>
but you don't usually want that because it looks horrible
<swick[m]>
so you even move colors inside bt709 to make space for colors in bt2020
<emersion>
oh…
Saijin_Naib[m] is now known as Saijin_Naib
<emersion>
so basically, when going from bt709 to bt2020 it will map the bt709 blue primary to something which isn't the bt2020 primary, something less blueish
<emersion>
and then when doing bt2020→bt709 it will map the bt2020 blue primary to the bt709 blue primary?
<swick[m]>
yes, so it can take bluer colors from bt2020 to move there
<emersion>
i see
<emersion>
thanks for all the explanations!
<swick[m]>
otherwise you get banding effects
<emersion>
i feel like i understand at least .1% of color management now :P
<swick[m]>
there is an analog to brightness where it's easier to see
<emersion>
banding?
<emersion>
banding would be a precision issue no?
<swick[m]>
any kind of color gradiant which lies outside of bt709 for example would end up getting mapped to the same color in bt709
<emersion>
right
<swick[m]>
that also creates banding
<emersion>
hm, does it?
<emersion>
i would've expected… uniform color areas where there was a gradient before
<swick[m]>
it depends on the direction of the color gradiant but in general the gradient becomes less intense
<emersion>
like, two points of a gradient taken out of the bt709 would end up with an identical color
<emersion>
anyways, doesn't matter much, i see what you mean
<swick[m]>
well, it projects the gradient curve to the gamut boundary which must be equal or less in length
<swick[m]>
but yeah, depends on the gradient
<emersion>
and so, "gamut mapping" is this trick of converting one color space to the other without damaging the colors too much?
<swick[m]>
yeah
mohit815 has quit []
mohit815 has joined #wayland
mohit815 has quit []
mohit815 has joined #wayland
manuel1985 has quit [Quit: Leaving]
dcz has quit [Ping timeout: 480 seconds]
eroux_ has quit [Read error: Connection reset by peer]
eroux has joined #wayland
eroux has quit [Read error: Connection reset by peer]
eroux has joined #wayland
___nick___ has quit [Ping timeout: 480 seconds]
dcz has joined #wayland
mvlad has quit [Remote host closed the connection]
ngor has joined #wayland
ngor has quit []
<JoshuaAshton>
We have some gamut mapping code in Gamescope if you want to take a look emersion
<JoshuaAshton>
In the short term we are planning on shipping our own "vibrant deck" type thing but done properly using the AMD DC HW's 3D LUT + Shaper LUT
Brainium has joined #wayland
dcz has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
rtjure has quit [Remote host closed the connection]
danvet has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Remote host closed the connection]
nerdopolis has joined #wayland
gspbirel56840084987909192 has joined #wayland
gspbirel5684008498790919 has quit [Ping timeout: 480 seconds]