Re: Default colors vs. gamma

[Alexander Malmberg]

(First, to clarify, all of this is for display on a screen. Other 
devices may need other adjustments.)

Fred Kiefer wrote:
> Alexander Malmberg wrote:
[snip]
> > So, do we want to do this? If so, what do we want the default value to 
> > be? 1.6 is nice for users who haven't set their gamma, but not so nice 
> > for users who have set it; I'm not really happy about forcing users 
> > who have set things up properly to set a default just to tell GNUstep 
> > that their system is set up properly, but if this makes GNUstep 
> > prettier to other users, it might be worthwhile.
>
> I am almost sure that this is the wrong solution to an important 
> problem.

You mean the general problem of displaying colors properly on the 
screen? This patch does nothing to solve that problem. However, that 
problem already has solutions; the problem is that they require the user 
to determine the right gamma and configure their system based on this 
(more below).

The problem that this patch addresses is that users don't seem to be 
doing that.

> What you did is just hacked into the palce where the system
> colour list is generated when it is not installed.

No, this affects all non-custom colors; note the two lines commented out 
around line 253.

> If this is the only
> thing that needs to be done, than why don't we provide a separate system 
> colour list for systems with wrong gamma settings?

Well, that's what the patch does: guess what the user's gamma "should" 
be and adjust the default system colors. The interesting issue here is 
what we think of this approach of automagically adjusting for 
unconfigured systems.

What's your opinion of that? What would your opinion be of a patch to 
set a system-(either all of GNUstep, or the entire system)-wide gamma 
based on an automagic guess?


<slightly-ot>
To expand on the solution above, afaict, all modern hardware and X 
versions support doing these color transforms in hardware (and I'd be 
surprised if other display systems couldn't do this). Thus, we can 
simply assume that colors are linear in the backend and let the hardware 
fix them for us. (This is what I assume in back-art, and I believe 
back-xlib does this, too.)

Getting X to do this is as simple as running xgamma (or editing 
XF86Config, or using DisplayCalibrator, etc.), but it takes user action. 
We could even do this in the X backends, _if_ we knew what values to 
use. (In fact, the X extensions in place even let us set arbitrary 
transfer functions for the colors, so we could go beyond plain "gamma" 
if we needed to.)

If we really wanted to and had the values, we could do the adjustments 
in the backends themselves (pretty straightforward for back-art, at the 
cost of some complexity and a fair bit of speed). However, this has the 
same problem (user has to tell us what values to use), and given how 
easy it is to get X to do this for us, I don't think it's worthwhile.

(It's worth noting that this can't be done entirely in -gui since the 
composite operations in the backend need to be done in linear color space.)
</slightly-ot>

- Alexander Malmberg