Re: [compiz] color management spec

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [compiz] color management spec

Tomas Carnecky
Added [hidden email] to hear their opinion about this matter.
For reference, this is what I proposed:
http://lists.freedesktop.org/archives/xorg/2008-May/035772.html

Danny Baumann wrote:

> Hi,
>  
>>> I strongly dislike supporting subwindow ID/profile tuples.
>> The task of
>>> window and compositing managers is and always has been to
>> manage and
>>> draw _toplevel_ windows, not subwindows. I don't really think that
>>> adding a subwindow management infrastructure to compositing
>> managers
>>> just for saving some lines of code in the toolkit (and not
>> even all of
>>> them) is an overly good idea.
>> It's not just for 'saving some lines of code in the toolkit'.
>> Color management would require significantly more code in the
>> toolkit and would most likely be slower then if it is done in
>> the compositing manager.
>
> I was just talking about "communicate using subwindow id/profile tuples" vs.
> "communicate using toplevel window region/profile tuples". The former would
> save a bit of code in the toolkit, but would complicate compositing managers
> significantly; which is why I strongly prefer the latter.

The compositing manager would never actually draw subwindows, just
merely use them to identify regions.

When using properties on the top level window, the toolkit would have to
explicitly update those whenever the window is resized. But when using
subwindows, the toolkit (at least gtk) wouldn't have to do anything
special. In gtk, each widget that uses a subwindow resizes it when the
top level window is resized. The compositing manager would just
subscribe to ConfigureNotify events of the subwindows and be done.

tom
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: [compiz] color management spec

Owen Taylor
On Tue, 2008-06-10 at 16:43 +0200, Tomas Carnecky wrote:

> Added [hidden email] to hear their opinion about this matter.
> For reference, this is what I proposed:
> http://lists.freedesktop.org/archives/xorg/2008-May/035772.html
>
> Danny Baumann wrote:
> > Hi,
> >  
> >>> I strongly dislike supporting subwindow ID/profile tuples.
> >> The task of
> >>> window and compositing managers is and always has been to
> >> manage and
> >>> draw _toplevel_ windows, not subwindows. I don't really think that
> >>> adding a subwindow management infrastructure to compositing
> >> managers
> >>> just for saving some lines of code in the toolkit (and not
> >> even all of
> >>> them) is an overly good idea.
> >> It's not just for 'saving some lines of code in the toolkit'.
> >> Color management would require significantly more code in the
> >> toolkit and would most likely be slower then if it is done in
> >> the compositing manager.
> >
> > I was just talking about "communicate using subwindow id/profile tuples" vs.
> > "communicate using toplevel window region/profile tuples". The former would
> > save a bit of code in the toolkit, but would complicate compositing managers
> > significantly; which is why I strongly prefer the latter.
>
> The compositing manager would never actually draw subwindows, just
> merely use them to identify regions.
>
> When using properties on the top level window, the toolkit would have to
> explicitly update those whenever the window is resized. But when using
> subwindows, the toolkit (at least gtk) wouldn't have to do anything
> special. In gtk, each widget that uses a subwindow resizes it when the
> top level window is resized. The compositing manager would just
> subscribe to ConfigureNotify events of the subwindows and be done.

If I was working on a new toolkit from scratch it would most likely have
no subwindows, or a very, very limited use of subwindows.

In the case where you do have subwindows, future toolkits will commonly
act as compositing managers for their own subwindows, so a subwindow
does not necessarily represent an integer-pixel-bordered region of the
window.

I have trouble seeing the idea of separate profiles for subwindows
as being a good idea. There are also other problems like:

 - There's no easy way to get or be notified of changes to the
   clip region of a window in X. If a subwindow with a separate
   profile was partially obscured by another subwindow, the compositing
   manager would have trouble tracking that.

 - If there was inter-process embedding, the ID's of subwindows with
   separate profiles would have to be propagated up to the toplevel,
   which would be a pain. (You don't seem to have a
   WM_COLORMAP_WINDOWS equivalent, but one would be needed.)

