[Openicc] GSoC CM collaboration, littleCMS...

[Jan-Peter Homann]

Hello list, hello marti
I think the idea of precalculating devicelinks in a high-end CMM modul 
and doing the pixeltransformation in the GPU is a very good way.
I recently attended the ICC meeting in munich and the session about ICC 
based colormanagement for digital film and video soltion was going in 
the same direction. Currently more or less all (commercial) solutions 
for colormanagement in the motion picture area are using proprietary 
devicelinks (3D LUTS) for conversions from the "RGB film colorspace" to 
the monitor colorspace, processed in the GPU.


LittleCMS:
-----------
I would like very much to read comments from marti maria to following 
topics:

- Which concept do You would prefer for using the power of the GPU for 
littleCMS ?
- Do You think it would make sense to build an interface between 
littleCMS and Argyll for e.g. computing and caching optimized gamut 
mapping from source to destination in Argyll, instead of just linking 
static tables from source and destination profile ?
-

Regards
Jan-Peter

Gerhard Fürnkranz wrote:
> -------- 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
>
>   


-- 
***********   Neue Adresse / new adress   ************

homann colormanagement ------ fon/fax +49 30 611 075 18
Jan-Peter Homann ------------- mobile +49 171 54 70 358
Christinenstr. 21 ------ http://www.colormanagement.de
10119 Berlin -------- mailto:homann at colormanagement.de

***********   Neue Adresse / new adress   ************