Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: Default colors vs. gamma

5 views
Skip to first unread message

Dennis Leeuw

unread,
Oct 11, 2004, 3:22:04 AM10/11/04
to Alexander Malmberg, Discuss GNUstep
Alexander Malmberg wrote:
> Hi,
>
> A common complaint about GNUstep is that it isn't pretty enough, and a
> common response in #GNUstep is "fix your gamma". Since it seems that
> most users don't set their gamma properly, I wrote the following patch:
>
> http://w1.423.telia.com/~u42308495/alex/systemColorGamma.patch
>
> which simply does gamma adjustments on the default system colors before
> using them. The GSSystemColorGamma default controls the gamma, and
> defaults to 1.6, which makes things bright and cheerful for
> non-gamma-adjusted users. (Users who have adjusted their gamma will want
> to set this default to 1.0 or things will be _very_ bright. :)
>
> 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.
>
> Thoughts?

I agree that forcing a setting onto somebody that has setup his/her
system the way it should be is not the way to go. We could add a note to
the setup documentation that tells people to set the default to 1.6 if
they haven't adjusted their gamma settings.

just my 2 cents.

Dennis

>
> - Alexander Malmberg
>
>
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss...@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnustep


--
You must learn from the mistakes of others. You can't possibly live long
enough to make them all yourself.
--- Sam Levenson


Nicolas Roard

unread,
Oct 11, 2004, 8:20:33 AM10/11/04
to Dennis Leeuw, Alexander Malmberg, Discuss GNUstep

Le 11 oct. 04, à 08:22, Dennis Leeuw a écrit :

> Alexander Malmberg wrote:
>> Hi,
>> A common complaint about GNUstep is that it isn't pretty enough, and
>> a common response in #GNUstep is "fix your gamma". Since it seems
>> that most users don't set their gamma properly, I wrote the following
>> patch:
>> http://w1.423.telia.com/~u42308495/alex/systemColorGamma.patch
>> which simply does gamma adjustments on the default system colors
>> before using them. The GSSystemColorGamma default controls the gamma,
>> and defaults to 1.6, which makes things bright and cheerful for
>> non-gamma-adjusted users. (Users who have adjusted their gamma will
>> want to set this default to 1.0 or things will be _very_ bright. :)
>> 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.
>> Thoughts?
>
> I agree that forcing a setting onto somebody that has setup his/her
> system the way it should be is not the way to go. We could add a note
> to the setup documentation that tells people to set the default to 1.6
> if they haven't adjusted their gamma settings.

I disagree... most people (by far) don't set their gamma, and we should
thus provides by default the 1.6 setting.
People that had calibrated their screen are capable of modifying a
defaults (and ideally we should have some Preferences module for
setting it :-)

--
Nicolas Roard
"Any sufficiently advanced technology is indistinguishable from magic."
-Arthur C. Clarke

Fred Kiefer

unread,
Oct 11, 2004, 11:07:33 AM10/11/04
to Alexander Malmberg, Discuss GNUstep
Alexander Malmberg wrote:
> A common complaint about GNUstep is that it isn't pretty enough, and a
> common response in #GNUstep is "fix your gamma". Since it seems that
> most users don't set their gamma properly, I wrote the following patch:
>
> http://w1.423.telia.com/~u42308495/alex/systemColorGamma.patch
>
> which simply does gamma adjustments on the default system colors before
> using them. The GSSystemColorGamma default controls the gamma, and
> defaults to 1.6, which makes things bright and cheerful for
> non-gamma-adjusted users. (Users who have adjusted their gamma will want
> to set this default to 1.0 or things will be _very_ bright. :)
>
> 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. What you did is just hacked into the palce where the system
colour list is generated when it is not installed. 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?

What this patch does not fix is that any colour generated on such a
system will be a bit dark. This would require a fix in the backend and
thinking about it I would ratehr go for full CMS handling than just a
bit of gamma fiddling.

Fred


Alex Perez

unread,
Oct 11, 2004, 11:46:58 AM10/11/04
to Fred Kiefer, Alexander Malmberg, Discuss GNUstep
Fred Kiefer wrote:
> Alexander Malmberg wrote:
>
>> A common complaint about GNUstep is that it isn't pretty enough, and a
>> common response in #GNUstep is "fix your gamma". Since it seems that
>> most users don't set their gamma properly, I wrote the following patch:
>>
>> http://w1.423.telia.com/~u42308495/alex/systemColorGamma.patch
>>
>> which simply does gamma adjustments on the default system colors
>> before using them. The GSSystemColorGamma default controls the gamma,
>> and defaults to 1.6, which makes things bright and cheerful for
>> non-gamma-adjusted users. (Users who have adjusted their gamma will
>> want to set this default to 1.0 or things will be _very_ bright. :)
>>
>> 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. What you did is just hacked into the palce where the system
> colour list is generated when it is not installed. 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?

