[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