"media-relative colorimetric + black point
compensation"
Info about BlackPointCompensation ISO 18619:2015:
http://www.color.org/whitepapers.xalter
regards
Kai-Uwe Behrmann
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
on if the ICC curve format is not directly
implemented in the shaders.
> Especially so if finding the degamma mapping needs a measurement tool.
Measuring is too laborious and already expressed as the profile.
regards
Kai-Uwe Behrmann
___
wayl
d you mind elaborating on that feature without some
example code or reference on how to write such and how it integrates in
a DE.
thanks,
Kai-Uwe Behrmann
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
ion decided look for arbitrary outputs from one surface
(currently not possible in X11)
* a surface can be mapped virtually anywhere without the client to know
Is the later wayland design goal still in force?
thanks,
Kai-Uwe Behrmann
> 2. How exactly should the client be informed of the &
fers with up to 15 channels).
Constrain device link to 3 in/out color channels as for the surface
color space too. No need for 15 channels here.
regards,
Kai-Uwe Behrmann
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
fort for device link versus without is similar.
thanks,
Kai-Uwe Behrmann
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
n is in action. Be that manipulation
visual impairment simulation, white point altering, saturation altering,
sepia effect, you name it
> [1]:
> https://github.com/swaywm/wlr-protocols/blob/master/unstable/wlr-gamma-control-unstable-v1.xml
> [2]: https://github.com/jonls/redshift/bl
Am 28.02.19 um 12:37 schrieb Pekka Paalanen:
> On Thu, 28 Feb 2019 09:12:57 +0100
> Kai-Uwe wrote:
>
>> Am 27.02.19 um 14:17 schrieb Pekka Paalanen:
>>> On Tue, 26 Feb 2019 18:56:06 +0100
>>> Kai-Uwe wrote:
>>>
>>>> Am 26.02.19 um 16:48 sch
Am 27.02.19 um 14:17 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:
>>>
>
>> + > + summary="the output for which the device link should be removed"
>> />
>> +
>> +
>> +
>> +
>> +This request allows to create a zwp_color_profile_v1 object from an
>> ICC
>&g
ere about these commercial interest clash. Are face down cards
common advertising practice in the US?
regards
Kai-Uwe Behrmann
--
www.oyranos.org - Color Management System project lead
www.behrmann.name - coding for various open source and commercial color
projects
PS: To make it clear, I am
Am 18.01.19 um 09:08 schrieb Graeme Gill:> Maybe rendering specifically
for one output is sufficient
> as long as the secondary displays (however that is determined!) look
> OK with a fallback conversion by the compositor.
Currently the first or main monitor is the primary rendering target. As
lon
Am 03.01.2018 um 14:23 schrieb Han, Guowei:
> We are running a multi process application. And GUI is act as a
> transparent top layer. All other process rendering by them self
> underneath. So its important for other process to place the window at
> right potion.
[Even that issue appears offtopic
Maybe you are after a full screen application then. With that you should
be able to decide about the positioning on the whole output.
Am 03.01.2018 um 02:37 schrieb Han, Guowei:
> Thanks Jasper. Do u know if there's a demo i can learn from? Currently
> i am creating a bigger surface bigger than sc
Am 14.01.2017 um 03:24 schrieb Carsten Haitzler (The Rasterman):
> On Fri, 13 Jan 2017 18:08:51 +0200 Pekka Paalanen said:
>> Oh, ok, that's why. We could as easily have the compositor show the
>> color swatch only on a part of the output and leave the rest of the
>> area for normal use.
>>
>> How
volved with the KDE community and working
as well for other DEs, I appreciate this openness. I wish to integrate
Oyranos CMS with Wayland/Weston.
colord is considerd very Gnome centric.
Kai-Uwe
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
of the while desktop not only some
esoteric clients, which support device links or other more powerful
expressions from their own GUIs.
Kai-Uwe
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
seamless your curves, need to be abstracted and
instead of curves are expressed as ICC profiles of type abstract. So a
CMS can integrate them easily, without to know the bells and whistles
redshift offers its users.
Kai-Uwe
___
wayland-devel mailing list
wa
Hello Daniel,
Am 20.12.2016 um 17:44 schrieb Daniel Stone:
> On 20 December 2016 at 14:46, Kai-Uwe wrote:
>> Am 20.12.2016 um 15:25 schrieb Daniel Stone:
>>> On 19 November 2016 at 16:29, Niels Ole Salscheider
>>>> +
>>>> +
>>>> +
;> +color-corrected. In this case it can attach the color space of its
>> main
>> +output to its surfaces.
>> +
>> +
>> +
>> +
>
> If a client doesn't want its surfaces to be colour-corrected ..
Am 20.12.2016 um 14:08 schrieb Pekka Paalanen:
> On Tue, 20 Dec 2016 13:05:10 +0100
> Kai-Uwe wrote:
> Oh nice. So indeed, CMS belongs in the compositor too (not only
> clients), because it is the window manager in the Wayland architecture.
The compositor has at least access to the
iggers a similar update demand.
Maybe the device link is kind of a extension for later implementation.
Kai-Uwe
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
need to
configure wayland.
Kai-Uwe
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
emory block. And loading the profile on the fly is really fast. You
need the CMM profile handle mostly in the weston_build_clut() function
and for the header ID computation in other places. So profile memory
blob and profile header ID would suffice?
Then following might work out for the later approach:
+struct weston_colorspace {
+
+ void * profile_data;
+ int profile_data_size;
+ unsigned char profile_id[16];
+
+ struct weston_clut clut;
+
+ int destroyable;
+ int refcount;
+ int input;
+
+ struct weston_compositor *compositor;
+};
This opens the path to exchange the CMM without much fuzz on start time
depending on the system requirements.
Thanks
Kai-Uwe
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Am 29.10.2014 um 20:15 schrieb Niels Ole Salscheider:
> On Tuesday 28 October 2014, 15:45:18, Kai-Uwe Behrmann wrote:
>> Am 27.10.2014 um 19:07 schrieb Niels Ole Salscheider:
>>>> The support to mask the area of a surface so that its color space is not
>>>> convert
Am 27.10.2014 um 19:07 schrieb Niels Ole Salscheider:
>> The support to mask the area of a surface so that its color space is not
>> converted has been removed. Instead, the color profile of the main output
>> of that surface can be attached if an application has a need to display
>> uncorrected co
ps://en.wikipedia.org/wiki/Wayland_%28display_server_protocol%29
kind regards
Kai-Uwe
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Am 31.03.2014 16:10, schrieb Pekka Paalanen:
> On Mon, 31 Mar 2014 11:29:03 +0200
> Kai-Uwe Behrmann wrote:
>
>> Am 31.03.2014 09:46, schrieb Pekka Paalanen:
>>> On Sun, 30 Mar 2014 13:36:32 +0200
>>> Niels Ole Salscheider wrote:
>>>
>>>>
sult any single client cannot assume at all, anyway.
> I still think that if a client needs the result of blending non-opaque
> pixels to be guaranteed, it should do it itself and not rely on the
> server.
>
>> Overall, I'm very happy to see someone pick up this work. Thanks.
> Indeed.
kind regards
Kai-Uwe
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
re- and post per channel processing can help to reduce the
artefacts.
kind regards
Kai-Uwe
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
e to do put the work in
one place and lessen the reuirements to compositor implementors.]
> Compared to that, I see your protocol adds the option for clients to
> provide a custom ICC profile to the server, and expects the server to
> process it properly.
... a no brainer for compositors.
>
precate the VCGT tag is not so easy, as we have lots of legacy
profiles around from windows / osx software and directly from vendors.
Ignoring the VCGT tag is no option, modifying the profile by baking the
VCGT tag into the ICC standard colorimetric descriptions migh
number of monitors / outputs with distinct profiles.
kind regards
Kai-Uwe
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
+#ifndef _WESTON_EDID_H_
+#define _WESTON_EDID_H_
+
+struct weston_edid_color_Yxy {
+ double Y;
+ double x;
+ double y;
+};
Why is the Y value set when it is all about primaries. No one will ever
use that other than for assuming 1.0 .
kind regards
Kai-Uwe
_
Am 02.05.13, 10:10 +0100 schrieb Richard Hughes:
In the future the CMS plugins will need to read the config file and setup a list
of hardcoded names to ICC profiles.
Why will come a need for a CMS to read hardcoded names from the config
file?
kind regards
Kai-Uwe
g CMS related attributes from EDID exists:
http://www.oyranos.org/libxcm/
kind regards
Kai-Uwe
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Am 20.04.2013 13:12, schrieb David Herrmann:
On Fri, Apr 19, 2013 at 9:19 PM, Kai-Uwe Behrmann wrote:
Am 19.04.2013 21:12, schrieb David Herrmann:
Why do you keep the blob around all the time? Just free it in
create_output_for_connector() after you parsed it. If we somehow need
it later, we
just free it right away.
The EDID blob is exposed under X11, which is a good thing in many cases.
Do you have a special reason to suggest otherwise on Wayland/Weston?
kind regards
Kai-Uwe
___
wayland-devel mailing list
wayland-devel@lists.freedeskto
d the general idea on how I think this should work. There are
You explain the term "CMF". The first idea, which pops to my mind, is
the "Colour Matching Function", which is fundamental to the CIE and ICC
specs. Are you aiming to do spectral imaging in westo
urface
with a tagged color profile, which means applications don't have to
care about CM unless they want to opt out a region and handle
everything themselves.
agreed, it is a good thing IMO.
kind regards
Kai-Uwe
[1] ICC colour transforms are most often prepared from a pair of ICC
profiles.
s the calibration state.
Sad, but true. Better are ICC profiles, which omit the vcgt tag
alltogether. That is much more straight forward IMO.
kind regards
Kai-Uwe
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedeskt
Am 07.03.2013 12:56, schrieb Pekka Paalanen:
On Thu, 07 Mar 2013 12:32:21 +0100
Kai-Uwe Behrmann wrote:
Statement:
The flattened output of overlapping transparent regions depend on the
intented order of painting the graph during compositing.
Question:
Does your following annotation has a
Am 07.03.2013 11:44, schrieb Pekka Paalanen:
On Thu, 07 Mar 2013 07:25:17 +0100
Kai-Uwe Behrmann wrote:
The biggest improvement over v1 is that we have some thought-out
commit behaviours. It is possible to resize a window so that all
surfaces stay in sync on screen, and it is also possible to
to have sub-surfaces
running on their own only optional?
kind regards
Kai-Uwe
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
re and more run on similar
computer hardware and their CPU/GPU fits already in a USB stick.
kind regards
Kai-Uwe
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
On Tue, Dec 18, 2012 at 10:45 AM, Kai-Uwe Behrmann wrote:
Am 17.12.2012 16:47, schrieb Richard Hughes:
On 5 December 2012 14:32, Pekka Paalanen wrote:
One of the most important use cases is a video player in a window. It
has XRGB or ARGB window decorations, usually the video content in YUV
Am 18.12.2012 06:40, schrieb Bill Spitzak:
On Dec 17, 2012, at 5:01 PM, John Kåre Alsaker wrote:
Then a client such as gimp could draw all it's display into a single buffer.
To get the different color correction of the center display, it would
declare a subsurface containing this and set it's c
ct in 2008.
However, we had seen quite some objections around subwindows at that
time. Did something substancial change on that matter?
To put the question in other words, do Qt and Gtk developers now or soon
play with the idea to use wayland as the internal compositing core?
kind regards
Ka
ed gamma, in order to work properly.
kind regards
Kai-Uwe Behrmann
--
developing for colour management
www.behrmann.name + www.oyranos.org
[1] http://en.wikipedia.org/wiki/SRGB
[2] http://en.wikipedia.org/wiki/Gamma_correction
___
wayland-devel mailing list
49 matches
Mail list logo