I must say I agree strongly with Fred here. This solution is amazingly
hackish, and is the wrong solution to this very real problem. You are
fighting an uphill battle with this gamma issue, and you *will /never/
win it*. It's imperative that you come to terms with this reality,
because if that doesn't happen, -GUI will always be a joke in many
people's eyes. (which would be a shame, because it has so much potential).

No other toolkits insist on forcing proper gamma values, so why should
GNUstep? You can insist on the hardline "it's the right thing to do"
(which from a technical perspective I agree on, but pragmatically I
disagree with you on) mantra, and you're welcome to stay in your ivory
tower, but down here on the ground, we almost all use different
applications which use different toolkits.

What really ought to happen is the default "dark" gray GNUstep
appearance (which looks /proper/ with the gamma set correctly) should be
lightened. A common complaint is that GNUstep is "too dark" and that's
in large part because people aren't viewing it at the correct gamma
setting. Frankly, when I look at images with a gamma of 1.6 set, I think
they are disgustingly horrific. Most people, (the vast majority, I'd
argue) instead of setting the gamma as they should, alter the brightness
and contrast settings of their monitors to achieve proper appearances.

> What this patch does not fix is that any colour generated on such a
> system will be a bit dark. This would require a fix in the backend and
> thinking about it I would ratehr go for full CMS handling than just a
> bit of gamma fiddling.

Agreed.


Gürkan Sengün

unread,
Oct 11, 2004, 12:32:16 PM10/11/04
to discuss...@gnu.org

>> I agree that forcing a setting onto somebody that has setup his/her
>> system the way it should be is not the way to go. We could add a note to
>> the setup documentation that tells people to set the default to 1.6 if
>> they haven't adjusted their gamma settings.
I agree. It's so easy to set it, why not just do it?
I think I will adjust it using xgamma / DisplayCalibrator for
the next GNUstep LIVE CD:
http://www.linuks.mine.nu/displaycalibrator/

patches for other backends are welcome!

Yours,
Gürkan


Pascal Bourguignon

