On Sat, Feb 29, 2020 at 7:07 PM Chris Murphy wrote:
>
> Hi,
>
> I just came across this and it seems it might be related; but someone
> else will need to evaluate whether it's applicable or adequate.
>
> https://lwn.net/Articles/813254/
> https://www.fsf.org/blogs/sy
Hi,
I just came across this and it seems it might be related; but someone
else will need to evaluate whether it's applicable or adequate.
https://lwn.net/Articles/813254/
https://www.fsf.org/blogs/sysadmin/coming-soon-a-new-site-for-fully-free-collaboration
--
Chris M
peline and compositor. There are
many on Linux. Even multiple wayland compositors. And they're
potentially used in combination on top of each other. I'm thinking of
Qubes OS where each application runs in a VM. What about flatpaks and
snap applications? The idea each net pipeline is different and would
need to be characterized, doesn't sound workable.
--
Chris Murphy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
ight have for the rest of the displays that
aren't self-calibrating, is lack of platform support parity for the
various video card LUTs. But for that (important) detail, it should
otherwise be true that an ICC profile describes the display's state
regardless of the display rende
On Thu, Mar 7, 2019 at 3:15 AM Michel Dänzer wrote:
>
> On 2019-03-07 8:05 a.m., Chris Murphy wrote:
> > Of course. It can take 5-30 minutes to do a calibration and
> > characterization. In particular if I have 2, 3 or even 4 displays
> > connected I'd want to cal
SO defined (via
PDF) blending operations.
--
Chris Murphy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
On Wed, Mar 6, 2019 at 10:02 PM Graeme Gill wrote:
>
> 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
se
drm/kms full screen, and then restore the Wayland session I might be
OK with it. But if I have to log out, not OK.
--
Chris Murphy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
on purchase of a
> gpu and/or a monitor).
Weekly or monthly is common once you own such hardware. Display
behavior changes quite a bit, and can be highly variable depending on
the component sourcing for the light source.
About the only device profile good for the life of the device, is a
ca
linear ProPhoto
RGB (same primaries as ROMM RGB, using gamma 1.0 function instead of
1.8).
A possibly important side topic to understand about rendering intent
transforms: it is not intelligent or dynamic.
--
Chris Murphy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
ee output class have one A2B table (device to
PCS), which is what applies in the application display use case, with
the rendering intent choices pointing to that table.
--
Chris Murphy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Quite a lot of color management transform engines look for such
source=destination and optimize them away, hence null transform. It's
a really common transform that comes up all the time. This null
transform can be done by policy (ignore all profiles!) or it can be
done programmatically by recognizing the need for a null transform
prior to doing the actual transform work.
--
Chris Murphy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
plus tone curve which can be defined as a gamma function or even
parametrically), space class, and abstract class are typically pretty
tiny, they could be created on the fly and fed into lcms2 as virtual
profiles, and let it handle all the transforms with its
On Mon, Mar 4, 2019 at 12:13 AM Graeme Gill wrote:
>
> Chris Murphy wrote:
>
> > A common offender were games. They'd try to access the video card LUT
> > directly for effects, but then not reset it back to what it was,
> > rather reset it to a hardwired assump
On Fri, Mar 1, 2019 at 3:10 AM Pekka Paalanen wrote:
>
> On Thu, 28 Feb 2019 18:28:33 -0700
> Chris Murphy wrote:
>
> > I'm curious how legacy applications including games used to manipulate
> > actual hardware LUT in a video card, if the application asked the
>
wheel and doing it internally.
In the near term do you really expect you need blending beyond
Rec.2020/Rec.2100? Rec.2020/Rec.2100 is not so big that transforms to
Rec.709 will require special gamut mapping consideration. But I'm open
to other ideas.
Blender, DaVinci, Lightworks, GIMP
On Thu, Feb 28, 2019 at 2:35 AM Pekka Paalanen wrote:
>
> On Wed, 27 Feb 2019 13:47:07 -0700
> Chris Murphy wrote:
>
> > On Wed, Feb 27, 2019 at 5:27 AM Pekka Paalanen wrote:
> > >
> > > there is a single, unambiguous answer on Wayland: the compositor owns
&g
er windows would
> remain looking good regardless.
Understood.
--
Chris Murphy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
e way they found it. Or alternatively if they're
going to mess with that pipeline, to have a kind of "reset" API for
the thing that ought to be mostly responsible for such a thing, e.g.
colord.
--
Chris Murphy
___
wayland-devel mail
On Fri, Feb 1, 2019 at 3:43 AM Pekka Paalanen wrote:
>
> On Thu, 31 Jan 2019 12:03:25 -0700
> Chris Murphy wrote:
>
> > I'm pretty sure most every desktop environment and distribution have
> > settled on colord as the general purpose service.
> > https://
e're going to have different rendering experiences.
And that is the long version on why 'color image encoding' as a full
encapsulating term of what's really important, is the ball to keep our
eye on, not just color spaces.
Chris Murphy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
and definition (summary). And it's also sane to
include all of the listed color image encodings, in this proposal.
http://www.color.org/chardata/rgb/rgb_registry.xalter
--
Chris Murphy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
x27;s a variant, which is 'Display P3' from Apple,
which starts out being defined with DCI-P3 D65 but uses a tone
response curve defined by the sRGB curve.
> +
Probably the summary should be 'ITU-R BT.2020 for UHDTV' same for
ome recommended by ICC, like SampleICC, Argyll etc, is there
> something which suits our case better?
You'd want to evaluate the interfaces of Argyll CMS and lcms2; it's
possible you'd use Argyll CMS for profile creation, and lcms2 as the
tr
ceholder bug to point to the Fedora one or
if the Fedora one is sufficient.
Also are XWayland crashers properly assigned to mutter on GNOME? Or XOrg?
Thanks,
--
Chris Murphy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lis
On Tue, Apr 4, 2017 at 6:25 PM, Peter Hutterer wrote:
> On Tue, Apr 04, 2017 at 05:01:53PM -0600, Chris Murphy wrote:
>> On Tue, Apr 4, 2017 at 4:36 PM, Peter Hutterer
>> wrote:
>> > On Tue, Apr 04, 2017 at 12:33:32PM -0600, Chris Murphy wrote:
>> >> Be
On Tue, Apr 4, 2017 at 4:36 PM, Peter Hutterer wrote:
> On Tue, Apr 04, 2017 at 12:33:32PM -0600, Chris Murphy wrote:
>> Before filing a bug...
>>
>> I'm having tap to click annoyances. When typing, the cursor insert
>> point changes somewhere else, and suddenly
nHPSpectreNotebook:pvrType1ProductConfigId:rvnHP:rn81A0:rvr48.54:cvnHP:ct10:cvrChassisVersion:
Thanks,
--
Chris Murphy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
it takes two or more
profiles to define a transform, and it's that transform that
(indirectly) moderates the display's behavior; or even the
application's behavior for that matter.
--
Chris Murphy
___
wayland-devel mailing list
wayland-dev
as "much easier to make reliable" sounds like the other pipeline may
not be reliable, but that is the pipeline 99.9% of the colors we care
about are going through, which are the colors from all of our
applications.
So instead of testing one pipeline, we're going to h
oth, noticeable posteriziation); or if the display is such crap
that you just have to suck it up and go with matrix+TRC to get smooth
results that lacks uniform accuracy.
--
Chris Murphy
___
wayland-devel mailing list
wayland-devel@lists.freedeskto
r behaved is pretty questionable, and a huge
assumption that we're in fact improving the display performance by
"calibrating" them by depending on video card LUTs in the first place. That
is exactly why the high end display don't use it at all. And for
here will be partial data loss (color fidelity)
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 channe
On Wed, Dec 21, 2016 at 5:49 PM, Carsten Haitzler wrote:
> On Wed, 21 Dec 2016 12:24:33 -0700 Chris Murphy
> said:
>
>> So...
>>
>> Do applications (wayland clients) choose what compositor to use? Each
>> application could be using a different compositor?
t everything needs this many bits pushed around, but
if it's an architecture that could suitably replace what color managed
apps already do internally now, then it's needed at least as an option
that they can opt into.
--
Chris Murphy
___
way
jects are explicitly tagged and the
compositor is doing display compensation with the help of e.g. lcms)?
Or am I missing something about compositors?
Chris Murphy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedeskto
blets you will have 10 different experiences).
I don't assume that on Linux any of these must be mimicked. But there
are distinct advantages with mimicking: we'll have a good idea where
the bodies are buried, rather than having something completely
different from any other platform.
-
ibration program
came with a helper program that would launch at startup time and apply
the calibration curve to the video card LUT.
--
Chris Murphy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
On Tue, Dec 20, 2016 at 11:33 AM, Daniel Stone wrote:
> Hi Chris,
>
> On 20 December 2016 at 18:11, Chris Murphy wrote:
>> On Tue, Dec 20, 2016 at 10:02 AM, Daniel Stone wrote:
>>> On 17 December 2016 at 10:16, Graeme Gill wrote:
>>>> As I've explaine
le s that doesn't demand
that the user draw up a list of "don't ever run these programs" while
doing color critical work, then great. Otherwise, there's going to
need to be a way to access the crude calibration lever in the video
card. Even though crude, this use case
40 matches
Mail list logo
