ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
kasper93 has quit [Remote host closed the connection]
Guest10215 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest10219
mclasen has quit [Ping timeout: 480 seconds]
mxz__ has joined #wayland
mxz___ has joined #wayland
mxz_ has quit [Ping timeout: 480 seconds]
mxz has quit [Ping timeout: 480 seconds]
KarenTheDorf has quit [Remote host closed the connection]
mxz__ is now known as mxz
kts has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
iomari891 has joined #wayland
Leopold_ has joined #wayland
clando has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
kts has joined #wayland
cool110 has joined #wayland
cool110 is now known as Guest10225
Guest10219 has quit [Remote host closed the connection]
sima has joined #wayland
kts has quit [Quit: Konversation terminated!]
leon-anavi has joined #wayland
tzimmermann has joined #wayland
colinmarc has joined #wayland
<colinmarc>
if the recommendation is just to ignore the ICC stuff, maybe that should be a separate protocol? I found it tricky in my mesa implementation that on the driver side you basically don't have the ability to opt out of certain features - the set of features is determined by the compositer. whereas binding a protocol (version) is a bilateral negotiation. sorry if that's already come up
<colinmarc>
compositor*
<emersion>
clients don't have to do anything special (they don't have to support ICC if they don't want to)
<emersion>
there's no need to "opt out"
<emersion>
but yeah, maybe the ICC stuff should be separate, especially if only Weston is going to support it, it wouldn't pass the impl requirements for merging
<colinmarc>
emersion: that's not 100% true, since the output's preferred image description can be defined with an ICC file
<colinmarc>
but that part of the protocol hasn't been implemented anywhere anyway iirc (it's not in the mesa impl because vulkan doesn't have any surface area for that)
calcul0n has quit [Ping timeout: 480 seconds]
rv1sr has joined #wayland
<pq>
emersion, a libdisplay-info release would be nice for Weston, I don't remember anything WIP I'd want to wait for.
<colinmarc>
(also, as a compositor, if you support ICC profiles at all, you have to expect that any client that binds the hdr protocol (which will be all of them, via mesa) can send an ICC profile, and be ready to accept it. If there was a binding step, then you would be able to gate that functionality. maybe that's not hugely important)
<pq>
ICC stuff is for everyone who wants to work with software that is related to cameras, scanners, and prints. The existing industry is largely built on ICC I believe.
<pq>
mclasen seems to be missing the fact that everything about Wayland is optional. Even everything that an extension says is mandatory, because the extension itself is optional.
<colinmarc>
do video players care about ICC profiles?
<colinmarc>
honestly asking, I've never implemented or looked closely at one
<pq>
colinmarc, I've never implemented a video player either, or looked at the container specs. Broadcasting in general does not tend to use ICC.
<pq>
However, anything that relates to image processing, "photoshopping", drawing, desining printed materials, etc. are likely using ICC.
<pq>
All those applications could live the parametric image descriptions, if it wasn't for users who like to measure their monitor response and craft a color profile out of that.
<pq>
*live with
<colinmarc>
okay, so you have games and video players on the one hand, and content creation tools on the other. they have fairly substantially different requirements. and I don't think it's crazy to venture that there are a lot more users/apps in the former category already existing on linux.
<pq>
IOW, ignoring ICC means throwing all professional image processing users out.
<pq>
and my dream is to make Linux at least as attractive to such users as Apple
garnacho has joined #wayland
<colinmarc>
so, I'm hopelessly biased, as someone who plays games on linux and who is designing a compositor for running games, but I do think there's something being lost here by lumping both categories together in one protocol
<pq>
if ICC is moved to a separate protocol extension, I likely will not be funded to work on it anymore, and sounds very much like there aren't (m)any other developers who'd care.
<daniels>
there are a _lot_ of people using those kinds of tools on Linux, yeah
<pq>
many many years ago, when people started wanting HDR on Linux desktop, I very deliberately wanted to connect that to color management for two reasons: the core of HDR support *is* color management, and to get proper support for ICC that is not extremely fragile
<pq>
In the end, ICC support is much easier than HDR support: hook up LittleCMS, and you're done.
<pq>
with HDR, you actually have to figure out yourself what to do with all the parameters
<pq>
Once you know how to do all the HDR stuff based on parameters, I don't think it's a big step after that to make ICC and parametric interoperable, in a casually satisfactory way.
<colinmarc>
I'm just trying to point out that technically, there is a clear split between applications (and even compositors) that want to shovel HDR content around, and those that need color management. By the way, that split is exactly between the apps that would just use the driver's implementation and the apps that would bind the protocol directly.
<pq>
I will be seriously disappointed if ICC must be moved into a separate extension. It does add more uninteresting boilerplate just to integrate with the parametric color-management protocol, while it does not make anything easier.
<colinmarc>
pq: I'm certain that's true, but as someone who is just beginning their digital color journey, everything is overwhelming enough to understand already
<pq>
colinmarc, HDR absolutely needs color management.
<colinmarc>
sorry, I was using that as shorthand for the ICC profiles and other advanced ways of doing color management
<pq>
and HDR color management is much harder to do than ICC, because in ICC all the difficulty is in crafting the ICC profiles, which for a compositor are handed ready-made.
<colinmarc>
pq: it definitely makes things easier, because it allows for a few clarifying assumptions - for example that only the driver will bind the parametric protocol.
<pq>
colinmarc, color management in itself is overwhelming. Picking just ICC or HDR does not make it much easier, but it does give a narrower view that is more likely to lead into hidden assumptions.
<colinmarc>
I know I'm just a rando so thanks for discussing this with me, in any case :)
<pq>
colinmarc, what "driver"?
<colinmarc>
I guess I mean the WSI implementation in mesa/eventually other graphics drivers
<colinmarc>
there are many other examples of protocols that are meant to be used only by the system-installed driver stack and not by the framework or the app itself. or am I misunderstanding that?
<pq>
if you are referring to the HDR capabilities of Vulkan and EGL, the drivers will only pass parameters through. They don't help you in any way. You still need to know in your app, which parameters to pick, and how to actually produce an image that matches those.
<pq>
If you choose to use some game engine that has that knowledge alrady built in, that helps you.
<pq>
But if you use a game engine, then you probably never use a WSI API anyway, so it doesn't matter who binds the protocol interface, it's not "you" in any case.
<colinmarc>
I guess we need to define "easier" then. to me, it is easier to design a protocol which only has to support integration with drivers. this isn't hypothetical - one of the blockers on the CM&HDR protocol is that there's no way for vulkan users to disable mesa's integration in order to use their own, right?
<colinmarc>
you don't want both WSI and the framework/engine/app to bind the protocol simultaneously, that's an error. so you need some out of band way to communicate "I've got it, I'm binding the protocol"
<colinmarc>
whereas if you put it in the bucket of "only WSI is meant to bind this protocol" that removes that problem
<pq>
I thought there was an answer to that question. But that question will continue to be a problem even if ICC and parametric were separate extesions, because then they need to be mutually exclusive on the same wl_surface. Then you have someone who wants to use an ICC profile but render with Vulkan.
<emersion>
the original idea was that mesa wouldn't use the protocol if the Vulkan user doesn't use the HDR ext
<colinmarc>
maybe I'm misunderstanding something, but I don't think it's that simple
<emersion>
binding to the global should have no consequences
<emersion>
get_surface is the thing that needs gating
<emersion>
i don't believe PASSTHROUGH equals "no color_management_surface"
<emersion>
isn't PASSTHROUGH supposed to be implemented as setting the surface's color space to the output's?
<emersion>
my immediate thought would be to call get_surface lazily, when a swapchain is bound to a surface
<pq>
emersion, I think something in Vulkan API design made the convenient solution impractical.
<emersion>
VkSwapchainCreateInfoKHR contains the surface
<pq>
because there is no Vulkan API object that represents the window system connection
mvlad has joined #wayland
<colinmarc>
so you would call get_surface the first time the swapchain is created, and then cache it for future swapchains?
<emersion>
yeah, stash it in the surface
<colinmarc>
another problem I ran into is that it's not easy to look up the instance extensions that were enabled. and since the extension literally just adds enum values it's a bit weird to gate on that (for example, mesa always exposes all the enum values even if you don't enable the extension, because it's hard to code it otherwise)
<emersion>
i mean the VkSurfaceKHR
<pq>
If I'm not mistaken, it's related to the reason why Vulkan is creates so many wl_registry objects in the first place.
<colinmarc>
yeah, I don't understand 100% why that is, to be honest
<pq>
daniels explained it to me once, but I've happily forgot.
<pq>
So, if ICC interfaces are put into a separate Wayland extension, it will either need to duplicate both the wl_surface and wl_output extensions interfaces of the parametric color-management extension, or hook onto them.
<pq>
Either way, it becomes API-wise possible to tag a wl_surface with both ICC and parametric image descriptions, which makes no sense and must be forbidden somehow. So the "get_surface" is still mutually exclusive and allowed to have only one at a time per wl_surface.
<colinmarc>
pq: Couldn't you have them both create image description objects, the same way dma creates wl_buffers?
<colinmarc>
to your point, that's still mutually exclusive
<jadahl>
colinmarc: count GNOME Shell as one that intends to to both HDR and "real" color management
<pq>
If the ICC extension does not duplicate the wl_output, wl_surface, and a small part of the wp_image_description interfaces, it needs to re-use the wp_image_description interface, which means that ICC necessarily still leaks into the wp_image_description interface (in its information provider part).
<pq>
and it brings the problem of versioning wp_image_description: now there are two independent extensions creating objects of the same type.
<jadahl>
I imagine photo editor apps like that will want to indeed
<pq>
they very least want to get the display's ICC profile, and provide window content matching that
<jadahl>
whatever gets them correct output. I can't imagine performance being critical for something like darktable
<colinmarc>
yeah, my point was not that those users don't exist, but that the huge userbase of video players and games has a different (sub)set of requirements, which are more easily satisfied, and would be satisfied by a WSI-only protocol (which, even if it's doable to do the protocol-for-both-WSI-and-apps thing, is certainly awkward and more complicated)
<pq>
colinmarc, the factory interfaces of wl_buffer do not consider versioning, which means we can never extend wl_buffer interface, and I think would have wanted to several times, but had to put the new stuff in wl_surface instead. Versioning can be made to work (now that we are aware), but it's complicated.
melonai has quit []
<colinmarc>
pq: that's interesting, I didn't know that
<pq>
colinmarc, what if someone who usually does photo editing wants to watch a video?
<colinmarc>
I'm not sure I understand the question, sorry
<colinmarc>
anyone who does content creation probably has a macbook - today. I think it's laudable to try and make linux a better platform for that. but it's a bit weird to bundle those needs in with the needs of the people already on linux playing games and watching HDR movies.
<pq>
The user has set up an ICC profile for their display. Video players probably use only the parametric interfaces. Now, the display cannot be described by the parametric interface at all. Video player does not mind, just tags its window with the video color characteristics. The compositor gets to deal with parametric<->ICC interoperability anyway, even if the protocols were separate.
<colinmarc>
ah ok. yeah, in that future, it is simpler for it to be one protocol, probably.
<pq>
emersion, does Weston compositor implementation and weston-image client implementation count as one or two implementations for wayland-protocols governance?
<emersion>
i thought weston clients are not real-world
<emersion>
were*
<emersion>
but maybe i'm wrong?
<pq>
weston-image is as much real-world simple image viewer as they would be, color-management wise.
<pq>
I can do a Weston wayland-backend as a client implementation, too. Should so at some point anyway.
<emersion>
i've been wondering about wlroots' backend counting or not as a client impl in the past
<pq>
*Should do
<emersion>
for wl_surface.get_release
<pq>
what would be a more real-world client implementation than a nested compositor?
<emersion>
i don't have an answer to these questions
<pq>
I'd be happy to count them as two, compositor and client. They are independent implementations, just under the same membership.
<pq>
Maybe that should be brought up and decided.
<jadahl>
technically they are two separate implementations. so it's more of a philosophical or "governence" question I guess
<pq>
I don't see a difference to the same person writing the implementations in two different projects.
<jadahl>
"GNOME" is one member, but we count mutter and gtk as different implementations
<emersion>
Mutter and GTK are separate members
<jadahl>
not in the MEMBERS.md
<jadahl>
it says GTK/Mutter (then lists me and Carlos)
<emersion>
oh, i misremembered
<jadahl>
splitting up has been discussed, but didn't happen yet
<emersion>
kind-of related is wlroots being a single member representing many different compositors
<jadahl>
indeed
<pq>
I wouldn't take a "nested compositor" implementation that is just a pass-through of protocol as either compositor or client implementation, btw., as it does not handle the semantics for either side.
<emersion>
that's fair
<pq>
emersion, I think the deciding factor there is, where does the protocol implementation reside mostly? In the compositors, or in wlroots? Or this that difficult to tell?
<pq>
*Or is that
<emersion>
in general that's not difficult to tell
<emersion>
some compositors use the wlr impl, some compositors do the impl themselves
<pq>
if someone does the impl themselves, they should count separately - but also they need to be members separately as well, or?
<emersion>
we've been ignoring members for the purposes of counting impls so far
<emersion>
e.g. mpv is not a member
<pq>
oh, that's good
<emersion>
yeah
<pq>
then there is no question at all
<emersion>
the only question is whether or not the impl is "real" or "toy"
<pq>
Weston compositor implementation is one, and weston-image is another
<emersion>
and you've answered that question
<pq>
so the ICC parts only need one compositor or client impl, right?
<pq>
*one more
<colinmarc>
there is some sort of soft notability threshold, right? like I wouldn't count my compositor as notable because it has no real users yet.
<pq>
easiest is to look for a client to implement it, and then it can exercise the handling for the output ICC profile as well, which weston-image does not do.
<jadahl>
pq: could be worth checking how far GTK has come in the color management work
<pq>
OTOH, if I implement color-management ICC support in weston's wayland-backend, that would be another client implementation quite different from weston-image. But I'd hesitate to say the Weston project can fulfill all three required implementations, I'd like another project too.
<jadahl>
not sure how much ICC profile work has been done, but IIRC e.g. loupe (gtk4 image viewer) might want to plumb the ICC profiles of images
<jadahl>
(there is work related to color management going on in gtk/loupe land)
<pq>
jadahl, awesome
<pq>
jadahl, given weston-image already works on Weston, they could develop against Weston.
<pq>
jadahl, how should I get in touch?
<MrCooper>
mclasen is working on it for GTK
<jadahl>
pq: right, talk to mclasen on #gtk on libera, or here
<pq>
he's not here when I am, I think
<jadahl>
I think he'll join in three or so hours
<pq>
okay, thanks
slim has quit [Quit: slim]
<pq>
Maybe the ICC side will be the first to gather the implementations then. :-)
<pq>
The parametric interface is still missing bits even (white levels).
<pq>
So at this point it doesn't seem to me that getting the ICC side implementations would considerably hinder landing the protocol.
<colinmarc>
just to point it out, there are also many, many thousands of users using a different protocol for HDR today which doesn't support any of that. because there's so much demand that they're circumventing the "official" protocol process
<pq>
Sure, that's fine.
<colinmarc>
it's a bit odd to me that games seem like such a low priority here, given how much they are driving linux desktop adoption. and the fact that games, on the whole, are relatively simple clients with simple and consistent requirements.
<colinmarc>
functionally today they are basically a single client, wine/proton
rasterman has joined #wayland
<pq>
and people complain to me that no-one cares about ICC
<pq>
why should we create a quick solution for games, when one already exists?
<pq>
we should do better, and aim higher
<jadahl>
if we would end up with an upstream quick fix for games (like the one in the wild), we'd end up with two HDR protocols, one well designed, and quickly designed
<emersion>
my understanding was that ICC was very far off, and would block merging of the HDR stuff
<emersion>
but it seems like it's not the case
<colinmarc>
I think the WSI/app split is more the issue. the ideal would be to have vulkan APIs to support all those interfaces, and do everything through vulkan. but no one has even proposed those extensions
<colinmarc>
the parametric stuff is exposable via Vulkan already. the ICC stuff (and some other pieces of the protocol like preferred descriptions) is not
<pq>
ICC alone is easy, because profile builders and CMSs do all the hard work. Mixed ICC/parametric is hard, and splitting the extension in two might sweep that case under the carpet but not make it disappear. Weston has taken (blame me) an unnecessarily hard way of implementing ICC support.
<emersion>
that's completely fine if vulkan doesn't expose every feature, i think
<pq>
Vulkan and EGL are not the only libraries that wrap the color-management protocol interfaces, more or less fully. App toolkits would do so too. Since neither Vulkan nor EGL are app toolkits, but tookits might use Vulkan or EGL, you still have two independent components doing the same things on the same surfaces. It seems unavoidable.
<King_DuckZ>
good morning all~ any hint on how best to retrieve the output's width and height from the fragment shader?
<zamundaaa[m]>
pq: I don't think ICC in the protocol is really needed for those "real colormanagement" use cases to work. You only need a profile on the output side, which is simpler to implement, at least in KWin
<pq>
zamundaaa[m], the apps also need to get that profile, and then they need to tell the compositor they used that profile.
<zamundaaa[m]>
I don't think that's necessary
<pq>
why not?
<pq>
apps very least do need the display profile
<zamundaaa[m]>
Apps need the available gamut, but I don't think it needs to account for the nonlinear nature of the display's response
<pq>
but the gamut bounary cannot be expressed otherwise
<pq>
*boundary
<zamundaaa[m]>
The linear subset of the gamut that the display can present can be expressed
<pq>
what subset? A gamut that a display can reproduce is the gamut it can reproduce.
<King_DuckZ>
I've been looking around in Weston's code, I don't find any obvious way to propagate that info down into a uniform - I couldn't even find where it's stored at all tbh :/
<zamundaaa[m]>
You can pick a set of primaries that is entirely contained in the display's gamut
<pq>
you mean you think it is ok to leave parts of the reproducable gamut out of clients' access?
<zamundaaa[m]>
Yes
<zamundaaa[m]>
They should effectively always be insignificant, right?
<pq>
I'm not sure. I don't even know how you could pick such primaries in the first place.
<daniels>
colinmarc: it has taken much longer than we'd have liked to have a solution, but tbf we did also start many years later than hoped. the protocol development has been a long twisty road, but otoh there's a _lot_ of infrastructure work required to just make sure that you don't instantly blind people as soon as a notification pops up on top of their HDR game/movie, so splitting things may have compromised things long term & not made it faster
<daniels>
pq: the reason the queries are all on VkSurfaceKHR, rather than having a VkDisplayKHR which wraps a surface, is basically that none of Windows/macOS/Android have a display object, because your window system is a system-global singleton
<zamundaaa[m]>
pq Microsoft at least seems confident that it's enough, their Windows Advanced Color stuff doesn't deal with ICC profiles at all afaik
<daniels>
the surface-based queries do work fine enough, just with some minor annoyance, so that's where we ended up with, rather than having an indirection that's completely superfluous for everything other than generic Linux
<zamundaaa[m]>
So I'm at least willing to try it
<pq>
zamundaaa[m], The gamut is a 3D volume, and you'd need to make sure that the sub-set gamut 3D volume is fully contained inside the reproducable 3D volume. Maybe it is simple for RGB displays specifically, though, but I would not trust my intuition without mathematical modeling with real-world data.
<pq>
zamundaaa[m], well, people also think that sending BT.2020 on the wire is good enough. Depends on what it is designed for.
<pq>
I mean HDMI and DisplayPort
KDDLB has joined #wayland
<pq>
years later, we have rumours of Source-Based Tone Mapping to fix the problems with that.
<colinmarc>
daniels: I'm sorry if you read impatience in what I wrote, that's actually not what I was trying to express. I haven't been around for all of that - I only just started getting involved in linux graphics stuff. I would of course like to use (a subset) of the protocol already, and my suggestion was that it might be technically clarifying to simplify or split the protocol. And more broadly I'm concerned that it seems like games are a bit of a
<colinmarc>
secondary concern, which is leading to the practical result of wayland being sort of "forked"
<pq>
yet, ICC has existed for longer than any of that. But ICC is hard to implement efficiently.
<zamundaaa[m]>
pq That is true. I don't intend to stick to this plan no matter what, but to write autotests that check whether or not this works out in practice too. And if it doesn't, we'll just have to add ICC support in KWin too
<pq>
zamundaaa[m], cool. How do you plan to test that?
<pq>
zamundaaa[m], wait, do you mean that also KWin would not use a user set ICC profile as-is, but only the simple sub-set gamut?
<zamundaaa[m]>
Yes, ish. On the output side, the ICC profile is still applied
<pq>
what do you as the source profile, if you use the ICC profile as destination?
<pq>
or do you make your sources target PCSXYZ?
<zamundaaa[m]>
I don't use lcms for that. I just convert the input to XYZ D50, and pass it through for example the B2A1 tag
<zamundaaa[m]>
For testing I'll write an integration test in KWin, which tests the whole client -> final framebuffer pipeline, and check delta E at the end, and which part of the gamut it actually manages to use
<daniels>
colinmarc: yeah, that's totally fine, I get what you're saying :) it definitely seems from the surface like doing full CM (as opposed to limited HDR) is the hard part, but in reality a huge amount of the implementation work is the same no matter which path you take - teaching compositors to do something more nuanced than just slamming buffers at GL or KMS without thinking about the content
<pq>
zamundaaa[m], delta E vs. what? What's the reference?
<daniels>
(sort of like how a lot of the engineering effort to 'do Wayland' was actually just a lot of foundational work on toolkits so they were capable of running on non-X11)
<zamundaaa[m]>
pq: the reference is lcms doing the conversation like it would on X11
<swick[m]>
trusting MS on anything color is a bit... eh.
<pq>
daniels, I was asking what problems not having a VkDisplayKHR caused, rather than why we don't have it.
<King_DuckZ>
pq: thanks, looking at it now
<daniels>
pq: oh, I don't know what problems it really causes tbh
<pq>
daniels, like why does Mesa Vulkan create so many wl_registries? Or how we cannot... something something to to do get_color_management_surface only when we know that Vulkan will actually be driving the color properties?
<emersion>
colinmarc: would it help to have a read-only version of get_surface for vulkan, or not?
<pq>
colinmarc, if you think games are a secondary concern, what do you see as the primary concern that people are working on?
<colinmarc>
emersion: write-only would help but not read-only :)
<pq>
zamundaaa[m], ok, so what do you use as the source profile for the reference?
<colinmarc>
colinmarc: the main thing vulkan can do today is describe the buffer that it passes up
<daniels>
pq: yeah, the client has to specifically enable the VK_EXT_hdr_metadata extension on the VkInstance it creates before it queries surface capabilities, so you could skip that
<colinmarc>
daniels: maybe I'm misunderstanding, but I think the metadata is separate from describing the buffer color space
<colinmarc>
the issue is that VK_EXT_swapchain_colorspace is awkward to use as a signal, in part because even without that extension mesa would still like to send sRGB
<zamundaaa[m]>
pq: various profiles that apps might use - probably mostly profiles from random displays
<zamundaaa[m]>
Colin Marc: I don't think you have to use the color management surface for sRGB
<zamundaaa[m]>
You can assume that to be the default, that you get when the surface isn't tagged with any image description
<pq>
zamundaaa[m], I'm lost. Isn't the goal to test if using a simple sub-set gamut of the output's ICC profile is sufficient? And KWin implements protocol only for parametric surface profiles. If your reference is defined by ICC profile, you'd have to convert that to a parametric profile? Or do you do a re-render of test input from source ICC profile to parametric profile, send that image to compositor, compare
<pq>
compositor result to the original ICC source profile coupled with the outputs ICC profile?
<zamundaaa[m]>
pq: yes, I commit a re-render of the test input to the parametric profile
<colinmarc>
<zamundaaa[m]> "Colin Marc: I don't think you..." <- right, but what about the content creation apps? they want to set P3 or whatever, which means they need to enable the extension, which means mesa will bind the protocol
<colinmarc>
or they don't enable the extension and mark their buffers incorrectly as srgb
<zamundaaa[m]>
Mesa doesn't mark anything if the extension isn't enabled
<colinmarc>
realistically what they want is PASSTHROUGH, if they're doing CM themselves, I think
<zamundaaa[m]>
If the app wants to do color management itself, it has to use the color management surface to tag it with whatever colorspace they want
<colinmarc>
which is also behind the extension
<zamundaaa[m]>
The sRGB thing is quite misleading in Vulkan, it doesn't really mean sRGB
<zamundaaa[m]>
It's untagged in this case, and with other operating systems too right now afaik
<zamundaaa[m]>
PASSTHROUGH is unfortunately not really usable for our purpose
<zamundaaa[m]>
Because you can't really create or destroy the color management surface based on that, right?
<colinmarc>
zamundaaa[m]: that's even more awkward, yeah, because it's a property of the swapchain, not the surface
<colinmarc>
treating sRGB as "untagged, but only if the extension is not enabled" works but is not very explicit and hard to communicate to users
nerdopolis has joined #wayland
<zamundaaa[m]>
No, you'd also treat is as untagged when the extension is used
<colinmarc>
but what if your content is actually srgb?
<zamundaaa[m]>
The assumption is that untagged is okay for sRGB content
<zamundaaa[m]>
But you're right, it's awkward
<kennylevinsen>
"color sensitive sRGB content" is probably always going to be an odd concept
<colinmarc>
you also have to convince nvidia to do the same thing in their wsi, I guess. and if you're porting a moltenvk app to linux, then the behavior will be surprising
<King_DuckZ>
I'm getting really confused right now but I think shader in Weston got the names wrong, it's got this yuva2rgba function that should really be called ycbcra2rgba
iomari891 has joined #wayland
calcul0n has joined #wayland
Leopold_ has joined #wayland
<King_DuckZ>
or maybe not :|
<pq>
zamundaaa[m], ok, yeah, sounds like that can work. An interesting idea.
mclasen has joined #wayland
<pq>
King_DuckZ, YUV and YCbCr are used interchangeably in weston.
<pq>
neither means very much, because there are many "flavors" of YCbCr
<King_DuckZ>
pq: that's wrong if that's the case, u and v are in the [-0.5..0.5] range, while cb and cr are in the positive range (but not necessarily [0..255])
<pq>
King_DuckZ, tell that to all the DRM pixel formats who carry Y, U or V in their names.
<pq>
and the channel data type is invariably unsigned integer
<pq>
OTOH, shaders always handle [0.0, 1.0] range values. Not [0, 255] and not even [-0.5, 0.5].
<King_DuckZ>
pq: well, that doesn't make it "correct" :)
<King_DuckZ>
well the yuva2rgba() function in the shader *is* offsetting u and v by 0.5, so I think that's really converting yuva and not ycbcr in this case
<King_DuckZ>
I got confused but I think the naming in the shader is correct
<JEEB>
to my knowledge YUV was an analog thing, and people just kept utilizing the same thing for digital, even though it was being called YCbCr or Y'Cb'Cr' (one of those is linear, one of those is transform encoded)
<pq>
if U and V are zero for achromatic, and Cb and Cr are in unsigned intereger range, then neither is correct for yuva2rgba()
<JEEB>
at least in FFmpeg that is why the pixel formats kept being called YUV...
<pq>
JEEB, right. The one with prime ' is electrically encoded.
* King_DuckZ
facepalms
<pq>
and YUV drops the prime, because no-one bothers with optical Y - except constant luminance encoding
<King_DuckZ>
sorry, I just realised yuva2rgba() is doing -0.5 and not + so my first guess was correct, it is ycbcr and not yuv (let's leave the ' on the side for now)
<King_DuckZ>
looking at this line `su = yuva.y - 0.5;`
<pq>
King_DuckZ, the input to yuva2rgba() is unsigned integer encoding of YCbCr divided by integer max.
<JEEB>
and to see how actual specs call these things, you can take a look at BT.2100, f.ex. 10- and 12-bit integer representation, I don't see YUV being utilized there at all
<King_DuckZ>
I don't think the scaling matters here, or else rgb would also be "wrong" since it's not [0..255]
<King_DuckZ>
just the fact that it's all positive
privacy has joined #wayland
<pq>
King_DuckZ, and quantization range? The input to yuva2rgba() has the range in it, and the range is normalized only inside yuva2rgba().
<colinmarc>
is YUV a legitimate way to talk about pixel layout? or is that also loose?
<pq>
colinmarc, YUV is fundamentally loose nowadays.
<colinmarc>
it's just easier to type than YCbCr :)
<pq>
yup
<King_DuckZ>
pq: the wikipedia page I posted earlier says "YCbCr usually scales all channels to either the 16–235 range or the 0–255 range"
<pq>
and YCbCr has never been a single definition either
<pq>
King_DuckZ, yes, I read that.
<King_DuckZ>
so it doesn't really matter if it's starting from 0 or 16, though I agree it's bloody confusing
<King_DuckZ>
but calling it the wrong name makes it even more confusing
kts has joined #wayland
<King_DuckZ>
colinmarc: so is typing mb vs MiB but in code it'd be very confusing if you had *both* megabytes and mebibytes and never knew if bytes2mb() was doing the one or the other
<pq>
do you really read YUV as not YCbCr?
<pq>
you cannot compute with YCbCr without additional knowledge, anyway
<King_DuckZ>
pq: well it might be due to inexperience, but I've been messing around with +0.5 and clamp for the whole week now, all I know for sure at this point is that I know this "try and see what the output looks like" guessing game
<King_DuckZ>
is that I hate*
<pq>
King_DuckZ, uh... trial end error is probably the most painful path here. What do you want to know?
<King_DuckZ>
I'm working on that shader to make it do chroma key and I need yuv (like [-0.5..05] uv) for that to work properly (at least that's my understanding so far)
cool110 has joined #wayland
<pq>
well, you probably need to rewrite yuva2rgba() completely to get that.
cool110 is now known as Guest10247
<pq>
currently, the quantization range handling is built into the "matrix" that also does the YCbCr->RGB conversion.
<King_DuckZ>
no because that one is used to convert from values coming from the outside the shader (see sample_input_texture())
<pq>
what do you need again?
<pq>
and why are you looking at yuva2rgba()?
<King_DuckZ>
gl_FragColor = f(rgba, yuva(rgba)), and I'm trying not to convert twice where possible
<King_DuckZ>
because I wanted to know if the yuva I get when for example `c_variant == SHADER_VARIANT_Y_U_V` is really yuva or if it's ycbcr, and I think it's ycbcr in fact
<King_DuckZ>
since I have a chroma key to compare to, I must make sure I'm not comparing apples to oranges
Guest10225 has quit [Ping timeout: 480 seconds]
<pq>
What the shader calls YUV in yuva2rgba() is the unsigned integer pixel value divided by integer max. Then you have todo undo the offset and the quantization range to get to [-0.5, 0.5].
<King_DuckZ>
it wouldn't work if my key was in the [-0.5..0.5] range and the input colour was in the [0..1] range, and it'd work /sometimes/ if input was going through my rgba2yuva conversion sometimes, and coming straight from the input unshifted some other times
<King_DuckZ>
sorry if I sound pedantic, I'm really the guy caling gnu "linux" all the time and MiB megabytes, but in this case I think it makes a difference
kts has quit [Ping timeout: 480 seconds]
<King_DuckZ>
yep I think that's clear now, thanks!
<pq>
To me, what makes the difference is understanding what the values are. Being pedanting, the input to yuva2rgba() is neither YUV nor YCbCr, because it is scaled YCbCr. You cannot compare scaled to non-scaled. Pedantically.
<pq>
One can have even more fun similarly with RGB, when you can have unsigned integers, or normalized to peak range, or normalized to SDR range, and then of course in some niche corner there exists the limited quantization range of it as well.
<pq>
Not to mention the third quantization range 1-254 that some signaling types use (I forgot the name), but I don't think we encounter that in this context.
Leopold_ has quit [Remote host closed the connection]
<King_DuckZ>
yeah I see your point, I'm not saying "call it ycbcr" and suddenly everything is crystal clear, just a bit less confusing
<pq>
I was similarly very confused with the terms EOTF, OETF, and OOTF.
<King_DuckZ>
it's also true that in a shader's context I think it's normal to have [0..1] ranges instead of 255, so I wouldn't be surprised to see that Y is 1.0 instead of 255 just like I'm not surprised by R doing it
<JEEB>
King_DuckZ: too bad that to my knowledge I don't really see there being a definition of YUV in digital space, other than people writing YUV when they mean YCbCr or YCgCo or ICtCp
<JEEB>
and I know that from experience since I've worked on FFmpeg enough to know that the YUV... pixel formats are just leftovers from a bygone era when the analog format was more prevalent
<JEEB>
(also technically shorter, yes)
<pq>
King_DuckZ, how about the RGB range [0.0, 125.0] :-)
<King_DuckZ>
:D
<JEEB>
pq: the full range stuff which might or might not include 1 is defined in BT.2100. I rewrote the FFmpeg AVColorRange documentation based on that
<JEEB>
s/1/0/
<King_DuckZ>
JEEB: so you suggest keeping yuv naming and hope for the best? I'm asking in case I try and open a pull request
<pq>
JEEB, ah, that's the spec.
kts has joined #wayland
<JEEB>
pq: yea it defines the limited and full range representations
<JEEB>
King_DuckZ: no I definitely don't in any new context :P
<King_DuckZ>
JEEB: wouldn't it be confusing if you saw a yuva_chroma_key variable compared to a input_yuva-0.5?
<JEEB>
since YUV in digital space is not defined by anything to my knowledge, so if you mean YCbCr or YCgCo or ICtCp or IPTv2 or whatever, you write that xD
<King_DuckZ>
so what would you call a YUV whith U/V in the [-0.5..0.5] range?
<JEEB>
that's the state just before sending it into integer coding
<colinmarc>
that's the intermediate form that the matrix transform spits out
<JEEB>
basically if I had a floating point 4:2:0 format I'd expect it to have something like that
<colinmarc>
YPbPr?
<King_DuckZ>
colinmarc: that's the name of the cable, as I understand
<colinmarc>
> The resulting luma (Y) value will then have a nominal range from 0 to 1, and the chroma (PB and PR) values will have a nominal range from -0.5 to +0.5. The reverse conversion process can be readily derived by inverting the above equations.
<colinmarc>
(from wikipedia)
<JEEB>
if it's encoded already with a transfer, then call it luma and have it marked as float
<pq>
JEEB, no, it's not BT.2100. It's SDI signalling.
<JEEB>
since IIRC there is some best practice that for linear you call it luminance and transfer encoded it's supposedly better to call it luma (and same with chrominance vs chroma)
<King_DuckZ>
it's a very convincing and conveniently schematic explanation, but it seems to contradict wikipedia... so is that wrong? I'm trying to learn and the fact that each website claims the opposite of everyone else is not helping
<pq>
JEEB, yes, different. 1-254 for R, G, B, Y
<JEEB>
huh, funky
<King_DuckZ>
I do have the Poynton book, but it'll take a while before I go through it, I've only just started reading
rasterman has quit [Quit: Gettin' stinky!]
<pq>
King_DuckZ, welcome to color, in general.
<King_DuckZ>
:D
<kennylevinsen>
King_DuckZ: He's wrong - the cable has never been called YPbPr, but "component video". Some devices have labelled the terminals "Y", "Pb/Cb" and "Pr/Cr"
<King_DuckZ>
It's love and hate from day 1!
<JEEB>
kennylevinsen: component is analog, right?
<King_DuckZ>
kennylevinsen: thanks, so I'll call my function rgb2ypbpr
<JEEB>
ugh
<King_DuckZ>
well, ypbpra
<JEEB>
so you're calculating an analog signal?
<King_DuckZ>
no, but colinmarc said ypbpr T_T
<JEEB>
it's just the floating point representation of Y'C'bC'r (or whatever luma plus chroma based format)
<JEEB>
King_DuckZ: I do not see an actual specification calling this E' variable anything, and E' is the input to the integer representation
rasterman has joined #wayland
<kennylevinsen>
JEEB: yup, just intended to get better color separation and reduced artifacts compared to composite
<pq>
Different systems really do work slightly differently. People mix up systems, and write it down. People simplify all the way down to not quite right, and write it down. People read those, make utterly false conclusions, and write it down. And the next person comes looking for the truth...
<JEEB>
I just say call it ycc (since I'm not sure if it's cbcr or what) and it's float. the floating point representation of it is the signal you have for chroma (-0.5-0.5)
<King_DuckZ>
but I was really hoping to figure out the name I should use before lunch this year ^^
<JEEB>
alternatively take a look at how libplacebo calls these things
<kennylevinsen>
(PAL composite/RF is itself Y'UV, with component splitting off UV to their own signals)
<JEEB>
King_DuckZ: basically, YC(b)C(r) and float is what your signal is, it doesn't have a separate word for it
<King_DuckZ>
ycc sounds good enough, thanks
iomari891 has quit [Ping timeout: 480 seconds]
<JEEB>
or if it's generic matrix encoding then you'll have to look at libplacebo or zimg or so, for examples of generic matrix coefficient encoding/decoding functions
* JEEB
scrolls up to check the name of the function
<kennylevinsen>
As an aside, the wikipedia article on YCbCr is self-contradicting
<JEEB>
yea, which is why it's better to just keep to specs if only possible
<JEEB>
King_DuckZ: so is your function something like `rgba2yuva` from the backlog? is it just a generic matrix encoding thing?
<kennylevinsen>
It says that Y'PbPr has a range of -0.5 to +0.5 then says Y'CbCr is scaled to an integer space... and then proceeds to have a chart named "Y'CbCr" that goes from -1.0 to +1.0 :P
<kennylevinsen>
Petition to throw all these terms away and come up with new ones, anyone?
<pq>
People are bound to call the same thing with different names, and different things the same name. One would hope that a document is at least internally consistent.
<pq>
what I "like" the most is that 'yuva.y' gives you the u. :-P
<kennylevinsen>
colors were a mistake
<pq>
somehow using r,g,b,a to denote the components of yuva vector didn't seem right...
<JEEB>
King_DuckZ: I checked libplacebo and it calls matrix application {encode,decode}_color , which then handles the various matrix coefficients including ICtCp etc.
<kennylevinsen>
pq: honestly, rgba might be less confusing as there is no overlap to misinterpret
cmichael has joined #wayland
<pq>
except a which accidentally happens to be a
<pq>
hmm, the bug still exists, too...
<JEEB>
so I guess encode_color or apply_matrix_coefficients (but with apply I don't know what the inverse of it would be :P)
<pq>
I kinda think that mentioning *something* of YCrCr or even YUV would make better intuition of what it does. YUV-RGB-conversion is well-known category of algorithms, right?
<pq>
*YCbCr
<pq>
not an exact name for the algorithm as implemented, but enough to give a good idea what it's about
<JEEB>
as a comment, sure. but if you add it to the name then suddenly you're apparently limiting yourself to specific matrix coefficients values
nerdopolis has quit [Ping timeout: 480 seconds]
<pq>
rgbaize()
<pq>
mclasen, do you think Loupe might want to use the ICC profile side of color-management protocol? Either send the image embedded profile up, or get the compositor's preferred when it happens to be an ICC profile?
<mclasen>
I did succeed yesterday btw, in telling both kwin and weston that my surface is srgb
<pq>
mclasen, cool. That might be the third implementation needed for the protocol ICC parts.
<pq>
Nice!
<mclasen>
I did not succeed with srgb-linear, baby steps...
<pq>
mclasen, as you found out, Weston only supports ICC profiles right now, so you'd have to craft an ICC file. I would recommend one of the other two options though.
<mclasen>
its of course not very interesting for srgb
<pq>
mclasen, would Loupe (or GTK) use a CMM (like LittleCMS) itself?
<mclasen>
or handling icc profiles, we will eventually use lcms
<mclasen>
I'm trying to keep icc profiles out of this initial work
<pq>
ok
<mclasen>
weston put a wrench into that plan :)
<pq>
You could do what weston-image does, and simply forward the image embedded ICC profile to the compositor.
<mclasen>
well, this is not about images, per se. its about making gtk do its compositing in a defined space, and communicate that to the compositor in the end
<pq>
Or, if you use a CMM, you could get the compositor's preferred image description, and if it's ICC, use the CMM to convert to that client-side, and and tag the surface as such.
<swick[m]>
I remember loupe devs saying that they have ICC profiles that won't get accepted by the cm protocol
<swick[m]>
not sure about the details anymore
<pq>
swick[m], because of the class, I presume.
<swick[m]>
I think also because of non 3 channel profiles
<pq>
all those are such that I'd prefer if the app did its own color management to compositor preferred
kts has quit [Ping timeout: 480 seconds]
<King_DuckZ>
sorry I was out for lunch
<swick[m]>
exactly, I don't want to handle metallic inks and stuff like that
<mclasen>
I've ignored the compositor preferred thing so far, since it is so annoying to get the information about it (two levels of callbacks...)
<pq>
if end users want to tune that, that's something the app should allow
<King_DuckZ>
JEEB: I already have a matrix that seems to work, I put it together from Poynton's book and god knows what else, but rgb -> yuv -> rgb on shadertoy looks correct afaict
<pq>
ok, sounds like Loupe will want to use a CMM itself, targeting the compositor's preferred image description. That's excellent, because that's the case I'm still missing.
<colinmarc>
@pq, @swick - would it be helpful if I documented the conversation about vulkan compatibility today in a comment on the MR (or I guess a separate issue somewhere)? even though we didn't really find a solution, maybe discussion could continue there. if we do figure out a way to make it work, I'm happy to update my mesa draft MR.
nerdopolis has joined #wayland
<King_DuckZ>
my matrix 0.2126*f1, -0.2126/1.8556*f2, 0.5*f2, 0.7152*f1, -0.7152/1.8556*f2, -0.7152/1.5748*f2, 0.0722*f1, 0.5*f2, -0.0722/1.5748*f2 you can just set f1=f2=1, it's just there if you have a smaller gamut
<King_DuckZ>
(I think it's called gamut)
<pq>
colinmarc, I think I am not applicable. I mean, my Vulkan knowledge is nonexistent, and I'm not sure we covered anything new today.
<JEEB>
King_DuckZ: if you need matrix details there's BT.273 that goes over the common ones (and then gives you context for the rest of it like primaries or transfer and color range)
<King_DuckZ>
pq: thanks for checking, ok I'll disregard that link if it's wrong, but it's annoying how it claims that everyone else is wrong and corrects them, just adding to the noise
<King_DuckZ>
"liberal" is wrong in this case, they both are just in different ways (technically gpl maximises freedom, but enough cans of worms for today)
<JEEB>
yea, took a while for me to pick wording :P
<King_DuckZ>
I see what you mean :)
<JEEB>
of course for your own experientation it's fine, your fork just ends up being GPL due to utilizing GPL code
<JEEB>
King_DuckZ: also you can clearly see why I didn't utilize freedom or free as wording :P
<JEEB>
anyways, if you are looking at shader bits you might want to also look at libplacebo for inspiration since it already implements a bunch of the stuff mentioned in H.273
<King_DuckZ>
yes :)
<pq>
Just wait until people ask AI how color works, and write it down. Or just generate docs directly.
<King_DuckZ>
I'm having a look, just lots of links and stuff, it'll take me a while
<King_DuckZ>
imagine if you mixed red, green and x-ray for example
clando has quit [Quit: WeeChat 3.8]
<haasn>
pq: just store your color in the order CrYCb
<haasn>
then you can access .r for the red difference, .b for the blue difference and .y for the luma
<haasn>
problem solved /s
<haasn>
no but we unironically do this in libplacebo for the intermediates during constant luminance decoding :p
nerdopolis has quit [Ping timeout: 480 seconds]
gusnan has quit [Ping timeout: 480 seconds]
kts has joined #wayland
gusnan has joined #wayland
kts has quit [Quit: Konversation terminated!]
KarenTheDorf has joined #wayland
crazybyte has quit [Quit: Ping timeout (120 seconds)]
crazybyte has joined #wayland
<King_DuckZ>
I need some more help, hopefully it's less confusing than earlier today :) how can I pass user parameters to the shader in Weston? for example, from outside user is playing a video and wants to use chroma key green, smoothness=20, and then another video and have key=blue, smoothness=50
<King_DuckZ>
is there a way I can pass such parameters, or is a uniform taken from a global ini config the best I can achieve?
clando has joined #wayland
cmichael has quit [Remote host closed the connection]
cmichael has joined #wayland
cmichael has quit []
<King_DuckZ>
I guess another way to put it, can I attach some sort metadata to the output generated by each program running?
<mwhoosier>
daniels or mvlad: Is there any dedicated hardware path in the weston DRM backend to handle the "transform" key directly in KMS? I had been almost certain that I'd seen plane properties for this before, but now I can't find them.
MrCooper has quit [Remote host closed the connection]
<mwhoosier>
mvlad: Indeed. It turns out that before complaining here, I should have made sure that I wasn't looking at a massively out of date copy of the Weston source tree :(
<King_DuckZ>
ask first, think later - that's what I always do! :p
<King_DuckZ>
as I understand, fragment.glsl runs once for each program
<King_DuckZ>
in gl-renderer.c I have glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA);
tzimmermann has quit [Quit: Leaving]
iomari891 has joined #wayland
<King_DuckZ>
and I have two videos playng on top of each other, my chroma key is not working at all, green screen got desaturated but I don't think alpha is being respected
<King_DuckZ>
I don't see Weston doing glClear or anything, what's going on? have I made the wrong assumptions?
iomari891 has quit [Ping timeout: 480 seconds]
guru__ has quit [Remote host closed the connection]
<daniels>
King_DuckZ: sounds like you need to make libweston consider your format be transparent
paulk-bis has quit []
paulk has joined #wayland
mwhoosier has left #wayland [#wayland]
<King_DuckZ>
daniels: could you point me to where I should look at? I've been trying to follow weston_output, but with callbacks and all it's not easy to figure who's calling who
clando has quit [Quit: kénavo]
kts has quit [Quit: Konversation terminated!]
coldfeet has joined #wayland
kts has joined #wayland
kts has quit [Quit: Konversation terminated!]
rasterman has quit [Quit: Gettin' stinky!]
feaneron_ has joined #wayland
feaneron_ has quit []
sima has quit [Ping timeout: 480 seconds]
<swick[m]>
emersion: probably don't have time to do the libdisplay-info changes in mutter this cycle but good to see anyway
<emersion>
cool!
<swick[m]>
emersion: I'm more worried about libdisplay-info stalling. It was already not great getting one review from you every few month but it looks like it won't improve anytime soon...
<emersion>
the problem is that everybody is busy
<emersion>
same as always
<emersion>
would be really nice to get more contributors involved
<swick[m]>
yeah, whatever the reasons are, it's really frustrating to write code that just gets ignored forever
<swick[m]>
maybe we can recruit jani and hans?
<emersion>
i was going to suggest some KDE folks, but
<emersion>
i think a problem is that only very few people are interested in making it parse all of the specs
<emersion>
and also, very few people are willing to spend the effort to think about API design and such
Narrat has joined #wayland
Brainium has joined #wayland
coldfeet has quit [Remote host closed the connection]
<zamundaaa[m]>
If you point me to a pdf of the relevant spec in each case, I could do reviews at least
xjuan has joined #wayland
mvlad has quit [Remote host closed the connection]
caveman has quit [Quit: caveman]
rv1sr has quit []
feaneron has quit [Quit: feaneron]
feaneron has joined #wayland
Narrat has quit []
glennk has quit [Ping timeout: 480 seconds]
<KarenTheDorf>
emersion: And those of us who aren't busy, are unsure how to help without slowing experienced/professional devs down.
feaneron has quit [Quit: feaneron]
checkfoc_us has quit []
checkfoc_us has joined #wayland
nerdopolis has joined #wayland
Ermine has quit [Ping timeout: 480 seconds]
Ermine has joined #wayland
riteo has joined #wayland
nerdopolis has quit [Quit: No Ping reply in 180 seconds.]