unread,
Oct 11, 2004, 3:04:03 PM10/11/04
to
Alex Perez <ape...@student.santarosa.edu> writes:
> No other toolkits insist on forcing proper gamma values, so why should
> GNUstep? You can insist on the hardline "it's the right thing to do"
> (which from a technical perspective I agree on, but pragmatically I
> disagree with you on) mantra, and you're welcome to stay in your ivory
> tower, but down here on the ground, we almost all use different
> applications which use different toolkits.
>
> What really ought to happen is the default "dark" gray GNUstep
> appearance (which looks /proper/ with the gamma set correctly) should
> be lightened. A common complaint is that GNUstep is "too dark" and
> that's in large part because people aren't viewing it at the correct
> gamma setting. Frankly, when I look at images with a gamma of 1.6 set,
> I think they are disgustingly horrific. Most people, (the vast
> majority, I'd argue) instead of setting the gamma as they should,
> alter the brightness and contrast settings of their monitors to
> achieve proper appearances.

And for gamma-newbies around here like me, why should the gamma be 1.6
rather than 1.0? Why shouldn't we keep 'absolute' values for colors
(gamma=1.0) everywhere?

--
__Pascal Bourguignon__ http://www.informatimago.com/

Voting Democrat or Republican is like choosing a cabin in the Titanic.

Alex Perez

unread,
Oct 11, 2004, 4:02:20 PM10/11/04
to Pascal Bourguignon, discuss...@gnu.org
On 11 Oct 2004, Pascal Bourguignon wrote:

[snip]


> And for gamma-newbies around here like me, why should the gamma be 1.6
> rather than 1.0? Why shouldn't we keep 'absolute' values for colors
> (gamma=1.0) everywhere?

This is another point of contention I have with these 1.6 gamma zealots.
1.6 is an arbitrary gamma value, and is not correct for every (quite
possibly even most) monitors, but "they" won't tell you that. They just
blindly tell everyone to set their gamma to 1.6, and the ignorant and
innocent newbies do it, often without question. Several of these
high-gamma advocates don't even understand what they're recommending to
people (this is of course my opinion and my opinion only).

For a brief and easy-to-understand overview of Gamma, read
http://www.photoscientia.co.uk/Gamma.htm . For a more in-depth
explanation, see http://www.cgsd.com/papers/gamma.html

I urge everyone here to administer themselves a very large amount of
sanity before making brash and ill-informed arguments about what someone
else's gamma SHOULD or SHOULD NOT be.

Cheers,
Alex Perez
"Your gamma is either set to 1.6, or you are with the terrorists!"

Alexander Malmberg

unread,
Oct 11, 2004, 6:02:13 PM10/11/04
to Discuss GNUstep
(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


Dennis Leeuw

unread,
Oct 12, 2004, 4:44:12 AM10/12/04
to Alex Perez, Pascal Bourguignon, discuss...@gnu.org
Alex Perez wrote:
> On 11 Oct 2004, Pascal Bourguignon wrote:
>
> [snip]
>
>>And for gamma-newbies around here like me, why should the gamma be 1.6
>>rather than 1.0? Why shouldn't we keep 'absolute' values for colors
>>(gamma=1.0) everywhere?
>
>
> This is another point of contention I have with these 1.6 gamma zealots.
> 1.6 is an arbitrary gamma value, and is not correct for every (quite
> possibly even most) monitors, but "they" won't tell you that. They just
> blindly tell everyone to set their gamma to 1.6, and the ignorant and
> innocent newbies do it, often without question. Several of these
> high-gamma advocates don't even understand what they're recommending to
> people (this is of course my opinion and my opinion only).
>
> For a brief and easy-to-understand overview of Gamma, read
> http://www.photoscientia.co.uk/Gamma.htm .

The different patterns on that page, in conjunction with:
http://www.linuks.mine.nu/displaycalibrator/
might be able to solve the problem at the source. No patches needed just
a manual/helpviewer-doc to set you the right gamma. Might even be part
of Preferences.

Step 1: Set date and time
Step 2: Set language
Step 3: Set gamma

Just an idea...

Dennis

For a more in-depth
> explanation, see http://www.cgsd.com/papers/gamma.html
>
> I urge everyone here to administer themselves a very large amount of
> sanity before making brash and ill-informed arguments about what someone
> else's gamma SHOULD or SHOULD NOT be.
>
> Cheers,
> Alex Perez
> "Your gamma is either set to 1.6, or you are with the terrorists!"
>
>
>

Nicolas Roard

unread,
Oct 12, 2004, 7:29:13 AM10/12/04
to Dennis Leeuw, Pascal Bourguignon, discuss...@gnu.org

Le 12 oct. 04, à 09:44, Dennis Leeuw a écrit :

Well, the problem is not just a technical one... The thing is, Gtk/Qt
"expects" a gamma of 1.6-1.8. We expect a gamma of 1.0. Technically,
you can
say we're right (although, only if the display is calibrated).
But for people, we are wrong, as we behave differently than Gtk/Qt, and
as nearly nobody sets their gamma.
I think we should have by default the same kind of "wrongness", but we
should emphasis the fact that it's wrong and the user should calibrate
his
display... i.e, we should have by default a 1.6 correction for example,
so that GNUstep looks "good" out of the box, and have perhaps some kind
of "introduction" app that actually ask the user to set things properly
(or it could be in Preferences.app).
In any way, this "wrongness" is not _that_ problematic for us, as we
can/should easily change our gamma value.
So why not use the same "setting" as all GNOME/KDE.. for people that
want to properly set their display, it won't be difficult to do for
GNUstep.
But for all the other people, at least, it will look the same as their
KDE/GNOME apps.
In any ways, a 1.0 is as "wrong" as a 1.6-1.8 on a non-calibrated
display. So I think we should align here with GNOME/KDE.

Adam Fedor

unread,
Oct 12, 2004, 10:44:29 AM10/12/04
to Discuss GNUstep, Dennis Leeuw

On Oct 12, 2004, at 2:44 AM, Dennis Leeuw wrote:

> The different patterns on that page, in conjunction with:
> http://www.linuks.mine.nu/displaycalibrator/
> might be able to solve the problem at the source. No patches needed
> just a manual/helpviewer-doc to set you the right gamma. Might even be
> part of Preferences.
>
> Step 1: Set date and time
> Step 2: Set language
> Step 3: Set gamma
>
>

Yes! Another reason for having a Setup.app application that I asked
about early - after installation, just ask the user how he likes the
look of GNUstep.

Alexander Malmberg

unread,
Oct 12, 2004, 6:09:52 PM10/12/04
to Discuss GNUstep
Fred Kiefer wrote:
> Alexander Malmberg wrote:
>> (First, to clarify, all of this is for display on a screen. Other
>> devices may need other adjustments.)
>
> Thats an important point, which also makes it clear that we should not
> implemetn this behaviour in this bit of GUI, as this would effect every
> output device, even a PS file.

True, although I don't consider the exact shade of gray of the system
colors on the odd occasion that I print parts of our UI to be all that
important. :-)

[snip]
> I don't really like the idea of "automagic", even when implemented
> correctly it will only work for some people, others will be worse off.
> And somehow I always feel like I might end up in the wrong group...

Noted; I guess I should count this as a vote for "make the user
configure his system so we can do proper color adjustments".

> But now a question from my side: Why didn't you provide just a small
> application to generate different system colour lists?

Because that wouldn't have let me change the default look (ie. the one
that a new user with an unconfigured system would see).

