[Openicc] GSoC CM collaboration

Graeme Gill graeme at argyllcms.com
Thu Mar 6 03:53:43 PST 2008


Kai-Uwe Behrmann wrote:

> So you suggest a fixed CMM at the low end because of technical contraints 
> to access the GPU? 

No, mainly because there should be no discernible difference between
such things if implemented properly. That's one of the properties of
a color device space to device space transform, it's relatively unambiguous,
and any differences tend to be dictated by elements that are not discretionary,
such as CPU/GPU architecture, memory consumption or performance.

> On the other side rejecting the idea of profile linking code in the later 
> rendering end, would mean to further increase the requirements for past,
> current and future developed toolkits and applications by the need of 
> having at least all toolkits to handle colour management properties. 

There isn't a trade-off here. You wouldn't expect the compositing layer
to have all possible image file format readers implemented in it (TIFF, GIFF,
PDF, PNG etc. etc.) on the basis that an application would pass down
the filename and expect it to do the rest. That sort of thing is done
at a higher, graphics toolkit or application layer. You'd expect
the images to be loaded into memory before invoking the compositing layer
to do the pixel pushing. Similarly one doesn't expect the compositing layer
to have to link ICC profiles to form color transforms. Either they are
provided by the application/graphics toolkit up front, or a callback is used
to to get the application/graphics toolkit/CMM to generate them or return
them from cache on demand.

> Given the rather chaotic collection of APIs this would take many years to 
> overcome. Colour management is for most developers and users at best a 
> welcome thing, and even better at no cost. According will be the response 
> to take over the workload, which would be implied by a must requirement to 
> the toolkits for doing the profile linking. Linux systems are not so
> monolithic to follow easily.

You can't have it both ways. There's little point in color management
if the applications can't be aware of it. You can't make a monochrome
application color without it being aware of color. Sure you could
make all its out put red or green or yellow rather than grey, but does
that prove anything ? In other words, any ongoing or forward looking
graphics API's have to be expanded a little to accommodate color management.
To hope this can be made to go away is to postpone real managed color
indefinitely.

Graeme Gill.






More information about the openicc mailing list