[Openicc] GSoC CM collaboration

"Gerhard Fürnkranz" nospam456 at gmx.de
Thu Mar 6 10:49:06 PST 2008


-------- Original-Nachricht --------
> Datum: Thu, 06 Mar 2008 22:53:43 +1100
> Von: Graeme Gill <graeme at argyllcms.com>
> An: OpenICC Liste <openicc at lists.freedesktop.org>
> Betreff: Re: [Openicc] GSoC CM collaboration

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

Actally I find Kai-Uwe's idea not really absurd. Even if they should (hopefully) give very similar results, why should we not have the opportunity to select between different pixel transformation (interpolation) engines which installed on the system (for instance an IMDI-based one, or ultra-fast hardware-aided ones, or a high-accuracy but slower floating point engine), independently of the full-featured CMM, which is selected for doing the high-level work (like pre-computing the device links for the pixel transformation engine, or handling different rendering intents, coping with the special issues when mixing V2 and V4 profiles, conversion between XYZ and CIELAB PCS, computing on-the-fly gamut mapping (e.g. BPC), etc.)? Of course this requires a well-defined interface to the pixel transformation engines.

Regards,
Gerhard

-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer


More information about the openicc mailing list