> Or to but it even
> broader, why isn't anybody delivering different system colour lists for
> GNUstep? Is it because they are to hard to generate? Do we need a user
> itnerface for this?

There are apps to do this. Preferences has a pretty neat color module,
and it isn't very hard to make the colors lighter there (although it
does, as always, require that the user knows about all this and takes
action). I've also written apps for more generic editing of colors
(twice, iirc), but I'm not really sure what their state is now. Even a
simple shell script would be enough to make all the standard colors
brighter, though; it's just a matter of setting the right defaults.

As for why, I don't know. One possibility is that the complaints in this
area are coming from (or on behalf of) users who are new to GNUstep, or
who are just trying it out, and thus don't know that these apps exist
(or who expect, not altogether unreasonably, that GNUstep should look
good by default on their systems).

- Alexander Malmberg


Alexander Malmberg

unread,
Oct 12, 2004, 7:37:21 PM10/12/04
to Discuss GNUstep
Pascal Bourguignon wrote:
> And for gamma-newbies around here like me, why should the gamma be 1.6
> rather than 1.0? Why shouldn't we keep 'absolute' values for colors
> (gamma=1.0) everywhere?

Well, I'm no expert on this, but as I understand it:

We really want to use linear colors; ie. when we say that the system
gray is 0.667 gray, we want a color that is two-thirds of the light
intensity of full white. The problem is that if we give a signal to the
monitor that is two-thirds of the signal for full-white, various
non-linear phenomenon in the monitor will cause the resulting color to
be 0.667^gamma times the intensity of full white.

The 'gamma' in this function depends on all kinds of things (monitor,
monitor settings, ambient light, etc.), but it's usually somewhere
around 2.0. Thus, using 2.0, our 0.667 gray will turn out as 0.667^2.0
~= 0.44, less than half the intensity of full white. (Note that
brightness and contrast controls on a monitor can't fix this. They can
change how bright black is, and how bright white is, but they can't
change the ratio of intermediate colors to full white/black.)

To compensate for this, you do various gamma adjustments. A nice and
simple approach is to make the video card do it. If we know that the
effective gamma of our monitor is, say, 2.0, we can have the video card
apply an inverse transform when it reads the framebuffer and sends the
signal to the monitor (this is what 'xgamma' does). The video card will
then read 0.667 from the framebuffer, apply the inverse transform, and
really send 0.667^(1/2.0) ~= 0.82 to the monitor. In the monitor the
0.82 ends up as 0.82^2.0 ~= 0.67, which is just what we wanted.

Since most users haven't told X to do this, other desktop environments
make their colors brighter than they "should" be so that they'll look
right on these systems. This is what my patch does. Instead of making
our gray 0.667, it changes this to 0.667^(1/1.6) ~= 0.78, so that's what
we'll write to the framebuffers. If the video card isn't doing any
adjustments, it will send 0.78 to the monitor. which is pretty close to
what we want.

1.6 is just a reasonable guess; it probably isn't the right gamma, but
it'll be a lot closer than 1.0 (unless the user did the right
adjustments, in which case it'll be all wrong).

(According to people in #GNUstep, GNOME, KDE, and Windows have their
default interface colors set pre-adjusted for a 1.6 gamma, but they do
not otherwise adjust colors.)


I was asked in #GNUstep to provide screenshots of this, so:

http://w1.423.telia.com/~u42308495/alex/gamma_colors.png

The right instance of TextEdit is without my patch (or with my patch,
but with the default set to 1.0). The left instance is with my patch and
the default settings (ie. colors adjusted for a 1.6 gamma). Thus, the
right instance is using linear colors and should look "correct" on
displays that are gamma adjusted, while the left instance should look
"correct" on unadjusted displays. (When displaying the image, be wary of
programs that do their own adjustments.)


