[Openicc] XICC specification draft

[Kai-Uwe Behrmann]

Am 28.06.05, 01:03 -0600 schrieb Chris Murphy:

> 
> On Jun 27, 2005, at 11:23 PM, Craig Ringer wrote:
 
> > My worry is that if the X server takes, eg, sRGB and transforms it to
> > the output device colour spaces, many apps that know about the colour
> > profiles of their inputs are going to have to convert once from the
> > input colour space to sRGB, then let the X server convert to the output
> > device's space. My puny knowledge of colour management leads me to worry
> > about gamut compression and loss of precision due to the double
> > conversion involved here. Is this likely to be a serious issue in the
> > real world?
> 
> If they are 16-bits/channel conversions no, at least not until we starting
> seeing compositing being done on HDR imagery which will absolutely become
> common place. Hard to say when but there is already one single capture camera
> that captures HDR (values brighter than 100% and less than 0%, fully
> reversible non-destructive edits).

Bracketing merging is becoming a common content. In virtual reality scenes 
HDR is about becoming even more usual. Hope we need not too long to wait 
for such features. OpenEXR is allready a common platform for such kind of 
things. The precission introduced by HDR imagery can cover the current 
needs easily.
 
> Gamut compression between matrix based profiles is up to the CMM, not the
> profiles. If the rendering intent is RelCol, gamut compression should not
> occur.

With a two stage approach 1. convert to wide gamut colour space in the 
application and 2. X compensate to screen the intent should be preserved. 
Otherwise the original intention, how imagery should be rendered, gets 
lost.

> But there are three options I'm proposing, should be serviced:
> 
> 1. Application is color managed, and can do display compensation already.
> Therefore it would submit drawing commands as explicitly device dependent to
> avoid further conversion; this could be done by tagging the data with the
> current display profile as source. Since the destination in display
> compensation is also the display profile, source=destination=null transform.

About the general option I would agree. Nethertheless tagging with the 
display profile instead of declaring the image is prematched is dangerous. 
Someone explained on this list how profile sizes can be striped down. A 
simple mechanism, which relies on MD5 checksums, would not understand the 
X screen and the image are tagged with the same profile and would repeat the 
conversion. This is approach is in my opinion a workaround only for 
existing systems. We dont need to implement such limitations.

> Or it could be merely tagged as "intentionally device dependent."

We should support this instead. This can be made a simple flag and is much 
more clear.

> 2. Application is not color managed and simply sends what it things are device
> dependent drawing commands using today's APIs. An updating compositer/xserver
> simply says "aha, ignorant application, I will assume these values are tagged
> sRGB for the source profile and perform display compensation using the
> destination profile."  Anyone who wants to prevent this from happening and
> doesn't care about display compensation can simply set the display profile to
> sRGB and again get a null transform.

The same here, basically agree -- null transform is no option. A flag 
would do a better job.

> 3. application is color managed, but wants to opt for normalizing to some
> larger gamut space (a system compositing space perhaps), so that it doesn't
> have to negotiate display compensation itself, especially for multiple
> displays, rather allowing the xserver to do this. But the conversion still
> needs to be to a space that has a sufficiently wide gamut in order to not
> cause clipping in the event the display being used is a wide gamut display.

IMO we will need a lot of time to have a full covering implementation of 
server side colour management. Anyway it's highly desireable.

> > It forces more complexity into the app,
> > but for the near future most apps will need built-in CMS support to
> > handle other platforms and older displays without native CM support
> > anyway. Centralised configuration is harder, but can be handled through
> > approaches like the XICC atom, XSettings, etc. On the upside, the X
> > server doesn't need to know about non-RGB colour spaces or some of the
> > weirder types of profile used for some inputs. Network transfer sizes
> > would also be kept down, both for profiles and input data.
> 
> I realize the prospect of doing this across the various incarnations of "unix"
> et al, that are out there lies somewhere between daunting and impossible. But
> the ones that can't provide this "for free" for all applications are going to
> be relegated to a very questionable usability as wide gamut displays start
> being used on them, and regular imagery (uncompensated) looks like
> oversaturated crap. It will inherently limit the platform, if it can't do
> display compensation.

A toolkit independant CMS eighter using its build in architecture or 
relying on the OS would be a way, which help cross platform integration 
of applications. Of course X needs to build in or adapt some CMM at one 
or the other place.
 
> > On the downside, potentially large input colour profiles have to be sent
> > across the wire, as must large input colour data (think 16 bit per
> > channel CMYK) and the X server / composite manager must know about a
> > variety of colour spaces solely to support transforms to device colour.
> 
> I would say any application that handles color models other than RGB would be
> required to use option #3 above - they normalize to a wide gamut RGB space and
> then submit drawing commands, with the color space tag used. Then only RGB
> data is being sent, and only a single matrix based profile is sent.

I tried 8 bit per channel RGB over a DSL connection. It is slow without 
compression anyway. Using X remotely needs bandwith which will expectedly 
grow in the future and can serve such needs then. I am not shure if an 
approach like NX is can preserve quality in all situations.
 
regards
Kai-Uwe Behrmann
                                + development for color management 
                                + imaging / panoramas
                                + email: ku.b at gmx.de
                                + http://www.behrmann.name