[Openicc] XICC specification draft

Chris Murphy lists at colorremedies.com
Sun Jun 26 09:58:55 EST 2005


On Jun 25, 2005, at 5:22 PM, Casper Boemann wrote:

> firstly you have reversed the terminology:
> the xclient is where the program runs
> the xserver is where the monitor is attached

OK.

>
> Drawing a line only sends the coords across the network. The  
> rasterizing is
> done in the monitor (xserver) end.
>
> An image compositing program like krita would composit the images  
> in the
> program (on the xclient) and only send the composited image over  
> the network
> to the xserver. But it could also (for simpler cases) be done by  
> sending each
> imagelayer through the network and composit on the xserver.

OK so the xserver-xclient relationship can be based on either a pre- 
rasterized or post-rasterized context. So there is some kind of  
drawing language used in the case where the xserver is going to  
rasterize. Does this language support CMYK? Does it support per  
object color spaces defined by ICC profiles? That would be a minimum  
requirement for color management occurring entirely on the xserve side.

I think in any case it would make sense for applications to normalize  
to sRGB as a destination in a a remote display context. Then the  
entire xserver window on the remote machine could do simple full  
screen display compensation from sRGB to actual display profile (and  
if there is no display profile, as could be expected on some systems,  
at least there has been at least some display compensation already  
even if it isn't custom for the actual display being used).

A more sophisticated implementation would cause xserver to report to  
xclient and then the application itself what the current display  
profile is, and then the app can prematch to actual remote display  
profile rather than to sRGB as an intermediate space.

But in a remote display context, would a single application such as  
Scribus be expected to have more than one remote display operation  
occurring at once? I'd think yes, in the ad agency scenario  
previously described. Can the application be expected to, itself, be  
aware of multiple destination profiles, one for each remote display  
being used? Or is this better done by the xclient? And if it's better  
done by the xclient I wonder if it becoming more capable could be  
leveraged for non-remote display situations - i.e. rather than each  
application being responsible for implementing display compensation  
themselves, merely defer to the local window server.

Is it fair to say that a window server is like a combined (and more  
limited) xclient and xserver?


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)




More information about the openicc mailing list