After looking at the mails and #GNUstep discussion, I get this list (if
I misplaced or forgot someone, please correct me):

Against:
Dennis Leeuw
Fred Kiefer
Gürkan Sengün
(_maybe_ Adam Fedor, not sure how to read that mail)

For:
Nicolas Roard
Alex Perez [1]
Jeff Teunissen
Riccardo Mottola


Which doesn't really get us anywhere, except that it's now late and I
need to sleep. :)


[1] After discussion in #GNUstep, it turned out that Alex's earlier
mails here were based on a misunderstanding of what the patch did.

- Alexander Malmberg


Fred Kiefer

unread,
Oct 12, 2004, 4:09:10 PM10/12/04
to Alexander Malmberg, Discuss GNUstep
Alexander Malmberg wrote:
> (First, to clarify, all of this is for display on a screen. Other
> devices may need other adjustments.)
>

Thats an important point, which also makes it clear that we should not
implemetn this behaviour in this bit of GUI, as this would effect every
output device, even a PS file.

> > 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?
>
>

As I wrote, I like the idea of correcting the appearance of GNUstep, but
this patch does it wrong. All colours that are generated by any other
means than the system colour list will still look wrong. Also, as you
wrote, linear colour interpolation wont b epossible any more and so on.
What we should do is integrate some CMS library with the backends, we
could start of with just the gamma correction in the x-backends.


I don't really like the idea of "automagic", even when implemented
correctly it will only work for some people, others will be worse off.
And somehow I always feel like I might end up in the wrong group...

But now a question from my side: Why didn't you provide just a small
application to generate different system colour lists? Or to but it even

broader, why isn't anybody delivering different system colour lists for
GNUstep? Is it because they are to hard to generate? Do we need a user
itnerface for this?

Fred


Adrian Robert

unread,
Oct 12, 2004, 9:10:31 PM10/12/04
to discuss...@gnu.org
On 2004-10-12 18:37:21 -0500 Alexander Malmberg
<alex...@malmberg.org> wrote:

>
> I was asked in #GNUstep to provide screenshots of this, so:
>
> http://w1.423.telia.com/~u42308495/alex/gamma_colors.png

...


>
> After looking at the mails and #GNUstep discussion, I get this list
> (if I
> misplaced or forgot someone, please correct me):


