Re: Default colors vs. gamma

[Jeff Teunissen]

Quentin Mathé 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.
> 
> > 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. ?
> 
> > 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?

Neither Mac OS (including with ColorSync) nor KDE/GNOME used any CMS at all
for displaying on the screen.

Mac OS used a built-in gamma correction of 1.6, resulting in a total display
gamma of about 1.57. Later, with ColorSync, profiles were used to correct
printed output to match what was displayed on the screen. At no point was it
linear, but it did deliver WYSIWYG.

KDE/GNOME use no correction. Their total system gamma on usual hardware is
about 2.2, except on SGI workstations where it's about 1.294118 (hardware
correction of 1.7 by default on SGI). Because most people do not do gamma
correction at all, the colors are chosen to look good on uncorrected systems
(and basically nowhere else). If you adjust your gamma correction much
closer to linear, GTK+ and KDE apps will look VERY ugly.

Windows defines a standard color space, sRGB, which is exactly 2.20 gamma,
and Windows gamma-correction tools calibrate to the (very non-linear) sRGB
color space.

The monkeywrench in the works is that NeXTstep internally was absolutely
linear (total system gamma of 1.0), and colors had to be transformed for
every device, including the screen. This is a good thing for compositing, 
and reduces errors in color transforms, but is...not really all that fast.

[snip]

-- 
| Jeff Teunissen  -=-  Pres., Dusk To Dawn Computing  -=-  deek @ d2dc.net
| GPG: 1024D/9840105A   7102 808A 7733 C2F3 097B  161B 9222 DAB8 9840 105A
| Core developer, The QuakeForge Project        http://www.quakeforge.net/
| Specializing in Debian GNU/Linux              http://www.d2dc.net/~deek/