The _NET_COLOR_MANAGER client message also introduces a whole lot of
complexity for toolkit authors.

I assume that the problem you are trying to solve here is:

 A) Photo app has a embedded image in a wider-than-SRGB-colorspace
    plus some random toolbars
 B) You don't to convert the image to SRGB and lose gamut that the
    monitor might actually be able to reproduce

While the suggestion of subwindow tracking is seductive, I don't think
it really works out. So, you need to go with one of the other
possibilities - either you export the monitor profile to applications
and allow applications to mark windows as being in the monitor profile,
or you put the whole window into the image colorspace. (Using the
monitor colorspace obviously works better if there are multiple images
with significantly different gamuts in the same toplevel.)

Either way, this end up with the question ... how do you get a
toolkit dealing with some non-SRGB colorspace? I don't have a full or
even partial answer to that, though there are obvious ways you could
start extending RENDER and cairo to work toward that goal. For the
photo app, most professionals probably wouldn't be that upset if the
menus and toolbars got the wrong colors as long as their photos got
the right colors...

- Owen


_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: [compiz] color management spec

Bugzilla from ku.b@gmx.de
Am 10.06.08, 17:56 -0400 schrieb Owen Taylor:

> On Tue, 2008-06-10 at 16:43 +0200, Tomas Carnecky wrote:
> > Added [hidden email] to hear their opinion about this matter.
> > For reference, this is what I proposed:
> > http://lists.freedesktop.org/archives/xorg/2008-May/035772.html
> >
> > Danny Baumann wrote:
> > > Hi,
> > >  
> > >>> I strongly dislike supporting subwindow ID/profile tuples.
> > >> The task of
> > >>> window and compositing managers is and always has been to
> > >> manage and
> > >>> draw _toplevel_ windows, not subwindows. I don't really think that
> > >>> adding a subwindow management infrastructure to compositing
> > >> managers
> > >>> just for saving some lines of code in the toolkit (and not
> > >> even all of
> > >>> them) is an overly good idea.
> > >> It's not just for 'saving some lines of code in the toolkit'.
> > >> Color management would require significantly more code in the
> > >> toolkit and would most likely be slower then if it is done in
> > >> the compositing manager.
> > >
> > > I was just talking about "communicate using subwindow id/profile tuples" vs.
> > > "communicate using toplevel window region/profile tuples". The former would
> > > save a bit of code in the toolkit, but would complicate compositing managers
> > > significantly; which is why I strongly prefer the latter.
> >
> > The compositing manager would never actually draw subwindows, just
> > merely use them to identify regions.
> >
> > When using properties on the top level window, the toolkit would have to
> > explicitly update those whenever the window is resized. But when using
> > subwindows, the toolkit (at least gtk) wouldn't have to do anything
> > special. In gtk, each widget that uses a subwindow resizes it when the
> > top level window is resized. The compositing manager would just
> > subscribe to ConfigureNotify events of the subwindows and be done.
>
> If I was working on a new toolkit from scratch it would most likely have
> no subwindows, or a very, very limited use of subwindows.
>
> In the case where you do have subwindows, future toolkits will commonly
> act as compositing managers for their own subwindows, so a subwindow
> does not necessarily represent an integer-pixel-bordered region of the
> window.
>
> I have trouble seeing the idea of separate profiles for subwindows
> as being a good idea. There are also other problems like:
>
>  - There's no easy way to get or be notified of changes to the
>    clip region of a window in X. If a subwindow with a separate
>    profile was partially obscured by another subwindow, the compositing
>    manager would have trouble tracking that.
>
>  - If there was inter-process embedding, the ID's of subwindows with
>    separate profiles would have to be propagated up to the toplevel,
>    which would be a pain. (You don't seem to have a
>    WM_COLORMAP_WINDOWS equivalent, but one would be needed.)

