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 Salscheid
h suits our case better?
Yes, there are open source libraries to handle .icc files. You already
mentioned ArgyllCMS. There is also LittleCMS which is easy to use and enough
for a lot of usecases.
Best regards,
Ole
> Regards,
>
> Ankit
>
> On 1/10/2019 9:31 PM, Niels Ole Salschei
rrect values ("correct" in terms
> > of the color sensitive end users intentions for how they need their
> > systems
> > and applications to work.) Now if the compositor was CM aware, it could
> > choose whether to implement CM display calibration curves by usi
|
>
> +--v-v-+
>
>| Blender |
>
> ++-+
>
> | Tone mapped linear Rec2020
>
> +v-
one by the compositor?
This RFC also does not yet address the comments by Daniel since I am still
waiting for a response.
Niels Ole Salscheider (1):
Add the color-management protocol
Makefile.am| 1 +
unstable/color-management/README | 4 +
Signed-off-by: Niels Ole Salscheider
---
Makefile.am| 1 +
unstable/color-management/README | 4 +
.../color-management-unstable-v1.xml | 224 +
3 files changed, 229 insertions(+)
create mode 100644
> On 19 November 2016 at 16:29, Niels Ole Salscheider
>
> wrote:
> > +
> > +
> > + This interface allows attaching a color space to a wl_surface. The
> > + compositor uses this information to display the colors correctly.
> > +
On Wednesday, 21 December 2016, 12:05:12 CET, Daniel Stone wrote:
> Hi Chris,
>
> On 20 December 2016 at 20:49, Chris Murphy wrote:
> > On Tue, Dec 20, 2016 at 11:33 AM, Daniel Stone
wrote:
> >> On 20 December 2016 at 18:11, Chris Murphy
wrote:
> >>> We can't have multiple white points on the
On Wednesday, 21 December 2016, 11:39:50 CET, Graeme Gill wrote:
> Pekka Paalanen wrote:
> > When one integrates a CMS in a compositor, you no longer need to
> > expose configuration (hardware configuration, like CLUT programming)
> > via any protocol. The compositor talks directly with the CMS and
On Tuesday, 20 December 2016, 13:38:55 CET, Graeme Gill wrote:
> Niels Ole Salscheider wrote:
> > Yes, exactly. But these are things that do not use the "normal" wayland
> > protocols but are initiated by the compositor.
>
> I'm not sure what you mean by th
On Monday, 19 December 2016, 11:08:31 CET, Carsten Haitzler wrote:
> On Sat, 19 Nov 2016 17:29:20 +0100 Niels Ole Salscheider
>
> said:
> > Signed-off-by: Niels Ole Salscheider
> > ---
> >
> > Makefile.am| 1 +
>
On Monday, 19 December 2016, 13:08:13 CET, Graeme Gill wrote:
> Niels Ole Salscheider wrote:
> > I feel like the discussion drifts off a bit. You (Graeme) obviously know
> > much more about color management than I do. But as Pekka already pointed
> > out there are a few const
I feel like the discussion drifts off a bit. You (Graeme) obviously know much
more about color management than I do. But as Pekka already pointed out there
are a few constraints that originate in the design decisions of wayland and
are quite different to these of X11. We can't change these const
On Friday, 9 December 2016, 11:20:14 CET, Bill Spitzak wrote:
> On Fri, Dec 9, 2016 at 5:29 AM, Niels Ole Salscheider
>
> wrote:
> > Applications that care a bit more about color correction (but do not have
> > professional needs) could convert all their colors to the blendi
On Saturday, 10 December 2016, 11:48:32 CET, Carsten Haitzler wrote:
> On Fri, 09 Dec 2016 14:38:37 +0100 Niels Ole Salscheider
>
> said:
> > Am Donnerstag, 8. Dezember 2016, 15:51:12 CET schrieb Graeme Gill:
> > > Niels Ole Salscheider wrote:
> > > > Ther
Am Donnerstag, 8. Dezember 2016, 15:51:12 CET schrieb Graeme Gill:
> Niels Ole Salscheider wrote:
> > Therefore I think that the situation has changed and I'd like to propose
> > this protocol for inclusion in wayland-protocols again.
> > What do you think?
>
>
Am Donnerstag, 8. Dezember 2016, 13:33:20 CET schrieb Graeme Gill:
> Niels Ole Salscheider wrote:
>
> Hi,
>
> > The first version of my proposal had such a flag. I removed it and
> > replaced it by the described version based on feedback from Zoxc
> > (zox...@gmail
Am Freitag, 9. Dezember 2016, 12:02:07 CET schrieb Carsten Haitzler:
> On Thu, 8 Dec 2016 17:32:37 +1100 Graeme Gill said:
> > Carsten Haitzler (The Rasterman) wrote:
> > > i'm curious... is the intent to make it requird that all compositors
> > > support color management (and thus have to support
Am Donnerstag, 1. Dezember 2016, 15:17:53 CET schrieb Graeme Gill:
> Niels Ole Salscheider wrote:
>
> Hi,
>
> > Then they use the "set_colorspace" request
> > to set the color space of their surface to the same color space in order
> > to
> > ind
the blending color space is
> sRGB or the output space.
>
>
> On Sat, Nov 19, 2016 at 8:29 AM, Niels Ole Salscheider
>
> wrote:
> > Signed-off-by: Niels Ole Salscheider
> > ---
> >
> > Makefile.am| 1 +
> &g
Signed-off-by: Niels Ole Salscheider
---
Makefile.am| 1 +
unstable/color-management/README | 4 +
.../color-management-unstable-v1.xml | 136 +
3 files changed, 141 insertions(+)
create mode 100644
common so that color management becomes more important.
Therefore I think that the situation has changed and I'd like to propose this
protocol for inclusion in wayland-protocols again.
What do you think?
Ole
Niels Ole Salscheider (1):
Add the color-management protocol
Makefi
ton.ini.
Without my patches, only the hardware LUT is programmed with the gamma ramp
from the corresponding profile. My patches reuse the existing modules to get
the profile data for each output but then to do full color correction.
> On Mon, 27 Oct 2014 18:54:06 +0100
>
> Niels Ole Salsch
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
> >> converted has been removed. Instead, the color profile of the main output
> 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 colors.
I had a discussion regarding this with Zoxc on the
On Wednesday 15 October 2014, 21:56:53, Bryce Harrington wrote:
> On Mon, Oct 13, 2014 at 07:40:48PM +0200, Niels Ole Salscheider wrote:
> > This patch allows to attach an ICC profile to each output.
> >
> > Signed-off-by: Niels Ole Salscheider
> > ---
>
On Wednesday 15 October 2014, 21:54:37, Bryce Harrington wrote:
> On Mon, Oct 13, 2014 at 07:40:47PM +0200, Niels Ole Salscheider wrote:
> > This implements the functionality to attach a profile to a surface
> > in weston. An LUT is built from the profile that can be used to
>
space as blending space because it
uses 8 bit LUTs for now and I want to avoid additional banding. In
the long term we should use a linear blending space though to get
correct results.
Signed-off-by: Niels Ole Salscheider
---
Makefile.am | 3 +
configure.ac | 2 +-
src/compositor.c
This patch allows to attach an ICC profile to each output.
Signed-off-by: Niels Ole Salscheider
---
src/cms-colord.c | 4 +++-
src/cms-helper.c | 16 +++-
src/cms-helper.h | 3 ++-
src/cms-static.c | 1 +
src/compositor.c | 18 ++
src/compositor.h | 2 ++
6 files
The cms protocol allows to attach an ICC profile to a surface. It also tells
the client about the blending color space and the color spaces of all outputs.
Signed-off-by: Niels Ole Salscheider
---
Makefile.am | 15 +--
protocol/cms.xml | 132
This patch ignores the borders for now.
Signed-off-by: Niels Ole Salscheider
---
src/gl-renderer.c | 234 --
1 file changed, 226 insertions(+), 8 deletions(-)
diff --git a/src/gl-renderer.c b/src/gl-renderer.c
index 470f98a..4bc8b9b 100644
You can now use "C" to switch between the following modes:
- Assume sRGB input color space
- Assume that the input color space is the blending color space
- Attach a false-color ICC profile to the surface
Signed-off-by: Niels Ole Salscheider
---
clients/ima
It has been a few months since I sent the first version of the patches adding
per-surface color management
(http://lists.freedesktop.org/archives/wayland-devel/2014-March/013951.html).
I finally got around to addressing some of the issues of the first proposal.
Color profiles are now represented b
This patch ignores the YUV variants for now.
Signed-off-by: Niels Ole Salscheider
---
src/gl-renderer.c | 102 ++
1 file changed, 102 insertions(+)
diff --git a/src/gl-renderer.c b/src/gl-renderer.c
index f7f29b3..470f98a 100644
--- a/src/gl
Thank you for all your feedback! I am sorry that I did not respond earlier but
I was quite busy during the last three days.
> >>> how much data can an ICC profile be?
> >>>
> >>> I'm wondering whether it makes sense to send it inline in the protocol
> >>> stream like this. E.g. we transmit XKB k
The color correction protocol allows to attach an ICC profile to a
surface. It also tells the client about the blending color space and
the color spaces of all outputs.
Signed-off-by: Niels Ole Salscheider
---
Makefile.am | 15 ++--
protocol/colorcorrection.xml | 87
This patch allows to attach an ICC profile to each output. It then
builds an LUT that can be used to translate colors from the
blending space to the output space.
Signed-off-by: Niels Ole Salscheider
---
src/cms-colord.c | 4 +++-
src/cms-helper.c | 7 ++-
src/cms-helper.h | 3 ++-
src
I want to avoid additional banding. In
the long term we should use a linear blending space though to get
correct results.
Signed-off-by: Niels Ole Salscheider
---
Makefile.am | 3 +
src/compositor.c | 184 +++
src/compositor.h | 20
This patch ignores the YUV variants for now.
Signed-off-by: Niels Ole Salscheider
---
src/gl-renderer.c | 104 ++
1 file changed, 104 insertions(+)
diff --git a/src/gl-renderer.c b/src/gl-renderer.c
index 29d96f3..b2dfbac 100644
--- a/src/gl
rer.
- the events for blending and output color space changes are not tested.
Niels Ole Salscheider (6):
Add colorcorrection protocol
Attach input profiles and build corresponding LUTs
Attach output profiles and build corresponding LUTs
gl-renderer: Add necessary shaders for color corre
This patch ignores the borders for now.
Signed-off-by: Niels Ole Salscheider
---
src/gl-renderer.c | 309 ++
1 file changed, 286 insertions(+), 23 deletions(-)
diff --git a/src/gl-renderer.c b/src/gl-renderer.c
index b2dfbac..fe3aa4d 100644
You can now use the "C" key to toggle between the following modes:
- Assume sRGB input color space
- Assume that the input color space is the blending color space
- Do not use color correction
- Attach a false-color ICC profile to the surface
Signed-off-by: Niels Ole Salscheider
--
42 matches
Mail list logo
