he measurement would be at the
pixel depth resolution of the output of the per channel tables.
Naturally to make use of this, access to the per channel
tables contents is necessary, to setup the mapping
from the frame buffer value to the value sent to the
display.
Cheers,
Graeme Gill.
__
instrument of some sort to be able to measure prints, as well
as better characterize their displays.
Graeme Gill.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
more complete description of the pixel values, and implement a more
natural model of how things are ?
2) How would this be implemented, since (AFAIK) the server wl_buffer structure
is assumed to be private to the back end implementation ?
(That's something I have a couple more mo
any others, without delving deeper, but intuitively
the last options seems the cleanest. I presume it has core
protocol versioning implications though.
[ Of course every back end will need to be modified to actually
support the color transform a
he client
to have to keep track of the colorspace when submitting the buffer
as an update, since as a property of the wl_buffer, it tracks right
along with the pixel values.
Cheers,
Graeme Gill.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
tch, the colorspace
has to be
transformed.
Some formats (i.e. YCbCr) have different gamuts, and therefore might have
different color
profiles that reflect differences in color handling due to the different gamuts
sizes and
shapes. (A good compos
management sense !
> If you have specific suggestions, please post them to the xorg-devel
> mailing lists or create a merge request at
> https://gitlab.freedesktop.org/xorg/xserver/merge_requests .
Fair enough.
Cheers,
Graeme Gill.
___
ons, and needs access
to all the ordinary application facilities for providing a UI that
the user can use (and access to connected hardware, typically via
USB or Bluetooth).
Thanks,
Graeme Gill.
___
wayland-devel mailing list
up to now, and at least is possible
thanks to some foresight on the designers and implementer s part.
Cheers,
Graeme Gill.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Kai-Uwe wrote:
Hi,
> Device links are a serialisation of a color transform. lcms supports to
> dump color transforms to device links and load a device link into a
> color transform. Device link profiles come with little effort. Device
> links provide applications a entry to let the compositor do
s disappointing a change with such serious implications for
X11 color management was made without any consultation or even
notification to those that would be affected.
What order are all these things composed ?
Thanks,
Graeme Gill.
___
wayland-d
Chris Murphy wrote:
Hi Chris,
> Not every desktop environment is using the same Wayland compositor, or
> even a Wayland compositor at all. So is drm/kms something you can
> depend on most of the time regardless of the desktop?
I'm sure you could get even wider coverage of color management
tools
Chris Murphy wrote:
> Hmmm. For a while now we've had display calibration+profiling
> applications compel full screen mode so they're not really usable
> alongside anything else. They are in effect taking over. So if it's
> possible for the calibration app to set aside the Wayland session, use
> d
Chris Murphy wrote:
Hi Chris,
> Real displays often are not gray balanced. Calibration should achieve
> this, often it can't. What if the display is characterized and not
> calibrated to force R=G=B to be a neutral. And also what is neutral?
> Usually the black point xy (chromaticity, CIE xyY spa
from a color management point of view. So when
I load up an ICC display profile I really need to reset
all of that to be certain the screen is color calibrated!
Cheers,
Graeme Gill.
___
wayland-devel mailing list
wayland-devel@lists.freedeskt
a very demanding wayland
> client.
Right, but there needs to be facility for privileged Wayland clients
that can configure the wayland server as an agent of the user.
Cheers,
Graeme Gill.
___
wayland-devel mailing list
wayland-devel@lists.f
Carsten Haitzler wrote:
> On Wed, 6 Mar 2019 16:37:55 +1100 Graeme Gill said:
> it involves a screen or set of screens "flashing" between different
> colorspaces. it's much the same kind of effect of ye olde colormap installs.
> not as extreme, but still the ent
t blending in the output color
> space then.
Blending isn't a problem if it doesn't alter the pixel values
for opaque surfaces.
Cheers,
Graeme Gill.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Sharma, Shashank wrote:
>> From: Graeme Gill [mailto:grae...@argyllcms.com]
>>>> From: Ankit Nautiyal
>>>>
>>>> This protcol enables a client to send the hdr meta-data: MAX-CLL,
>>>> MAX-FALL, Max
>>>> Luminance and Min Luminan
or (perhaps) matrix & Luts or 3D texture is a necessary
performance
optimization in the compositor implementation. But this should be invisible
to the applications.
Cheers,
Graeme Gill.
___
wayland-devel mailing list
wayland-devel@lists.fre
ent thinking here:
<http://www.argyllcms.com/WaylandCM_v1.txt> for anyone interested.
Cheers,
Graeme Gill.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
esigned 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 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
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
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.
___
e 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 colors
ck
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.
_
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
> ha
profiles?
As I understand it, no they don't. They either rely on a stated
encoding (i.e. REC2020 based), or sometimes have simple meta-data
such as primary coordinates & transfer curve specifications. A client
wanting to support such meta-data can simply
) should be able to be referred to by a handle or
object identifier, and that would be what is used to tag
the output or surface.
Cheers,
Graeme Gill.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
, that all client content gets converted according to the client
> provided ICC profiles to CIE XYZ, composited/blended, and then
> converted to output space according to the output ICC profile.
See all my previous discussions. This approach has many problems
when it comes to gamut and intent.
ze them
to map 0 and 1 unchanged.)
Compositing in a linear light space has to occur to sufficiently high
precision of course, so as not to introduce quantization errors.
After composition the inverse curves would be applied to return to the
output device space.
Cheers,
Chris Murphy wrote:
Hi Chris,
> Well you need a client to do display calibration which necessarily
> means altering the video LUT (to linear) in order to do the
> measurements from which a correction curve is computed, and then that
> client needs to install that curve into the video LUT. Now, co
ICC profile is stored in its header.
Cheers,
Graeme Gill.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
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.
Cheers,
Graeme Gill.
_
al and gamut transformations chosen by the profile maker, so
a nominated ICC profile can encompass a variety of treatments or intent
within the formalized ICC Perceptual and Saturation intents. There often
is no formal scheme for such variations, just the name, description and
other notes that come wit
Chris Murphy wrote:
Hi Chris,
> I'm pretty sure most every desktop environment and distribution have
> settled on colord as the general purpose service.
> https://github.com/hughsie/colord
> https://www.freedesktop.org/software/colord/
right, but colord is not needed to run X11 color management.
Pekka Paalanen wrote:
> Graeme Gill wrote:
Hi,
>> I don't have any basis to voice an opinion as to which particular protocol
>> these different aspects would best fall into (wayland core or one of the
>> supplementary xdg protocols ? - I'm not clear on what the p
aracteristics of a monitor will likely
> require a notion of intent to a Wayland compositor. Not only one wants
> to be absolutely sure the compositor is not mangling the pixel data,
Quite the contrary - see above. If the compositor is mangling
take the HDR monitors as being nominally HDR10 or similar,
then you can
do a by-the-spec conversion and get something working.
Cheers,
Graeme Gill.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
lways be added to the hybrid/fallback scheme
at a latter point ?
Cheers,
Graeme Gill.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
ntent with
> specific color properties for now.
It's a necessary part of the picture. There's not much point in
moving ahead with Color Management support if there is no
easy means of creating display profiles to populate it with. So in
terms of practical implementation I see them goi
(ideally) by downloading the curve to the display
itself (many high end displays have this capability, and the
commercial CM tools do exactly that. How that could work with
Wayland is another problem to ponder.)
Cheers,
Graeme Gill.
___
wayland
provides no
access to the CRTC by client software).
Perhaps it's worth re-visiting some of the ideas about how to add Color
Management
to Wayland, to see how HDR could fit into it ?
regards,
Graeme Gill
(Author of ArgyllCMS <http://www.argyllcms.com/>)
_
Hi Chris,
let me give a more considered reply:
The conventional wisdom using video LUTs for calibration came about with CRTs.
Pretty much
all of that has to be thrown out with LCD's - they have a natural TRC that's
nothing like
a CRT, what the manufacturers have done is glue in hard wired tr
Chris Murphy wrote:
> On Mon, Dec 26, 2016 at 10:25 PM, Graeme Gill I'm not sure what you are thinking of here - the existing per channel
> VideoLUT API's are universally simple, and the only temptation in
> making changes to this might be in the direction of
;d also rather hope (but haven't had any confirmation)
that HW that permits 10 bpc frame buffers has 12 bit
VideoLUT precision
Graeme Gill.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Chris Murphy wrote:
Hi Chris,
> As for CIEXYZ, to literally convert pixels into this space, or even as an
> exchange space,
> it will require minimum 16 bits per channel or there will be noticeable
> quantization. It's
> a huge color space. You could maybe get away with 8 bit per channel CIE
>
;m reasonably certain that there are other
mechanisms available too, if a color managed workflow was
available, by suitable construction of input and/or
output device profiles. (This is an area that I'm
currently doing a little research into.)
Cheers,
Graeme Gill.
___
;d also rather hope (but haven't had any confirmation)
that HW that permits 10 bpc frame buffers has 12 bit
VideoLUT precision, particularly with HDR now being a thing.
Graeme Gill.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
n to be largely effective.)
> I don't think anyone doubts your expertise in the specific field, but
> much like a compositor with no explicit information on client colour
> properties, I'm having to try to walk back on your reasoning, to go
> from specific solutions you appear to be demanding, back to actual
> first-order problems. A lossy and frustrating exercise.
On the contrary, I think I've given copious levels of "big picture" to
back up specifics. Perhaps the overall context means that I'm not being
understood.
Regards,
Graeme Gill.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
's, but I think seeing how the commercial
software operates as well, would add a broader perspective.)
I can keep writing a lot of words, but they don't seem to
be conveying much meaning without some common context.
Cheers,
Graeme Gill.
___
w
ngle
transform @ 16 BPC), and MadVR uses a 256 x 256 x 256 table for
it's color, i.e. 100 Mbytes using the GPU. And multiple
applications may use multiple transforms.
In practice I wouldn't expect apps. to normally push these limits,
because most of this stuff o
ion calibration curve, how does
the application install it for loading into the correct CRTC when
Wayland is running ? (Packing it in some ICC profile may solve
normal usage situations, if there is a profile, but cuts off
other current uses such as checking that the Vi
ion will not happen.
That's all good - but aren't these the sorts of controls
that other applications need too ?
Slide show or Video player apps need to prevent screensaving,
modal dialogs need to be able to pop to the top of
the window s
agement or basic color management for
otherwise non-color managed applications would
certainly be a good thing as well, and a reason to
incorporate at least some basic CMM capabilities in
the compositor.
Having a standardized means of coordinating the
display profile would make it possible for the compositor
to use that information to provide better blending and
anti-aliasing behavior at some cost to performance,
although color sensitive users probably won't want
to make use of transparency.
Regards,
Graeme Gill.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
endent colorspaces. Where the pixels
reside or what the buffers are shared with, or
how the pixels get spatially transformed is mostly irrelevant.
The device colorspaces that the buffers value represent is what's
important from a color management perspective.
Regards,
Graeme Gill.
__
filing, to what it is for normal application display.
Regards,
Graeme Gill.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
ation and profiling and complex
linking, etc. etc. - no - they are user applications. Users
want to be able to pick and choose between such applications, not
be locked into a single implementation. This fosters
competition and innovation, just like any other application
area.
Graeme Gill.
___
applications.
There are other approaches possible, which attempt to
split up the color management operation into two
independent parts, but these approaches tend to be
highly imperfect in terms of performance,
quality (i.e. banding), gamut hand
ities is
something of a project, and might not even be a good direction to proceed
if other alternatives are a more enticing use of time and effort (installable
shaders in the rendering pipeline ??)
Regards,
Graeme Gill.
___
wayland-devel mailing list
links as a means of
conveying the desired transform ? What about HDR etc.
as a test case ?
This doesn't address any of the problems of supporting
calibration, profiling or color setup, nor how display
profiles are installed or read by applications.
Cheers,
Graeme Gill.
___
f things I've said being
understood, or even taken seriously. (And yes, I will continue
to poke away at understanding Wayland a little better.)
> This thread has been enough of a catastrophe so far that it's taken me
> around half a day to actually properly read thr
t. Tools, standards and workflows are already geared to this
mechanism.
Cheers,
Graeme Gill.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
easy to not appreciate
some of the subtleties that none the less have an impact
in the real world. I'm really not sure how I can expand
on this much more, but I'm willing to continue trying
for a while, so can you point to where you want me
to start ?
Cheers,
Graeme Gill.
_
ing in
the native output space (fast and dirty), or blending in
a per-channel linear light output space at higher precision (say
16 bit or half) would result in linear light blending without
having any impact on color gamut or color precision for each output.
Graem
and objections have
been raised to providing the application with this information.
Graeme Gill.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
ant some other intent such as perceptual or saturation
gamut mapping).
Cheers,
Graeme Gill.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
e.
The chicken and egg problem remains - how do color management
applications exercise the hardware to create calibration curves,
as well as help manage the display color configuration by
installing profiles, etc. ?
Without the ability to create the calibration and profile,
you don't have a c
Richard Hughes wrote:
> On 20 December 2016 at 07:22, Graeme Gill wrote:
>> Or be prepared to re-visit Wayland's fundamental design decisions
>> if they turn out to be based on a false premise.
>
> I don't think that's fair. I think Wayland is the opportunity
that point of view.)
Graeme Gill.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
acteristic is
determined by the display primary spectral characteristics,
and a change in representation/encoding doesn't imply
any change in the primaries. Even the RGB's haven't changed,
because the relationship between RGB <-> YCbCr is fixe
Pekka Paalanen wrote:
> On Tue, 20 Dec 2016 15:17:31 +1100
> Graeme Gill wrote:
> When I was talking about configuration, your reply talks about content
> delivery. We are continuously talking past each other. I talk about one
> thing, you deliberately interpret me talking about
though, just a different color encoding,
since the primaries haven't changed.
Analogous examples: XYZ and Yxy space. XYZ and L*a*b* space. RGB and LCH.
Graeme Gill.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.free
exities in a way that is compatible
> with Wayland's fundamental design decisions.
Or be prepared to re-visit Wayland's fundamental design decisions
if they turn out to be based on a false premise.
Graeme Gill.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
cks will soon start
>> to show with remote versions of Wayland. The whole point of creating a
>> protocol such as Wayland is to provide a common API that can be used
>> by all applications that are intended to run on Wayland.
>
> Indeed, that is the job of the desktop envi
ch.) Both ideas have similar issues -
you really want the per output pixels or device links to
be provided by the application on demand - i.e. when a surface
first overlaps an output, so that it doesn't have to pre-compute
pixels or device links for all possible outputs, even if they
never get u
Carsten Haitzler (The Rasterman) wrote:
> On Sat, 17 Dec 2016 21:16:41 +1100 Graeme Gill said:
>> That's not a typical situation though, but nothing special would be
>> happening - a new profile may be installed by the user as well,
>> in which case an application shoul
obviously on professional applications. I think both use cases
> are equally important and we should not treat one as an afterthought of the
> other.
Right. I agree, but technically I think one builds on the other.
> I would be glad if we could come up with a
Pekka Paalanen wrote:
> On Wed, 14 Dec 2016 18:49:14 +1100
> Graeme Gill wrote:
>> Please read my earlier posts. No (sane) compositor can implement CMM
>> capabilities to a color critical applications requirements,
>> so color management without any participation of a
Carsten Haitzler (The Rasterman) wrote:
> On Tue, 13 Dec 2016 17:46:25 +1100 Graeme Gill said:
> a display may not have a single native colorspace. it may be able to switch.
> embedded devices can do this as the display panel may have extra control lines
> for switching to a diffe
Carsten Haitzler (The Rasterman) wrote:
> On Tue, 13 Dec 2016 17:14:21 +1100 Graeme Gill said:
> this == support for color correction protocol AND actually the support for
> providing the real colorspace of the monitor, providing non SRGB pixel data by
> clients in another colorspa
Carsten Haitzler (The Rasterman) wrote:
> On Mon, 12 Dec 2016 17:57:08 +1100 Graeme Gill said:
>> Right. So a protocol for querying the profile of each output for its surface
>> is a base requirement.
>
> i totally disagree. the compositor should simply provide availab
Carsten Haitzler (The Rasterman) wrote:
> On Mon, 12 Dec 2016 18:18:21 +1100 Graeme Gill said:
>> The correct approach to avoiding such issues is simply
>> to make both aspects Wayland (extension) protocols, so
>> that Wayland color management and color sensitive app
hat point.
See my previous suggestion - use a linearised light output display space
for compositing - it's simple, fast, and there are no gamut issues.
Graeme Gill.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.
controlling screen colorspace.
I'm not sure what you mean by that. Traditionally applications render
to the display colorspace. Changing the display setup (i.e. switching
display colorspace emulation) is a user action, complicated only by the
need to make the corresponding
Carsten Haitzler (The Rasterman) wrote:
> well graeme disagrees and effectively thinks it should be. :)
I said no such thing!
Graeme Gill.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mail
Carsten Haitzler (The Rasterman) wrote:
> On Fri, 9 Dec 2016 15:30:40 +1100 Graeme Gill said:
>> I thought I'd explained this in the previous post ? - perhaps
>> I'm simply not understanding where you are coming from on this.
>
> you didn't explain b
Niels Ole Salscheider wrote:
> Am Donnerstag, 8. Dezember 2016, 15:51:12 CET schrieb Graeme Gill:
>> Looking through the current Wayland color-management protocol
>> proposal, I think it is missing a really fundamental thing -
>> managing the output device color calibr
Niels Ole Salscheider wrote:
> Am Donnerstag, 8. Dezember 2016, 13:33:20 CET schrieb Graeme Gill:
Hi,
>> I'm not quite sure what you mean. Generally an application will have
>> specific reasons for wanting to do it's own color management - for
>> instance, perhap
device color space (or just ignore it if you
> do not care about accurate colors).
I want to see the latter supported before the former.
Graeme Gill.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/m
lor management onto applications
that are not color aware.
If this doesn't make sense to you, then perhaps the best thing
would be for me to lay out the nuts and bolts of what's happening
in these different color management scenarios.
Cheers,
Graeme Gill.
___
port for core color management (i.e. application
color management), before adding layers that depend on the core.
Graeme Gill.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
rrent support for configuring
CRTC's, Outputs etc., there still seem to be some big gaps to fill to add
even core color management support as part of the Wayland protocol.
Graeme Gill.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
e MD5 fingerprint value was only introduced
in ICC V4, and so is not present in ICC V2 profiles. Even in V4
profiles, it is recommended rather than mandatory, so can't be relied upon.
Graeme Gill.
___
wayland-devel mailing list
wayland-devel@lists
sabling application-side color
management is a fundamental step in achieving end to end color management.
You don't have color management until you are able to profile the output device,
so this is not something that can be left until latter!
Graeme Gill.
_
tion and support of
established
systems such as X11. ie. We should be aiming for the current set of X11 color
management tools to just work when X11 is running on top of Wayland, not have
things such as XRandR simply stop working.
Graeme Gill.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
mbers instead of 8.
A lot of display folk are very chromaticity diagram oriented - they are used to
just
specifying xy, and it's nice to have the white point be explicit so you can
more easily
check what the white point color temperature is.
Graeme Gill.
ss all entries from anywhere.
That assumes all entries have been parsed.
Graeme Gill.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
tring as the buffer's color
space) so it does not have to open a CMS library that it might otherwise
not be using.
If that's the case, I'd suggest having a string that turns the color management
off. Much simpler and more direct as to the intention.
Graeme Gill.
__
1 - 100 of 104 matches
Mail list logo