Are colour maps applicable in the range of this project? I'd guess that
OpenGL cards with the necessary features for compiz would run almost
always in a true visual mode?
 
> The _NET_COLOR_MANAGER client message also introduces a whole lot of
> complexity for toolkit authors.
>
> I assume that the problem you are trying to solve here is:
>
>  A) Photo app has a embedded image in a wider-than-SRGB-colorspace
>     plus some random toolbars
>  B) You don't to convert the image to SRGB and lose gamut that the
>     monitor might actually be able to reproduce

  C) Deploy a fast colour conversion path on the GPU rather than the CPU

  E) Manage the whole desktop at once, like it is displayed at once.

> While the suggestion of subwindow tracking is seductive, I don't think
> it really works out. So, you need to go with one of the other
> possibilities - either you export the monitor profile to applications
> and allow applications to mark windows as being in the monitor profile,
> or you put the whole window into the image colorspace. (Using the
> monitor colorspace obviously works better if there are multiple images
> with significantly different gamuts in the same toplevel.)

Tagging the window with the image colour space will render in rather a
mosaic of windows.
The other suggestion is covered by the _ICC_PROFILE_xxx atom but misses a
practical use case.

> Either way, this end up with the question ... how do you get a
> toolkit dealing with some non-SRGB colorspace? I don't have a full or

sRGB:
http://www.w3.org/Graphics/Color/sRGB.html
is a special, close to a idealised monitor, colour space. We have nearly
nowhere such devices. Toolkits typical display on real world devices
which differ from sRGB.
The sRGB would have to be supported by the drivers, which would introduce
a rather big burden on them. One partitial answere are video LUT's, which
are limited to neutrality management with several drawbacks.
With any computational intensive approach, a system to indicate damage or
request rerendering is a nice work load saver (XDamage?).
The project of Tomas moves the necessary driver implementation to a higher
layer and deploys hardware (GPU) in a more generic way. So it seems
overall reasonable.

What would interesst me, how is XDamage different from the
_NET_COLOR_MANAGER message? Is there possibly something overlapping?

> even partial answer to that, though there are obvious ways you could
> start extending RENDER and cairo to work toward that goal. For the

We discussed this at LGM to start there too.

> photo app, most professionals probably wouldn't be that upset if the
> menus and toolbars got the wrong colors as long as their photos got
> the right colors...

That case was a complaint from users and one of the reasons to start
projects like Tomas did.


kind regards
Kai-Uwe Behrmann
--
developing for colour management
www.behrmann.name + www.oyranos.org

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: [compiz] color management spec

Owen Taylor
[ Intentionally not trimming quoting much due to various bounces from lists ]

On Wed, 2008-06-11 at 09:05 +0200, Kai-Uwe Behrmann wrote:

