[Openicc] GSoC CM collaboration

Chris Murphy lists at colorremedies.com
Sun Mar 9 05:47:41 PDT 2008


On Mar 6, 2008, at 2:46 AM, Graeme Gill wrote:
>>> If it is felt desirable to have such legacy applications color  
>>> managed
>>> without changing them, then it is necessary to change the toolkit  
>>> they use
>>> (ie. X11 xlib, xcb etc., or the lower layers those toolkints  
>>> depend on).
>>
>> Keith has rejected this in the past. I dont know if hooks will be  
>> accepted
>> in Xorg.
>
> If it's well though out, coherent, and implemented, I'm sure it would
> be reconsidered :-).
>
>> Traditionally CMMs contain profile linking and pixel conversion in  
>> one
>> endity. This allows for CMM specific profile linking.
>
> Right, but this is mere convenience, not architectural necessity.


Anecdote time.

A developer working on a Mac OS X program has run into a problem with  
a program used for soft proofing. Everything is fast and fine  
displaying full resolution images, arbitrarily rotating them, whatever  
you want. The instant display compensation is used the whole process  
bogs down to an intolerable level.

So it seems that there isn't explicitly a display compensation API on  
OS X, or at least not a very smart one that downsamples hi-res data so  
that only the pixels necessary for display are being color managed at  
any one time! Ridiculous. You would think that by now this would be  
something the OS would simply intelligently do if you want system wide  
color management, and also have decent performance.

Point is, whatever is going to handle image data, should automatically  
downsample to screen resolution prior to applying display  
compensation. Or at least make it easy for the application to do so.

Chris


More information about the openicc mailing list