Re: Default colors vs. gamma

[Banlu Kemiyatorn]

Hi,

On Tue, 9 Nov 2004 01:08:34 +0100, Quentin Mathé
<gnustep-quentin@club-internet.fr> wrote:
> Le 1 nov. 04, à 12:03, Fred Kiefer a écrit :
> 
> > Looks like my mail was still unclear in what I propose. Sorry for
> > that. I suggest that we don't implement the gamma correction when
> > defining the system colours (I hope this part was clear)
> 
> yes, it was clear.
> 
> > , but instead implement it as a conversion between calibrate colour
> > spaces and device colour spaces. you see, whenever we want to set a
> > calibrated colour in a device it should be converted to the device
> > colour space. I hope I did put in a comment on this, when I rewrote
> > the colour classes.
> 
> ok
> I'm not a color expert but here is what I understand : system colors
> should depend when possible on a CIE color space (XYZ, Lab etc.), then
> when the output is done to the screen or the printer, the CMS
> translates the color by using the screen and the printer profiles.

Can we just extend the RGB internal gamut  to be wide enough to cover
the visible color in CIE color space? Since most data in the framework
should be in displayed sRGB, shouldn't  transform RGB in CIE space to
sRGB can be done with much less expensive calculation?

> > I think it would be best to have a full CMS impelemented here for the
> > conversions. If you think this is hard remember that the original
> > cairo backend had colour management implemented and that one of the
> > drawing applications, I think it was Cenon, comes with colour
> > management build in.
> 
> What is this original cairo backend ? How is it different from the
> cairo backend included in GNUstep since this summer ?
> If Cenon has a nice CMS, may be it should included in GNUstep or we can
> improve it in order to create a CMS which fits our needs. ?

To display CMYK colors correctly, there is not much choice beside
using LCMS. (http://www.littlecms.com) I don't know if it is nice if we
can save caliberation profile in ICC for portability to another system.
(I think have heard keithp talking about ditching XDCCC to use ICC instead)

> > Even if we don't use a CMS library here this conversion is the place
> > where gamma correction should be put. Of course this will require a
> > few more extensions, devices should know about their colour space and
> > that information should be used here and so one, but by using this we
> > would imporve display on the monitor, while not losing (perhaps even
> > gaining) in PS and printer output.
> 
> Sure.
> Well you haven't replied to my questions on how Mac OS (before
> ColorSync), KDE and GNOME are displaying their colors on screen with a
> gamma which is equal to 1.6 or 1.8 (for Mac OS). But I deduce they are
> probably relying on a light CMS which supports only gamma conversion…
> you propose the same thing if I understand correctly, I think it's the
> right solution and it should be relatively easy to develop a such
> system before to have a full CMS system in the future.

I think it is better to use LCMS mixing with our own light weight CMS.
LCMS is quite expensive and is overkill to manage some simple transform.
In this case, just  for setting gamma. It is better to only use it to deal with
reading/writing ICC profiles (and to transform CMYK)

What I am doing with Maliwan is by wrapping lcms with a set of APIs
that allow a CMS replacement (so it is possible to replace lcms with
ColorSypc in future). I am using my own conversion method
where it is too expensive to use LCMS and use LCMS where it is neccessary.
(I am not suggesting to use Maliwan because it is quite something else
and it has its own color management engine for portability to Cocoa)

> Well but I must say I don't understand why you are saying "this will
> require few more extensions" like devices with a color space specified,
> in my opinion if for the initially we do only gamma conversion, we just
> need to use the gamma set by the user for this screen or the default
> fallback gamma probably 1..6 or 1.8 to transform the system colors
> (probably using a 1.0 gamma) for a relatively right output on the
> screen without consideration of the screen color space.

Well.. I don't know.. I think it is better to have a workaround even like
fork/exec'ing xgamma and start implementing a clean fully functional CMS
for using internally but my idea is totally biased :)