> Am 10.06.08, 17:56 -0400 schrieb Owen Taylor:
> > On Tue, 2008-06-10 at 16:43 +0200, Tomas Carnecky wrote:
> > > Added [hidden email] to hear their opinion about this matter.
> > > For reference, this is what I proposed:
> > > http://lists.freedesktop.org/archives/xorg/2008-May/035772.html
> > >
> > > Danny Baumann wrote:
> > > > Hi,
> > > >  
> > > >>> I strongly dislike supporting subwindow ID/profile tuples.
> > > >> The task of
> > > >>> window and compositing managers is and always has been to
> > > >> manage and
> > > >>> draw _toplevel_ windows, not subwindows. I don't really think that
> > > >>> adding a subwindow management infrastructure to compositing
> > > >> managers
> > > >>> just for saving some lines of code in the toolkit (and not
> > > >> even all of
> > > >>> them) is an overly good idea.
> > > >> It's not just for 'saving some lines of code in the toolkit'.
> > > >> Color management would require significantly more code in the
> > > >> toolkit and would most likely be slower then if it is done in
> > > >> the compositing manager.
> > > >
> > > > I was just talking about "communicate using subwindow id/profile tuples" vs.
> > > > "communicate using toplevel window region/profile tuples". The former would
> > > > save a bit of code in the toolkit, but would complicate compositing managers
> > > > significantly; which is why I strongly prefer the latter.
> > >
> > > The compositing manager would never actually draw subwindows, just
> > > merely use them to identify regions.
> > >
> > > When using properties on the top level window, the toolkit would have to
> > > explicitly update those whenever the window is resized. But when using
> > > subwindows, the toolkit (at least gtk) wouldn't have to do anything
> > > special. In gtk, each widget that uses a subwindow resizes it when the
> > > top level window is resized. The compositing manager would just
> > > subscribe to ConfigureNotify events of the subwindows and be done.
> >
> > If I was working on a new toolkit from scratch it would most likely have
> > no subwindows, or a very, very limited use of subwindows.
> >
> > In the case where you do have subwindows, future toolkits will commonly
> > act as compositing managers for their own subwindows, so a subwindow
> > does not necessarily represent an integer-pixel-bordered region of the
> > window.
> >
> > I have trouble seeing the idea of separate profiles for subwindows
> > as being a good idea. There are also other problems like:
> >
> >  - There's no easy way to get or be notified of changes to the
> >    clip region of a window in X. If a subwindow with a separate
> >    profile was partially obscured by another subwindow, the compositing
> >    manager would have trouble tracking that.
> >
> >  - If there was inter-process embedding, the ID's of subwindows with
> >    separate profiles would have to be propagated up to the toplevel,
> >    which would be a pain. (You don't seem to have a
> >    WM_COLORMAP_WINDOWS equivalent, but one would be needed.)
>
> Are colour maps applicable in the range of this project? I'd guess that
> OpenGL cards with the necessary features for compiz would run almost
> always in a true visual mode?

WM_COLORMAP_WINDOWS is just an analogy; in the same way that
WM_COLORMAP_WINDOWS identifies subwindows that have different colormap,
you would need a property to identify subwindows with different color
profiles. *If* you wanted to put color profiles on subwindows (something
that I think is a bad idea.) The expense for the compositing manager to
monitor all subwindows of each toplevel for property changes would be
extreme.

> > The _NET_COLOR_MANAGER client message also introduces a whole lot of
> > complexity for toolkit authors.
> >
> > I assume that the problem you are trying to solve here is:
> >
> >  A) Photo app has a embedded image in a wider-than-SRGB-colorspace
> >     plus some random toolbars
> >  B) You don't to convert the image to SRGB and lose gamut that the
> >     monitor might actually be able to reproduce
>
>   C) Deploy a fast colour conversion path on the GPU rather than the CPU
>
>   E) Manage the whole desktop at once, like it is displayed at once.
>
> > While the suggestion of subwindow tracking is seductive, I don't think
> > it really works out. So, you need to go with one of the other
> > possibilities - either you export the monitor profile to applications
> > and allow applications to mark windows as being in the monitor profile,
> > or you put the whole window into the image colorspace. (Using the
> > monitor colorspace obviously works better if there are multiple images
> > with significantly different gamuts in the same toplevel.)
>
> Tagging the window with the image colour space will render in rather a
> mosaic of windows.

I don't understand this.

> The other suggestion is covered by the _ICC_PROFILE_xxx atom but misses a
> practical use case.

What use case?

> > Either way, this end up with the question ... how do you get a
> > toolkit dealing with some non-SRGB colorspace? I don't have a full or
>
> sRGB:
> http://www.w3.org/Graphics/Color/sRGB.html
> is a special, close to a idealised monitor, colour space. We have nearly
> nowhere such devices. Toolkits typical display on real world devices
> which differ from sRGB.
> The sRGB would have to be supported by the drivers, which would introduce
> a rather big burden on them. One partitial answere are video LUT's, which
> are limited to neutrality management with several drawbacks.

