[Openicc] XICC specification draft

[Chris Murphy]

On Jun 27, 2005, at 11:23 PM, Craig Ringer wrote:

>  Nonetheless, even if both displays are on the
> same card it is not at all safe to assume identical colour.

I agree. And anyone with dual displays, I feel, is automatically in a  
more professional category rather than just average Joe consumer.

> I tend to agree. The discussion of using the composite manager for
> colour correction is very interesting.

[Nitpick warning!] The term color correction in this context doesn't  
really bug me, I know what you mean. But the term implies something  
isn't right with the color now and it needs to be corrected so it is  
right. Traditionally it's the generic term for enhancing images.

Display compensation originally appeared as a term in Adobe Photoshop  
5.x, but hasn't appeared in subsequent versions, or any other  
applications that I'm aware of and now is used for the kind of  
conversion we're talking about - that of color space conversion to a  
display profile prior to painting to the display itself.


> 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).

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.

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. Or it could be merely tagged as  
"intentionally device dependent."

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.

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.


> The former gives apps maximum control and makes things easier for
> developers of portable applications. That's evidently important - look
> at how Photoshop and friends largely ignore the OS's ColourSync CMM on
> Mac OS in favour of their own.

They do this primarily for cross platform reasons because the Apple  
CMM isn't on Windows but they want to ensure the same conversions  
occurs when using the same profile sequence, regardless of the  
platform. Also, this is merely default. You can change the CMM on  
both platforms. Adobe also does at least 20-bits/channel  
transformations (except for display compensation, not sure what the  
precision is there.)

> 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.

> 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 don't know the "right answer" if there is one. Does anybody here  
> know
> of real world examples of either of the two approaches outlined above
> that can be looked at? The only one I can think of is OS CMS
> implementations, eg ColourSync on Mac OS X, but that doesn't really  
> map
> well onto either of the above.

OS X isn't really doing full display compensation. For some kinds of  
files it assumes Generic RGB as source for untagged content, for most  
kinds of data it assumes it's display RGB and does not compensation  
at all. And in those cases, wide gamut displays don't display files  
reasonably at all.


Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
---------------------------------------------------------
Co-author "Real World Color Management, 2nd Ed"
Published by PeachPit Press (ISBN 0-321-26722-2)