The gamma 1.0 shot looks just like I remember the NeXT (OK, it has
been a few years, but I'm pretty sure), yet I do not have any gamma
calibration turned on in my X server, and using test images it seems
like my setup has a gamma of about 2. Is it possible that the GNUstep
system color settings were set by someone eyeballing things on a
non-gamma-corrected system, instead of being numerically copied from a
NeXT?

In any case, my "vote" is that whatever is done, it should be
configurable from a GUI (the eventual Preferences app seems like a
great place), even if it is a technical solution like gamma setting.
(To make it intuitive, a slider could be used, and it could be called
"Brightness (gamma)".) GNUstep setup instructions should explicitly
recommend the user run Preferences to fiddle with the colors. Since
this is the way you do things in Windows (adjust colors from a Control
Panel item) and other environments this should not be something
difficult or discomfiting for new users.

Perhaps holding off on this until there is time to develop the GUI
might reduce the need for an unhappy compromise.


Adrian Robert

unread,
Oct 13, 2004, 9:59:21 AM10/13/04
to Discuss GNUstep

On Oct 13, 2004, at 8:57 AM, Alexander Malmberg wrote:
>>> as asked in #GNUstep to provide screenshots of this, so:
>>>
>>> http://w1.423.telia.com/~u42308495/alex/gamma_colors.png
> [snip]

>> The gamma 1.0 shot looks just like I remember the NeXT (OK, it has
>> been a few years, but I'm pretty sure), yet I do not have any gamma
>> calibration turned on in my X server, and using test images it seems
>> like my setup has a gamma of about 2.
>
> Just to be clear, you mean that the TextEdit instance on the right
> looks like NeXT, and the instance on the left is too bright?

Yes. But given the below, and some web investigations of my own, I
think probably my earlier impressions were the result of the aging NeXT
monitors.. ;-)


> > Is it possible that the GNUstep
>> system color settings were set by someone eyeballing things on a
>> non-gamma-corrected system, instead of being numerically copied from
>> a NeXT?
>

> Well, I asked Matt Rice, and he compared OPENSTEP (no special
> settings) and GNUstep (on an uncalibrated display) side-by-side and
> concluded that GNUstep was clearly darker than OPENSTEP. Adjusting
> gamma on the GNUstep system to around 2.2 made them similar. He also
> confirmed that our colors have the same absolute values as the
> OPENSTEP colors.

Dennis Leeuw

unread,
Oct 13, 2004, 10:34:22 AM10/13/04
to Nicolas Roard, discuss...@gnu.org
Nicolas Roard wrote:
>
> Le 12 oct. 04, à 09:44, Dennis Leeuw a écrit :
>
>> Alex Perez wrote:
>>
>>> On 11 Oct 2004, Pascal Bourguignon wrote:
>>> [snip]
>>>
>>>> And for gamma-newbies around here like me, why should the gamma be 1.6
>>>> rather than 1.0? Why shouldn't we keep 'absolute' values for colors
>>>> (gamma=1.0) everywhere?
>>>
>>> This is another point of contention I have with these 1.6 gamma
>>> zealots. 1.6 is an arbitrary gamma value, and is not correct for
>>> every (quite possibly even most) monitors, but "they" won't tell you
>>> that. They just blindly tell everyone to set their gamma to 1.6, and
>>> the ignorant and innocent newbies do it, often without question.
>>> Several of these high-gamma advocates don't even understand what
>>> they're recommending to people (this is of course my opinion and my
>>> opinion only).
>>> For a brief and easy-to-understand overview of Gamma, read
>>> http://www.photoscientia.co.uk/Gamma.htm .
>>
>>
>> The different patterns on that page, in conjunction with:
>> http://www.linuks.mine.nu/displaycalibrator/
>> might be able to solve the problem at the source. No patches needed
>> just a manual/helpviewer-doc to set you the right gamma. Might even be
>> part of Preferences.
>>
>> Step 1: Set date and time
>> Step 2: Set language
>> Step 3: Set gamma
>
>
> Well, the problem is not just a technical one... The thing is, Gtk/Qt
> "expects" a gamma of 1.6-1.8. We expect a gamma of 1.0. Technically, you
> can
> say we're right (although, only if the display is calibrated).
> But for people, we are wrong, as we behave differently than Gtk/Qt, and
> as nearly nobody sets their gamma.
> I think we should have by default the same kind of "wrongness", but we
> should emphasis the fact that it's wrong and the user should calibrate his
> display... i.e, we should have by default a 1.6 correction for example,
> so that GNUstep looks "good" out of the box, and have perhaps some kind
> of "introduction" app that actually ask the user to set things properly
> (or it could be in Preferences.app).
> In any way, this "wrongness" is not _that_ problematic for us, as we
> can/should easily change our gamma value.
> So why not use the same "setting" as all GNOME/KDE.. for people that
> want to properly set their display, it won't be difficult to do for
> GNUstep.
> But for all the other people, at least, it will look the same as their
> KDE/GNOME apps.
> In any ways, a 1.0 is as "wrong" as a 1.6-1.8 on a non-calibrated
> display. So I think we should align here with GNOME/KDE.

I think you convinced me...

I think I can live with the "wrongness" when there is a simple solution
to correct the "problem".
If e.g. Preferences has a simple way of correcting the "wrongness" to
the "right way", I can see the benefit for the majority of users.

I think one might expect a user when she/he calibrated the system to
know how to set things back again. And to know what a gamma control in
Preferences does...

Dennis

Alexander Malmberg

unread,
Oct 13, 2004, 8:57:45 AM10/13/04
to discuss...@gnu.org
Adrian Robert wrote:
> On 2004-10-12 18:37:21 -0500 Alexander Malmberg <alex...@malmberg.org>
> wrote:
>> I was asked in #GNUstep to provide screenshots of this, so:

