GSoC CM collaboration

[Simon Thum]

Kai-Uwe Behrmann wrote:
> Am 06.03.08, 10:05 +0100 schrieb Simon Thum:
> 
>>> This case should be covered by the _ICC_PROFILE in X spec. Current draft:
>>> https://www.oyranos.org/wiki/index.php?title=ICC_Profiles_in_X_Specification_0.3
>>>
>> Just out of curiousity: (How) do you plan to kepp this in sync with the XDCCC
>> stuff? If one just wants linear compositing/scaling/whatever, evaluting an icc
>> profile is a bit overkill. The XDCCC tables would be much simpler to work with
>> (in that case).
> 
> Modern monitor characterisation has as well to handle pure CLUT profiles.
> 
> ICC profiles are not required to contain matrixes and only one dimensional 
> curves, which are called shaper/matix profiles in ICC terminology. 
> 
> Xcms, as I understood, is obsoleted in favour of a ICC conforming
> approach. The later is what is mostly refered here in this thread.
Sorry I didn't know it was obsoleted. My guess was you'd integrate as an
Xcms 'function set'. I never got it working anyway, but I like the
simple approach plus it enables basic conversions and linear compositing
- without much fuzz.

What I have in mind is a simple XDCCC-style intensity LUT + an 
iRGB<->XYZ matrix, in sync with whatever you're coming up with. That 
would allow apps with simple color needs to remain simple.

For example, I once did a toy project which displayed a star field on X 
(antialiased particle system by the more elaborate name). I
assumed gamma=2.2 to map intensities, but XDCCC tables would have been
a superior option had they been present at all.

So if that's the only use case let's forget about this, but I think it 
is worth consideration. It has numerous advantages for simple apps. Just 
to reassure: I'm *NOT* talking about real color management here. I'm 
talking about proper (i.e. linear with intensity) transforms or 
compositing. IMO, that's fairly enough for a class of applications - a 
class that currently resorts to sRGB or the infamous gamma=1 assumption.

As you point out, equivalent data structures are not neccessarily 
present in an ICC profile. The key question thus is if they could be 
derived. I guess they could in most cases, since I don't see much value 
in a monitor profile that cannot map to intensities or XYZ. I further 
assume a CMS should be able to do most of the work.

Given some amount of consent on the matter I might also implement it, 
though I guess someone more involved could perform this better & faster. 
As I view it, it boils down on wether one wants to give some level of 
support to applications where full-blown cm is infeasible. Think of 
screen savers, thumbnails or icons.

Kind regards,

Simon