Re: HDR support in Wayland/Weston
Pekka Paalanen wrote: > I presume the measurement or calibration use case always involves > "owning" the whole monitor, and the very specific monitor at that. That > is, making the monitor temporarily exclusive to the app, so that > nothing else can interfere (e.g. instant messaging notification popping > up just under the measurement sensor). That would also give an > opportunity, if wanted(!), to bypass compositor color conversions and > do or not do anything else special. It really doesn't have to have exclusive access. Being able to display a window at a specific location & size and in a way that can't be overlayed by any other window or hidden by a screensaver is sufficient. > IOW, measurement/calibration/characterization is off the scope of the > currently on-going discussions. A separate protocol yes. But it needs to be co-designed and developed so that the two work together and can be tested together. You can't sign off on the "using" protocol without knowing that it actually works with the "setting" protocol, and its making life hard to try and test the first without the existence of the second. Cheers, Graeme Gill. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: HDR support in Wayland/Weston
Carsten Haitzler (The Rasterman) wrote: > apps should not have exclusive access. we're re-doing the whole horrid > "install > colormap" thing from the x days of 256 color (or paletted/colormapped > displays). It's not quite the same thing in all cases. A game doing this - yes, it's setting it up just for its private use. Color calibration or "blue light filter" not really - they are using it as a mechanism for deliberately altering the color of the whole display so that it affects the appearance of all other applications. Whether the latter two are in conflict is an interesting question. For the purposes of getting a known color behavior they are in conflict. But then they could also co-operate :- the "blue light filter" could make use of color management to implement a specific transform, and do it in such a way that the white point relative color behavior remains unchanged. Cheers, Graeme Gill. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: HDR support in Wayland/Weston
Simon Ser wrote: > On Monday, March 4, 2019 8:13 AM, Graeme Gill wrote: >> 2) Implement virtual per channel LUTs, with the compositor combining them >>together in some way, and have some means of the color management >> applications >>being aware when the display is being interfered with by another >> application, >>so that the user can be warned that the color management state is invalid. > > Is there a "good way" to combine multiple LUTs? It might be possible to compute aproximately color correct device value curves that can be combined together, based on the ICC profile characterization. The advantage of this is that it could be applied to a display without any application having to be aware of it (although a color critical application may want to be able to warn the user.) >> 1) A color managed API that lets an application shift the display white point >>using chromatic adaptation, so that such blue light filter applications >>can operate more predictably, as well as some means of the color >> management >>applications being aware of when this is happening. > > How should this look like? Disclaimer: I have no idea how these applications > work and I know nothing about color management. The logical way of supporting this in ICC profile terms would be to allow for the insertion of an ICC Abstract Profile in the color conversions (This is a PCS -> PCS transform. So you would do a Source Dev->PCS, Abstract PCS->PCS, Destination PCS->Dev). A chromatically correct white point shift would be pretty simple to specify as an abstract profile. Conversions done by the Compositor could incorporate the abstract profile in the linking. Conversions done by color aware applications could not be forced to honor the abstract profile, but they could choose to honor it, and they would explicitly be aware of the color modification although not the reason/intent of it without some extra meta information. > I'm guessing this is a restriction of the "change the whole LUTs" API. Are > there > any features the "blue light filter" app won't be able to implement when > switching to this API? Good question. I'm not aware of the range of applications that do this kind of thing. I guess a search of open source apps that use the relevant API's might give a clue. > Would the compositor part become complicated (judging > from [2] it seems different "blue light filter" apps may compute LUTs > differently)? A little, it shouldn't add much since lcms supports Abstract profiles. Cheers, Graeme Gill. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: HDR support in Wayland/Weston
Adam Jackson wrote: Hi, > X kinda has three mechanisms for this. The first one, that nobody > really uses, is setting the colormap for a DirectColor visual. Actually this is something I check and set to linear before calibration & profiling in the ArgyllCMS tools. > The > second, which games typically use, is setting per-channel gamma > (implicitly for the whole screen) as single floating-point values with > the xf86vidmode extension. Typically this is too crude a control for color management use. My assumption (which could be wrong) is that this is overridden by the per-crtc LUT. > The third, which desktop environments > sometimes use to try to make distinct displays look similar, is setting > per-crtc gamma as 256 (or whatever) stops per channel with the RANDR > extension. This is the avenue for implementing the Apple/ICC 'vcgt' calibration tag under X11 (and analogous to the API's in other operating systems). > All of these are effectively the program specifying its transformation > to what it hopes is linear in device space. The sample server happens > to implement all three as global state, but that's an implementation > detail. It would be straightforward to give each Xwayland client the > illusion of complete control if we wanted. For the purposes of setting the display global color calibration state, then this is not desirable. Cheers, Graeme Gill. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] unstable: add HDR Mastering Meta-data Protocol
Pekka Paalanen wrote: > The only question is, do color management and HDR support conceptually > make sense as independent features, or would implementations always > support both with essentially the same effort? In my view, you can certainly add an HDR extension independently of a color management extension, but it would either be a hack to get things working (i.e. make all sorts of general display colorspace assumptions or approximations) or if less hacky, would start to encompass general color management concerns. A Color Management extension on the other hand adds a bunch of non-HDR related stuff, but HDR then slots in as a sub-case of handling differences in display characteristics. > "Supporting HDR" here means only that the compositor is able to process > HDR content from clients, it does not include the capability to drive > HDR monitors. IOW, a compositor that only converts HDR content to SDR > is a valid HDR implementation from protocol perspective. It merely > advertises all outputs as SDR. True, but once you allow for a display to be labelled HDR and have an associated color profile, there isn't that much to handling HDR like any other display. > The big question here is: does a HDR video, with reasonable defaults if > not explicitly defined, allow to programmatically manufacture a custom > ICC profile with the HDR primaries? Yes, this works. Some HDR TV calibration already takes this approach. > What I mean is, if a compositor implements color management, is there > any good reason to not implement HDR luminance mapping as well? At > least the implementation would not differ, just the parameters or > tables. That is why I suspect supporting HDR will be easy on top of a > good color conversion implementation. I agree. > Harish Krupo wrote: >> Out-of-gamut pixels are handled completely separately compared to >> out-of-dynamic-range pixels. Out of gamut can be solved either clamping >> the color after conversion or by using a nearest approximation of the >> color available within the colorspace. >> Out-of-dynamic-range OTOH, requires applying tone mapping to adjust the >> luminance ranges. Adapting the luminance range is just another aspect of mapping one color space to another. One mechanism for achieving this is to use a relative colorspace description of the spaces and then use an orthogonal luminance mapping (such as tone mapping for HDR -> SDR). > I thought that some of the rendering intents of color management do the > same as HDR luminance mapping. Do they not? Only few parameters more to > adjust the ranges of the mapping curves. Standard ICC intents generally do not, because most of them work around a Relative Colorimetric assumption. Absolute Colorimetric in theory could support this, but in practice is not a mechanism that would work the way you want for HDR handling (i.e. it would work for SDR->HDR, but would clip HDR->SDR, and would have the side effect of not aligning the white points, which you probably don't want it to do.) But I think it should be relatively straight forward to augment the standard ICC CMM linking parameters with some HDR options. (In terms of implementation I would hope that lcms's plugin architecture would help facilitate this, or at worst it could be patches and the changes fed back upstream to Marti). The two options I would imagine adding would be SDR->HDR brightness (i.e. what the SDR white brightness should be), and for HDR->SDR what the HDR diffuse white is and possibly a tone mapping strategy. (The technical details of this can be guided by something like the ITU-R BT.2390-2 EETF). > It is also likely that color management will need a wl_output extension > object of its own, so if HDR information can be integrated in that, it > would be simpler to use. Yep. > There is no need to ensure at the protocol level. If the compositor > advertises HDR support and there exists at least one HDR output, the > player should always produce HDR frames if possible, especially if it > is cheaper for the player than SDR. The compositor will take care of the > SDR conversion if necessary, and there won't be glitches if the window > moves between HDR and SDR monitors as there is no need for the client > to catch up. In a color managed implementation, the player just need mark the source with the video ICC profile and HDR intent information for default handling by the Compositor. If it wanted to do the HDR handling itself, it would download the output ICC profile to figure out its conversion from video source to output space, and then mark the buffer as being in the primary output colorspace so that the Compositor knows it doesn't have to do anything. Cheers, Graeme Gill. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland-protocols v2 1/1] Add the color-management protocol
Pekka Paalanen wrote: > Sebastian's protocol proposal includes render intent from applications. > Conversion of client content to the blending space should ideally be > lossless, so the render intent in that step should be irrelevant if I > understand right. How to deal with render intent when converting from > blending space to output space is not clear to me, since different > windows may have different intents. Using the window's intent for the > window's pixels works only if the pixel in the framebuffer comes from > exactly one window and not more. Conceptually the conversion from source space to destination is a single step, with a single intent. So conceptually any conversions after this for the purposes of blending don't have to pay any regard to intent - it's already applied. Blending could convert from the device space back to XYZ, blend, and then convert back to device space. It would use whatever intent is appropriate for blending purposes, i.e. probably Relative Colorimetric. But I doubt this is the best approach. (see my previous post on blending.) Cheers, Graeme Gill. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland-protocols v2 1/1] Add the color-management protocol
Chris Murphy wrote: > 1.0. So yeah for HDR that information is useless and is one of the > gotchas with ICC display class profiles. There are optional tags > defined in the spec for many years now to include measured display > black and white luminance. For HDR applications it would seem it'd > have to be required information. It's easy enough to mandate that a profile for a display marked as HDI include the luminance tag. Or simply reject any display profile that is missing the tag. Cheers, Graeme. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[ANNOUNCE] wayland 1.16.92
This is the beta for the upcoming 1.17 release. Changelog: Derek Foreman (1): configure.ac: bump to version 1.16.92 for the beta release Leonid Bobrov via wayland-devel (1): tests: fix main symbol duplication Simon Ser (1): protocol: warn clients about some wl_output properties git tag: 1.16.92 https://wayland.freedesktop.org/releases/wayland-1.16.92.tar.xz MD5: 47b83f7b18795be0f69ee135e515566e wayland-1.16.92.tar.xz SHA1: 18d03c349c4737f3b77acde05db29b8611047cbd wayland-1.16.92.tar.xz SHA256: 18fd76c0f4fc21e14225a8fd03c89619e77751fb19b417c66cb7477d10be0660 wayland-1.16.92.tar.xz SHA512: d28eba0b9f4162378df08e59efe0aa099603942732735b09b5811700b5d5e130314833b5bd0604d4be5c1b89bb2b6a1e86dc14520703f73fd4c3a5cc7fab3ea2 wayland-1.16.92.tar.xz PGP: https://wayland.freedesktop.org/releases/wayland-1.16.92.tar.xz.sig ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[ANNOUNCE] weston 5.0.92
Here's the beta for the upcoming weston 6.0 release. Mostly bug/typo fixes here, as should be the case at this point in the cycle. Changelog: Alexandros Frantzis (1): clients/simple-dmabuf-egl: Create the EGL display using the GBM platform Daniel Stone (1): compositor-drm: Add missing newline to debug print Derek Foreman (1): configure.ac: bump to version 5.0.92 for the beta release Emmanuel Gil Peyrot (1): Fix typos all around (thanks codespell!) Philipp Zabel (1): compositor-drm: fix gbm_bo_get_handle_for_plane error handling git tag: 5.0.92 https://wayland.freedesktop.org/releases/weston-5.0.92.tar.xz MD5: 1409f3b4fa87cf72ec5dc0e1e2c6957c weston-5.0.92.tar.xz SHA1: 981b39d23d30a0c417f031df30306b67808819ed weston-5.0.92.tar.xz SHA256: 89b804a10f331c2933a8b5c3eaf1427cc94ca7743521836b2f5046e46c7fe1d8 weston-5.0.92.tar.xz SHA512: 3d19e5f0e0470288793ff2608f340b20750ee03835fd29e482790cbdcde74335615dd05c59ebd202d47f0280dc101d8408ceb920d278dabd7e5a54eb85f27078 weston-5.0.92.tar.xz PGP: https://wayland.freedesktop.org/releases/weston-5.0.92.tar.xz.sig ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland-protocols v2 1/1] Add the color-management protocol
Am Mittwoch, 27. Februar 2019, 14:17:07 CET schrieb Pekka Paalanen: > On Tue, 26 Feb 2019 18:56:06 +0100 > > Kai-Uwe wrote: > > Am 26.02.19 um 16:48 schrieb Pekka Paalanen: > > > On Sun, 22 Jan 2017 13:31:35 +0100 > > > > > > Niels Ole Salscheider wrote: > > >> Signed-off-by: Niels Ole Salscheider > > > > > > My failing is that I haven't read about what ICC v4 definition actually > > > describes, does it characterise content or a device, or is it more > > > about defining a transformation from something to something without > > > saying what something is. > > > > ICC v4 is a specification from 2010 and became in the same year ISO > > 15076-1:2010. Both specs are technically identical. The standard > > describes the content of a color profile format and gives some hints on > > how to handle color transforms. The v4 ICC profiles, as previous ICC v2 > > profiles too, can describe device color characteristics in relation to a > > reference color space (ProfileConnectionSpace PCS CIE*XYZ or CIE*Lab). > > This most often variant is used for color space characterisation, e.g. > > sRGB or device characterisation (monitors, cameras, ...). With this > > variant the compositor takes over responsibility and uses intelligence > > to combine the input source profile with perhaps effect profiles, for > > white point adjustment, red light reduction etc... and a final output > > profile into one color transform. The transform is then applied as 3D > > texture/shader depending on the actual compositor implementation. > > > > A ICC profile class variant, called device link profiles, can describe a > > color conversion without a reference color space, e.g. RGB->RGB. More > > below > > ... > > > >> + > > >> + +With this request, a device link profile can > > >> be attached to a +wl_surface. For each output on which the > > >> surface is visible, the +compositor will check if there is a > > >> device link profile. If there is one +it will be used to > > >> directly convert the surface to the output color +space. > > >> Blending of this surface (if necessary) will then be performed in + > > >> the output color space and after the normal blending operations.> > > > > Are those blending rules actually implementable? > > > > > > It is not generally possible to blend some surfaces into a temporary > > > buffer, convert that to the next color space, and then blend some more, > > > because the necessary order of blending operations depends on the > > > z-order of the surfaces. > > > > > > What implications does this have on the CRTC color processing pipeline? > > > > > > If a CRTC color processing pipeline, that is, the transformation from > > > framebuffer values to on-the-wire values for a monitor, is already set > > > up by the compositor's preference, what would a device link profile > > > look like? Does it produce on-the-wire or blending space? > > > > > > If the transformation defined by the device link profile produced > > > values for the monitor wire, then the compositor will have to undo the > > > CRTC pipeline transformation during composition for this surface, or it > > > needs to reset CRTC pipeline setup to identity and apply it manually > > > for all other surfaces. > > > > > > What is the use for a device link profile? > > > > A device link profile is useful to describe a transform from a buffer to > > a match one specific output. Device links can give a very fine grained > > control to applications to decide what they want with their colors. This > > is useful in case a application want to circumvent the default gamut > > mapping optimise for each output connected to a computer or add color > > effects like proofing. The intelligence is inside the device link > > profile and the compositor applies that as a dump rule. > > Hi Kai-Uwe, > > right, thank you. I did get the feeling right on what it is supposed to > do, but I have hard time imagining how to implement that in a compositor > that also needs to cater for other windows on the same output and blend > them all together correctly. > > Even without blending, it means that the CRTC color manipulation > features cannot really be used at all, because there are two > conflicting transformations to apply: from compositor internal > (blending) space to the output space, and from the application content > space through the device link profile to the output space. The only > way that could be realized without any additional reverse > transformations is that the CRTC is set as an identity pass-through, > and both kinds of transformations are done in the composite rendering > with OpenGL or Vulkan. > > If we want device link profiles in the protocol, then I think that is > the cost we have to pay. But that is just about performance, while to > me it seems like correct blending would be impossible to achieve if > there was another translucent window on top of the window using a > device link
Re: [PATCH v8 2/6] tests: support waitpid
On Mon, 4 Mar 2019 22:21:44 +0200 Leonid Bobrov wrote: > You know, I think this whole patch is silly, because waitid() is part of > POSIX, FreeBSD and NetBSD implement it while OpenBSD and DragonFly BSD > don't. I'll ask OpenBSD upstream to merge NetBSD's implementation and > DragonFly BSD upstream to merge FreeBSD's implementation. > > OpenBSD aims standardization so we should blame OpenBSD. Ok, sounds good to me. Whether that happens or not, I don't see a reason to keep two different paths in these specific cases of waitid/waitpid, because using waitid does not seem to have any benefit over waitpid here. Thanks, pq pgpVVQXw9jYGJ.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