>>
>> http://w1.423.telia.com/~u42308495/alex/gamma_colors.png
[snip]
>
> The gamma 1.0 shot looks just like I remember the NeXT (OK, it has been
> a few years, but I'm pretty sure), yet I do not have any gamma
> calibration turned on in my X server, and using test images it seems
> like my setup has a gamma of about 2.

Just to be clear, you mean that the TextEdit instance on the right looks
like NeXT, and the instance on the left is too bright?

> Is it possible that the GNUstep


> system color settings were set by someone eyeballing things on a
> non-gamma-corrected system, instead of being numerically copied from a
> NeXT?

Well, I asked Matt Rice, and he compared OPENSTEP (no special settings)
and GNUstep (on an uncalibrated display) side-by-side and concluded that
GNUstep was clearly darker than OPENSTEP. Adjusting gamma on the GNUstep
system to around 2.2 made them similar. He also confirmed that our
colors have the same absolute values as the OPENSTEP colors.

This is consistent with circumstantial evidence on the web.

> In any case, my "vote" is that whatever is done, it should be
> configurable from a GUI (the eventual Preferences app seems like a great
> place), even if it is a technical solution like gamma setting.

[snip]

OK, I can do that fairly easily (regardless of which approach we pick).

- Alexander Malmberg


Adam Fedor

unread,
Oct 13, 2004, 10:33:51 AM10/13/04
to Alexander Malmberg, discuss...@gnu.org

On Oct 13, 2004, at 6:57 AM, Alexander Malmberg wrote:
>
>> In any case, my "vote" is that whatever is done, it should be
>> configurable from a GUI (the eventual Preferences app seems like a
>> great place), even if it is a technical solution like gamma setting.
> [snip]
>
> OK, I can do that fairly easily (regardless of which approach we pick).
>
Yes, to be clearer - that's essentially what I would like to see, no
matter which way the default is.

Quentin Mathé

unread,
Oct 31, 2004, 11:28:50 AM10/31/04
to Alexander Malmberg, discuss...@gnu.org
Le 13 oct. 04, à 01:37, Alexander Malmberg a écrit :

> After looking at the mails and #GNUstep discussion, I get this list
> (if I misplaced or forgot someone, please correct me):
>

> Against:
> Dennis Leeuw
> Fred Kiefer
> Gürkan Sengün
> (_maybe_ Adam Fedor, not sure how to read that mail)
>
> For:
> Nicolas Roard
> Alex Perez [1]
> Jeff Teunissen
> Riccardo Mottola
>
> Which doesn't really get us anywhere, except that it's now late and I
> need to sleep. :)
>
> [1] After discussion in #GNUstep, it turned out that Alex's earlier
> mails here were based on a misunderstanding of what the patch did.

Well to bring back the issue, I would say I'm in the "For" list. Dennis
Leeuw has moved to "For" list too I can conclude by reading this last
mail on the subject.

In my opinion, it is better to have a somewhat correct default look
with a default gamma between 1.6 and 2.2, even if this gamma is wrong,
by taking in account you can have it truly right with a default
(wrapped by a Preferences panel ideally). Moreover iirc GNOME/KDE uses
a 1.6 gamma, Mac OS X a 1.8 gamma and Windows a 2.2 gamma, with such
values we can conclude it is reasonable (for color compatibility) to be
in this range not at the extreme opposite. Last point, I cannot imagine
having a desktop environment which asks a newbie to set its gamma, it
is a such complex notion for the everyday user.

Quentin.

--
Quentin Mathé
qma...@club-internet.fr


M. Uli Kusterer

unread,
Oct 31, 2004, 3:34:11 PM10/31/04
to
In article <mailman.6383.109924159...@gnu.org>,
Quentin Mathé <gnustep...@club-internet.fr> wrote:

> Last point, I cannot imagine
> having a desktop environment which asks a newbie to set its gamma, it
> is a such complex notion for the everyday user.

Even MacOS (which is often deemed the platform of choice for artists
and graphic designers) only has an assistant (aka "Wizard", reachable
via a Preference Pane) for setting up Gamma etc.

It's pretty nice, though. If you don't go into "expert" mode, they
mainly show you a few images and tell you how they're supposed to look
(e.g. a grey Apple inside a field of black horizontal lines, and you
have to set brightness and contrast until the Apple blends in with the
lines), and give you one or two sliders to perform your corrections.

That means: I encourage you to have a default gamma and leave changing
it to those people that need it.

Cheers,
-- Uli
http://www.zathras.de

Fred Kiefer

unread,
Oct 31, 2004, 3:56:26 PM10/31/04
to Quentin Mathé, Alexander Malmberg, discuss...@gnu.org
> not at the extreme opposite. Last point, I cannot imagine having a
> desktop environment which asks a newbie to set its gamma, it is a such
> complex notion for the everyday user.
>

Sorry, again a discussion that went a bit strang. The topic as far as I
remember was not, if GNUstep will need Gamma correction in some way
(which I strongly agree to, but rather as part of full colour
management), what was actually discussed was a specific proposal to
gamma correct the system colours when creating them from values and this
is what I opposed. As Alexander already explained we will be losing the
benefit of linearity in colour values, if we apply gamma correction in
the GUI. Also correctiong only some of the values may result in a worse
effect than correcting none.

