I'd suggest that client should use subsurfaces if they want multiple
colorspaces in a window. They might have to do that anyway since they may
want a different pixel format.
On Thu, May 2, 2013 at 8:58 AM, Pekka Paalanen wrote:
> On Wed, 1 May 2013 17:03:30 -0400
> Kristian Høgsberg wrote:
>
>
On Wed, 1 May 2013 17:03:30 -0400
Kristian Høgsberg wrote:
> On Mon, Apr 22, 2013 at 01:30:28PM +0300, Pekka Paalanen wrote:
> > On Fri, 5 Apr 2013 14:23:50 -0500
> > Thomas Daede wrote:
> >
> > > I am not sure that doing the color conversion in the compositor
> > > is the correct place. Some o
On Mon, Apr 22, 2013 at 01:30:28PM +0300, Pekka Paalanen wrote:
> On Fri, 5 Apr 2013 14:23:50 -0500
> Thomas Daede wrote:
>
> > I am not sure that doing the color conversion in the compositor is the
> > correct place. Some of it has to be there to support vcgt, but for
> > more general conversion
On Fri, 5 Apr 2013 14:23:50 -0500
Thomas Daede wrote:
> I am not sure that doing the color conversion in the compositor is the
> correct place. Some of it has to be there to support vcgt, but for
> more general conversions, it gets complicated quickly.
>
> Color correction is most important for
Bill Spitzak wrote:
Maybe the client should be able to query the color space of the output
and can set the color space of it's buffer to the same one, this would
indicate that no color correction is needed. The compositor could still
color-correct it from one output's color space to another's if
Thomas Daede wrote:
I am not sure that doing the color conversion in the compositor is the
correct place. Some of it has to be there to support vcgt, but for
more general conversions, it gets complicated quickly.
Hi,
The expectation is that vcgt is per output (ie., it's loaded into
the display
Richard Hughes wrote:
For GIMP I was going to just allow the app to opt-out a sub-surface
from any kind of color management. i.e. do it all in the app.
Maybe the client should be able to query the color space of the output
and can set the color space of it's buffer to the same one, this would
On 5 April 2013 20:23, Thomas Daede wrote:
> Color correction is most important for artists doing work in something
> like the GIMP. Programs like this (as of GIMP 3.0, at least) generally
> work in higher bit depths
For GIMP I was going to just allow the app to opt-out a sub-surface
from any kin
I am not sure that doing the color conversion in the compositor is the
correct place. Some of it has to be there to support vcgt, but for
more general conversions, it gets complicated quickly.
Color correction is most important for artists doing work in something
like the GIMP. Programs like this
Richard Hughes wrote:
I've got to move onto other stuff next week, but I'd be really
interested if anyone has inputs on how the sub-surface gamut mapping
using shaders is going to work. The main complication seems to be that
it's per-output, rather than per-surface. I've played with 1bit masks
i
On 5 April 2013 09:53, Richard Hughes wrote:
> * GLib really wants to return all signals (colord_device_changed_cb)
> on the main thread, not on the thread that's running the loop.
As discussed on IRC, it seems I was wrong. I've attached both patches
(v6) for review. I've switched the coldplug on
Bill Spitzak wrote:
These gamma ramps are an attempt to simulate a color conversion from
some color space (sRGB?) to the color space of the output device.
No, they are not. Gamma ramp setting generally accomplishes one or
more of:
1) Setting the brightness to a calibrated level.
2) Setting th
On 4 April 2013 17:11, John Kåre Alsaker wrote:
> You should remove the destroy and user_data fields from weston_color_profile.
Fixed.
> weston_cms_create_profile and weston_cms_load_profile should just
> return a pointer to weston_color_profile.
Fixed.
> Plugins should just exit if compositor
On 4 April 2013 21:30, Matthias Clasen wrote:
> Just ftr (and without actually looking at the patch): glib signals
> don't need an event loop, they're entirely synchronous.
Right, but in this case the event is coming from the GDBus thread,
which I assume is g_idle_add'ing the signal it back to th
On Thu, Apr 4, 2013 at 2:58 AM, John Kåre Alsaker
wrote:
> I don't see a GLib event loop, so I'm curious to how the signals work.
Just ftr (and without actually looking at the patch): glib signals
don't need an event loop, they're entirely synchronous.
___
On 4 April 2013 19:52, Bill Spitzak wrote:
> These gamma ramps are an attempt to simulate a color conversion from some
> color space (sRGB?) to the color space of the output device.
Not really, the gamma ramps just affect the gamma response and the
display whitepoint. You can't do color gamut map
Richard Hughes wrote:
On 4 April 2013 19:08, Bill Spitzak wrote:
Are clients supposed to tell the compositor what color space their buffer
is, and the compositor then converts to the output's color space as part of
the compositing step?
At the moment I'm just implementing the calibration st
On 4 April 2013 19:08, Bill Spitzak wrote:
> Are clients supposed to tell the compositor what color space their buffer
> is, and the compositor then converts to the output's color space as part of
> the compositing step?
At the moment I'm just implementing the calibration state setting,
i.e. sett
On 4 April 2013 19:21, Kai-Uwe Behrmann wrote:
> Parsing of ICC profiles inside weston is not nice. That would be better
> abstracted out to lay inside the CMS plugins. Those CMS plugins can link
> against lcms or whatever CMM they prefere.
Well, we could certainly add some abstraction to get 3 a
Am 03.04.2013 21:47, schrieb Richard Hughes:
Patch 1 adds the framework code, patch 2 adds the ability to load CMS
modules, and patch 3 adds a CMS module written for colord. With those
People have a hard time to understand ICC and colour termininology. So
some annotations to that first.
A CMS
How is this intended to work in Wayland?
Are clients supposed to tell the compositor what color space their
buffer is, and the compositor then converts to the output's color space
as part of the compositing step? Problems with this:
* We need a reliable way for clients to tell compositor wha
You can move the output->base.updated_color_profile assignment down to
the other of the vfunc initializations.
You should remove the destroy and user_data fields from weston_color_profile.
weston_cms_create_profile and weston_cms_load_profile should just
return a pointer to weston_color_profile.
On 4 April 2013 07:58, John Kåre Alsaker wrote:
> The weston_color_manager struct could lose the state field
All fixed in the newest patchset, thanks for your detailed review.
> I don't see a GLib event loop, so I'm curious to how the signals work.
As discussed on IRC, I've used a thread fo
The weston_color_manager struct could lose the state field. The CMS
plugins allocates it and can add state as needed. You should move the
weston_cms_output_added call below weston_output_init (which
initializes the compositor pointer in the outputs) and drop the first
argument from output_added, ou
I've attached three patches for comments and review. I'm a GLib
programmer at heart, so please be kind if I've made huge obvious
architectural mistakes :)
Patch 1 adds the framework code, patch 2 adds the ability to load CMS
modules, and patch 3 adds a CMS module written for colord. With those
thr
25 matches
Mail list logo