Trying to calibrate the video card via LUTs to be as close as possible
to sRGB is certainly not an ideal solution. But on other hand, the
default handling for a toplevel window should be that the colors in that
toplevel window are in sRGB space. And the compositing manager can
do the conversion. I think that architecture makes a lot of sense.

And if you want to use more of the monitor gamut than is available via
sRGB, then you can tag have windows that use different colorspaces
(possibly including the raw monitor colorspace.) Also makes sense to me.

> With any computational intensive approach, a system to indicate damage or
> request rerendering is a nice work load saver (XDamage?).
> The project of Tomas moves the necessary driver implementation to a higher
> layer and deploys hardware (GPU) in a more generic way. So it seems
> overall reasonable.

I think the overall project is reasonable. Being able to specify
per-window color profiles; have them properly converted as you move the
window between monitors, etc, would be a big advance. I'm just skeptical
of the idea that that the compositing manager should treat different
regions of a single toplevel differently.

There's certainly no reason we can't use the GPU for colorspace handling
within a window as well.

> What would interesst me, how is XDamage different from the
> _NET_COLOR_MANAGER message? Is there possibly something overlapping?

I don't quite see the connection. Compositing managers already track
damage via the XDamage extension. The _NET_COLOR_MANAGER message as I
understood it was about figuring out whether the compositing manager
supported particular colorspaces (I would have just used a root or
selection window property...)

> > even partial answer to that, though there are obvious ways you could
> > start extending RENDER and cairo to work toward that goal. For the
>
> We discussed this at LGM to start there too.  
>
> > photo app, most professionals probably wouldn't be that upset if the
> > menus and toolbars got the wrong colors as long as their photos got
> > the right colors...
>
> That case was a complaint from users and one of the reasons to start
> projects like Tomas did.

Only having the toolbars in the particular toplevel window be messed up
would already be a big advance compared to the current system where you
have to configure things globally.

- Owen


_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: [compiz] color management spec

Owen Taylor
On Sat, 2008-06-14 at 12:51 -0700, Hal V. Engel wrote:

> On Wednesday 11 June 2008 08:33:04 am Owen Taylor wrote:
>
> > [ Intentionally not trimming quoting much due to various bounces
> from lists
>
> > ]
>
> >
>
> > On Wed, 2008-06-11 at 09:05 +0200, Kai-Uwe Behrmann wrote:
>
> snip
>
> > > Tagging the window with the image colour space will render in
> rather a
>
> > > mosaic of windows.
>
> >
>
> > I don't understand this.
>
> I think you are assuming that the image color space is some kind of
> gamma corrected RGB color space. What is the image color space was a
> CMYK color space or XYZ or Lab?

If the visual of a window is ARGB, it can't hold XYZ or Lab, or most
obviously CMYK data.

I don't see color management support at the CM level as being a
mechanism to simplify the writing of image handling code, it's a
mechanism to allow the user to see the widest range of accurate colors
possible on their monitor.

For any color space you might want to support on a toplevel you have to
ask "what is the advantage".

 sRGB: decent compromise between range and precision. Widely used
     standard.
 
 raw monitor color space: allows the application full control.
     difficulties in multi-monitor setups if the monitors aren't
     identical and calibrated identically.

The reason why you might want to support other color spaces is to get
greater gamut then is possible with sRGB without having to deal with the
difficulties of per-monitor specifics... if I have an image in Adobe RGB
with 8 bits per primary, it might be interesting to preserve that
colorspace and use that as the colorspace on my toplevel, but that's not
done to avoid having colorspace conversion code in the application: it's
done to avoid losing gamut when converting it to something else.