To restate this even clearer: I am "For" gamma correction, but against
the proposed patch and anything similar to it.

Fred


Quentin Mathé

unread,
Nov 1, 2004, 1:21:20 AM11/1/04
to Fred Kiefer, discuss...@gnu.org
Le 31 oct. 04, à 21:56, Fred Kiefer a écrit :

> Quentin Mathé wrote:
>
>> Well to bring back the issue, I would say I'm in the "For" list.
>> Dennis Leeuw has moved to "For" list too I can conclude by reading
>> this last mail on the subject.
>> In my opinion, it is better to have a somewhat correct default look
>> with a default gamma between 1.6 and 2.2, even if this gamma is
>> wrong, by taking in account you can have it truly right with a
>> default (wrapped by a Preferences panel ideally). Moreover iirc
>> GNOME/KDE uses a 1.6 gamma, Mac OS X a 1.8 gamma and Windows a 2.2
>> gamma, with such values we can conclude it is reasonable (for color
>> compatibility) to be in this range not at the extreme opposite. Last
>> point, I cannot imagine having a desktop environment which asks a
>> newbie to set its gamma, it is a such complex notion for the everyday
>> user.
>
> Sorry, again a discussion that went a bit strang.

Sorry to be the bad guy here, but… I understood that Alexander was
saying it was not so dramatic to break the color linearity, but that's
not your opinion I conclude.

> The topic as far as I remember was not, if GNUstep will need Gamma
> correction in some way (which I strongly agree to, but rather as part
> of full colour management), what was actually discussed was a specific
> proposal to gamma correct the system colours when creating them from
> values and this is what I opposed. As Alexander already explained we
> will be losing the benefit of linearity in colour values, if we apply
> gamma correction in the GUI. Also correctiong only some of the values
> may result in a worse effect than correcting none.
>
> To restate this even clearer: I am "For" gamma correction, but against
> the proposed patch and anything similar to it.

ok.

But in the GNOME or KDE cases, is their default gamma support based on
a CMS, or is their default gamma just a hack which breaks linearity. …
Last point, long time before ColorSync (the Mac OS CMS) exists, Mac OS
was using a 1.8 gamma, do you think at this time the linearity was
broken also because of the non existent CMS ?

Fred Kiefer

unread,
Nov 1, 2004, 6:03:50 AM11/1/04
to Quentin Mathé, discuss...@gnu.org
Quentin Mathé wrote:
> Le 31 oct. 04, à 21:56, Fred Kiefer a écrit :
>
>> Quentin Mathé wrote:
>>
>> The topic as far as I remember was not, if GNUstep will need Gamma
>> correction in some way (which I strongly agree to, but rather as part
>> of full colour management), what was actually discussed was a specific
>> proposal to gamma correct the system colours when creating them from
>> values and this is what I opposed. As Alexander already explained we
>> will be losing the benefit of linearity in colour values, if we apply
>> gamma correction in the GUI. Also correctiong only some of the values
>> may result in a worse effect than correcting none.
>>
>> To restate this even clearer: I am "For" gamma correction, but against
>> the proposed patch and anything similar to it.
>
> But in the GNOME or KDE cases, is their default gamma support based on a
> CMS, or is their default gamma just a hack which breaks linearity. …
> Last point, long time before ColorSync (the Mac OS CMS) exists, Mac OS
> was using a 1.8 gamma, do you think at this time the linearity was
> broken also because of the non existent CMS ?
>

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), 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.
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.
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.

If this mail is still unclear, I'll give up and start to code it. Words
are so complicated, Objective-C is so easy...

Fred


Quentin Mathé

unread,
Nov 8, 2004, 7:08:34 PM11/8/04
to Fred Kiefer, GNUstep Discussion List
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…
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.
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.

Nb : I don't know if it would be useful for the printers to have the
possiblity to specify a gamma.

> If this mail is still unclear, I'll give up and start to code it.
> Words are so complicated, Objective-C is so easy...

hehe :-) Objective-C : the only C derived language which is easier than
C itself.

Thanks for your reply Fred, I understand the things better now.

Banlu Kemiyatorn

unread,
Nov 9, 2004, 2:13:18 AM11/9/04
to Quentin Mathé, Fred Kiefer, GNUstep Discussion List
Hi,

On Tue, 9 Nov 2004 01:08:34 +0100, Quentin Mathé
<gnustep...@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 :)


Jeff Teunissen

unread,
Nov 14, 2004, 9:54:42 AM11/14/04
to discuss...@gnu.org
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/


0 new messages