Honestly, the only reason this is at all interesting is the limitations
of RGB 8:8:8. The long term solution here is support for something
like scRGB (http://en.wikipedia.org/wiki/ScRGB_color_space.)

- Owen


_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: [compiz] color management spec

Tomas Carnecky
Owen Taylor wrote:
> If the visual of a window is ARGB, it can't hold XYZ or Lab, or most
> obviously CMYK data.

> difficulties of per-monitor specifics... if I have an image in Adobe RGB
> with 8 bits per primary, it might be interesting to preserve that
> colorspace and use that as the colorspace on my toplevel, but that's not
> done to avoid having colorspace conversion code in the application: it's
> done to avoid losing gamut when converting it to something else.

If you have an image in CMYK the best way to avoid losing gamut, just
like in your AdobeRGB example, is to let the CM convert it at the very
last stage. So it might be useful to be able to upload CMYK pixels into
the xserver and tag the data somehow. I don't see any conflict there as
long as the application and CM agree on the pixel format.

> Honestly, the only reason this is at all interesting is the limitations
> of RGB 8:8:8. The long term solution here is support for something
> like scRGB (http://en.wikipedia.org/wiki/ScRGB_color_space.)

First the server would have to support buffers with at least 6 byte per
pixel, which it does not currently. I would love to see support for
arbitrary pixel formats in the xserver. I would even go as far as having
the xserver create bare buffers and then tag them with the pixel format
/ icc profile. After all, if a (OpenGL-based) CM is running the xserver
doesn't need to know anything about the windows besides the dimensions.

tom

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: [compiz] color management spec

Owen Taylor
On Sun, 2008-06-15 at 01:38 +0200, Tomas Carnecky wrote:

> Owen Taylor wrote:
> > If the visual of a window is ARGB, it can't hold XYZ or Lab, or most
> > obviously CMYK data.
>
> > difficulties of per-monitor specifics... if I have an image in Adobe RGB
> > with 8 bits per primary, it might be interesting to preserve that
> > colorspace and use that as the colorspace on my toplevel, but that's not
> > done to avoid having colorspace conversion code in the application: it's
> > done to avoid losing gamut when converting it to something else.
>
> If you have an image in CMYK the best way to avoid losing gamut, just
> like in your AdobeRGB example, is to let the CM convert it at the very
> last stage. So it might be useful to be able to upload CMYK pixels into
> the xserver and tag the data somehow. I don't see any conflict there as
> long as the application and CM agree on the pixel format.

I think there is a significant difference between having the CM deal
with the exact interpretation of RGB in a RGB pixel format, and having
the CM take "random" data stuffed into a RGB pixel and convert it - does
the user still see something intelligible if the CM/app communication
goes wrong? If a CM isn't running? If the user takes a screenshot of the
window?

Also, of course, CMYK isn't a precisely defined color space like sRGB;
you'd have to accompany the window with a color profile.

> > Honestly, the only reason this is at all interesting is the limitations
> > of RGB 8:8:8. The long term solution here is support for something
> > like scRGB (http://en.wikipedia.org/wiki/ScRGB_color_space.)
>
> First the server would have to support buffers with at least 6 byte per
> pixel, which it does not currently. I would love to see support for
> arbitrary pixel formats in the xserver. I would even go as far as having
> the xserver create bare buffers and then tag them with the pixel format
> / icc profile. After all, if a (OpenGL-based) CM is running the xserver
> doesn't need to know anything about the windows besides the dimensions.

There's certainly significant work there at all layers. I believe that
there was discussion on the cairo mailing list of someone starting doing
work within pixman, which is certainly a good place to start.

As above, I'm not sure uninterpreted window buffers is a good idea... or
really necessary. Better to support a small set of things well than a
large set of things poorly.

- Owen


_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: [compiz] color management spec

Bugzilla from ku.b@gmx.de
Am 14.06.08, 20:13 -0400 schrieb Owen Taylor:

> On Sun, 2008-06-15 at 01:38 +0200, Tomas Carnecky wrote:
> > Owen Taylor wrote:
> > > If the visual of a window is ARGB, it can't hold XYZ or Lab, or most
> > > obviously CMYK data.
> >
> > > difficulties of per-monitor specifics... if I have an image in Adobe RGB
> > > with 8 bits per primary, it might be interesting to preserve that
> > > colorspace and use that as the colorspace on my toplevel, but that's not
> > > done to avoid having colorspace conversion code in the application: it's
> > > done to avoid losing gamut when converting it to something else.
> >
> > If you have an image in CMYK the best way to avoid losing gamut, just
> > like in your AdobeRGB example, is to let the CM convert it at the very
> > last stage. So it might be useful to be able to upload CMYK pixels into
> > the xserver and tag the data somehow. I don't see any conflict there as
> > long as the application and CM agree on the pixel format.
>
> I think there is a significant difference between having the CM deal
> with the exact interpretation of RGB in a RGB pixel format, and having
> the CM take "random" data stuffed into a RGB pixel and convert it - does
> the user still see something intelligible if the CM/app communication
> goes wrong? If a CM isn't running? If the user takes a screenshot of the
> window?
>
> Also, of course, CMYK isn't a precisely defined color space like sRGB;
> you'd have to accompany the window with a color profile.
>
> > > Honestly, the only reason this is at all interesting is the limitations
> > > of RGB 8:8:8. The long term solution here is support for something
> > > like scRGB (http://en.wikipedia.org/wiki/ScRGB_color_space.)
> >
> > First the server would have to support buffers with at least 6 byte per
> > pixel, which it does not currently. I would love to see support for
> > arbitrary pixel formats in the xserver. I would even go as far as having
> > the xserver create bare buffers and then tag them with the pixel format
> > / icc profile. After all, if a (OpenGL-based) CM is running the xserver
> > doesn't need to know anything about the windows besides the dimensions.
>
> There's certainly significant work there at all layers. I believe that
> there was discussion on the cairo mailing list of someone starting doing
> work within pixman, which is certainly a good place to start.
>
> As above, I'm not sure uninterpreted window buffers is a good idea... or
> really necessary. Better to support a small set of things well than a
> large set of things poorly.

The idea is to have as few as possible colour conversions to gain speed,
be economic with memory resources and preserve precission. An other goal
to bring fancy pixel buffers close to the DVI outpu connector is to send
high bit depth channels over to the monitor device.

With dual link DVI connections we have since quite some years devices on
the marked. Recently they became, in the speach of colour management
experts, affordable. So there are reasons enough to drive this approach.

About scRGB, Windows has a very simple approach in mind with its kind of
"single colour space solutions", which might be powerful for its purpose.
The open source colour management community, read Scribus, Krita,
Ghostscript, Oyranos ... did not adapt to such a thing in mind or in
practise. So citing scRGB will fall relatively short in this community.
We orient much toward ICC and possibly OpenEXR colour management. What is
good for the internet, and we support this hartedly, might not be good for
the desktop, printing, movies and other arts.

Please support the search for variable channel, variable bit depth and
variable coulour space transport definitions.

One of the bricks we need is access from the upper end, e.g. applications,
to the compositing buffers. The buffers of the later are already in 16-bit
size. A clever colour conversion module (CMM) could convert their content
already to support HDR. Whether the way to go is, to bypass toolkits and
use OpenGL for 16-bit(++) buffers, or toolkits support these kind of
things has to be researched as well.


kind regards
Kai-Uwe Behrmann
--
developing for colour management
www.behrmann.name + www.oyranos.org

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: [compiz] color management spec

Owen Taylor
On Sun, 2008-06-15 at 11:52 +0200, Kai-Uwe Behrmann wrote:

> Am 14.06.08, 20:13 -0400 schrieb Owen Taylor:
> > On Sun, 2008-06-15 at 01:38 +0200, Tomas Carnecky wrote:
> > > Owen Taylor wrote:
> > > > If the visual of a window is ARGB, it can't hold XYZ or Lab, or most
> > > > obviously CMYK data.
> > >
> > > > difficulties of per-monitor specifics... if I have an image in Adobe RGB
> > > > with 8 bits per primary, it might be interesting to preserve that
> > > > colorspace and use that as the colorspace on my toplevel, but that's not
> > > > done to avoid having colorspace conversion code in the application: it's
> > > > done to avoid losing gamut when converting it to something else.
> > >
> > > If you have an image in CMYK the best way to avoid losing gamut, just
> > > like in your AdobeRGB example, is to let the CM convert it at the very
> > > last stage. So it might be useful to be able to upload CMYK pixels into
> > > the xserver and tag the data somehow. I don't see any conflict there as
> > > long as the application and CM agree on the pixel format.
> >
> > I think there is a significant difference between having the CM deal
> > with the exact interpretation of RGB in a RGB pixel format, and having
> > the CM take "random" data stuffed into a RGB pixel and convert it - does
> > the user still see something intelligible if the CM/app communication
> > goes wrong? If a CM isn't running? If the user takes a screenshot of the
> > window?
> >
> > Also, of course, CMYK isn't a precisely defined color space like sRGB;
> > you'd have to accompany the window with a color profile.
> >
> > > > Honestly, the only reason this is at all interesting is the limitations
> > > > of RGB 8:8:8. The long term solution here is support for something
> > > > like scRGB (http://en.wikipedia.org/wiki/ScRGB_color_space.)
> > >
> > > First the server would have to support buffers with at least 6 byte per
> > > pixel, which it does not currently. I would love to see support for
> > > arbitrary pixel formats in the xserver. I would even go as far as having
> > > the xserver create bare buffers and then tag them with the pixel format
> > > / icc profile. After all, if a (OpenGL-based) CM is running the xserver
> > > doesn't need to know anything about the windows besides the dimensions.
> >
> > There's certainly significant work there at all layers. I believe that
> > there was discussion on the cairo mailing list of someone starting doing
> > work within pixman, which is certainly a good place to start.
> >
> > As above, I'm not sure uninterpreted window buffers is a good idea... or
> > really necessary. Better to support a small set of things well than a
> > large set of things poorly.
>
> The idea is to have as few as possible colour conversions to gain speed,
> be economic with memory resources and preserve precission. An other goal
> to bring fancy pixel buffers close to the DVI outpu connector is to send
> high bit depth channels over to the monitor device.
>
> With dual link DVI connections we have since quite some years devices on
> the marked. Recently they became, in the speach of colour management
> experts, affordable. So there are reasons enough to drive this approach.
>
> About scRGB, Windows has a very simple approach in mind with its kind of
> "single colour space solutions", which might be powerful for its purpose.
> The open source colour management community, read Scribus, Krita,
> Ghostscript, Oyranos ... did not adapt to such a thing in mind or in
> practise. So citing scRGB will fall relatively short in this community.
> We orient much toward ICC and possibly OpenEXR colour management. What is
> good for the internet, and we support this hartedly, might not be good for
> the desktop, printing, movies and other arts.

[...]

You use "very simple" here as if it was an insult.

Inherently, if you want to alpha blend, you want to use intermediate
buffers, then you need a common colorspace. Reject a common colorspace,
then you've thrown out some of the most important tools in the graphics
toolkit.

Let me emphasize here that I'm not trying to sabotage the approach of
doing final color conversions in the CM. I think it's a fine project.

But what I'm arguing against here is putting in a lot of complexity - in
particular, tagging regions of a toplevel with different colorspaces -
to try and achieve future hypothetical advantages that are better
achieved by using high precision pixel formats.

- Owen

[
If, in certain specialized areas, the precision of 16-bit floats is
insufficient, then certainly 128-bit pixel formats with 32-bit floats
are feasible with current hardware, if memory and bandwidth intensive.
]


_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list