Automatically picking a random pair of colors to make good contrast

[Mikhail T.]

Hello!

I am using xterm for most of my command-line work, but am getting bored and
otherwise troubled by the monotonous colors.

I'd like my xterms invoked with a (semi-)randomly picked colors for back- and
foreground -- as long as the two choices provide decent enough contrast.

How would one pick such a pair? The only requirement is that the two are "far
enough" from each other to be easy to use...

If anyone explains the algorithm to me well enough, I should be able to offer
patches against xterm's sources -- the ultimate plan is to make the color-combo
dependent on the command executed inside:

xterm -CR -e ssh foo

would (always) use one pair, while

xterm -CR -e tail -f /var/log/bar

would always use another. (The fictious `-CR' option would trigger the new
behavior.) Thanks in advance for any suggestions. Yours,

-mi

[Skybuck Flying]

How about black and white ?

Also if it's just two colors you are after then black and white is probably
optimal.

It has the highest contrast. (0,0,0) versus (255,255,255).

If you want any other two pair of colors you'll have to set parameters to
allow less than optimal contrast.

Bye,
Skybuck.

[Mikhail T.]

Post by Skybuck Flying
How about black and white ?

"You can pick any color as long as it is black" (Henry Ford)

Post by Skybuck Flying
Also if it's just two colors you are after then black and white is probably
optimal.

As I say in the very subject, I'd like randomly-picked pairs. Though one can
make random selections from a set with one element, the results will not be all
that interesting...

Post by Skybuck Flying
It has the highest contrast. (0,0,0) versus (255,255,255).

Yes, absolutely, black and white are an acceptable choice (and the highest
contrast). But I'll settle for lesser contrast to get more choices -- and
"funkier" color combinations. For example, green on black seems nice. As well as
yellow on dark blue (or midnight blue).

Post by Skybuck Flying
If you want any other two pair of colors you'll have to set parameters to allow
less than optimal contrast.

Right. So, how does one measure contrast? Is it simply the distance between
points in 3D: (r1, g1, b1) and (r2, g2, b2), or is there more to it?

Thanks!

-mi

[Don Y]

Hi Mikhail,

Post by Mikhail T.
I am using xterm for most of my command-line work, but am getting bored and
otherwise troubled by the monotonous colors.
I'd like my xterms invoked with a (semi-)randomly picked colors for back- and
foreground -- as long as the two choices provide decent enough contrast.
How would one pick such a pair? The only requirement is that the two are "far
enough" from each other to be easy to use...
If anyone explains the algorithm to me well enough, I should be able to offer
patches against xterm's sources -- the ultimate plan is to make the color-combo
xterm -CR -e ssh foo
would (always) use one pair, while
xterm -CR -e tail -f /var/log/bar
would always use another. (The fictious `-CR' option would trigger the new
behavior.) Thanks in advance for any suggestions. Yours,

I think you will find that picking a random "color" will leave you
dissatisfied with the visual results.

First, not all people can perceive all colors "correctly". In
particular, about 1 in 15 men have some form of color-blindness.
(more common in men than women)

But, even assuming all users are capable of perceiving all colors
(i.e., you could implement options that allow certain color choices
to be avoided in your "randomizer"), how we perceive color varies.

E.g., your eye will "see" red and blue at two different apparent
"depths" (look at something with sharp red & blue borders). In
some cases, this can actually cause headaches as the eyes try
to focus on one color, then the other, then back to the first,
etc.

Also, swapping the foreground and background colors FOR A GIVEN
COLOR PAIR will yield very different perceptual results. Try,
e.g., yellow on blue vs. blue on yellow (or, white and black,
for that matter).

For a real treat, try red on blue and blue on red!

You may find a better solution to be creating a table of color
combinations and "randomly" picking among them.

You may also find that *fixing* the color choices is preferable
than leaving them variable. E.g., I routinely change the colors
of "text consoles" so I can visually associate a color with a
particular activity (in my mind):

"Hmmm... I was editing /etc/passwd on the *red* screen so I need
to ALT-F2 (2 being the color for red) to get back to that screen..."

vs.

"The output from the make(1) I am running is green. So, to check
up on its progress, I need to ALT-F5 (5 being the color for green)
to get to that screen..."

YMMV. HTH,
--don

[Mikhail T.]

Post by Don Y
You may also find that *fixing* the color choices is preferable
than leaving them variable. E.g., I routinely change the colors
of "text consoles" so I can visually associate a color with a

Yes, fixing the color choice was my plan. I am going to pick colors at random,
but use the command executed inside the xterm as the seed for the random number
generator. Thus, all xterms executing the same command (like ssh-ing to the same
remote host) would be using the same color-pair, which, I think, would be quite
useful.

But I still don't know, how to pick colors "far enough" from each other -- even
if the "far enough" may be different for different people (using different
monitors).

-mi

[Don Y]

Hi Mikhail,

Post by Mikhail T.

Post by Don Y
You may also find that *fixing* the color choices is preferable
than leaving them variable. E.g., I routinely change the colors
of "text consoles" so I can visually associate a color with a

Yes, fixing the color choice was my plan. I am going to pick colors at random,
but use the command executed inside the xterm as the seed for the random number
generator. Thus, all xterms executing the same command (like ssh-ing to the same
remote host) would be using the same color-pair, which, I think, would be quite
useful.
But I still don't know, how to pick colors "far enough" from each other -- even
if the "far enough" may be different for different people (using different
monitors).

Typically, you look for "things" (I am trying to avoid using the
word "colors") that have different "(color) values". <frown>
This is hard to describe without pictures... and, there are
several different "models" used to try to codify this sort of
thing (i.e., you can spend a LONG time trying to sort out the
minutiae!)

Artists typically refer to colors in terms of hue (what we non
artists would tend to call "color" -- red, green, blue, etc.),
saturation (how *intense* the color... deep red vs. pale red)
and value (how "light"/reflective the color).

It is possible to have two very different hues/saturations
*appear* to have no contrast differences between them.

E.g., there is a WinMobile game called Jawbreakers that is
a great example of this! There are many colored "balls"
(red, green, yellow, purple, ...) displayed on the screen.
Your job is to get them to clump together in like-colored
groups.

But, while VERY different colors, there is no value difference
between them! A green ball adjacent to a red ball doesn't
*effectively* stand out -- as a grey ball next to a black
(or white) one would!

It is this difference in value that makes things (e.g., paintings)
"interesting".

For example, when SWMBO makes a painting and is unhappy with it,
I often suggest she look at it through her camera's view-finder
with the "mode" set to "black and white". This removes all of
the "color" that tends to distract us and lets her see that
there is no real *contrast* across the image. Somethings need
to be "darker" and others "lighter" -- whatever that means for
those particular "colors".

[If you have such a camera, this is a great exercise. Or,
import the photo into a photoediting program and strip the
color out, there. You'll be surprised how often very different
"colors" have no real difference in contrast!]

Apparently, in WW-II (?), people with color-blindness were often
used to spot camouflaged installations -- they weren't distracted
by the cacophony of colors in the camouflage netting and, instead,
could see the "artificial-ness" of those man-made patterns
against the natural flora.

[Another great use for a digital camera is checking to see if
the batteries in your TV remote control are good! :> ]

[Mikhail T.]

Post by Don Y
But, while VERY different colors, there is no value difference
between them! A green ball adjacent to a red ball doesn't
*effectively* stand out -- as a grey ball next to a black
(or white) one would!

So, are you saying, it is impossible to reliably generate well contrasting
color-pairs algorithmically -- other than from a manually-constructed table of
some sort?

If, after all, it can be done, I'd like to try it... Any pointers?

-mi

[Johann Klammer]

Post by Mikhail T.

Post by Don Y
But, while VERY different colors, there is no value difference
between them! A green ball adjacent to a red ball doesn't
*effectively* stand out -- as a grey ball next to a black
(or white) one would!

So, are you saying, it is impossible to reliably generate well contrasting
color-pairs algorithmically -- other than from a manually-constructed table of
some sort?
If, after all, it can be done, I'd like to try it... Any pointers?
-mi

Look up the CIE chrominance curves on wikipedia. they may be usable for
estimating the perceived difference in color. also try greyscale
summing, in case you have colorblind person.

http://en.wikipedia.org/wiki/Color_model

[Don Y]

Hi Mikhail,

Post by Mikhail T.

Post by Don Y
But, while VERY different colors, there is no value difference
between them! A green ball adjacent to a red ball doesn't
*effectively* stand out -- as a grey ball next to a black
(or white) one would!

So, are you saying, it is impossible to reliably generate well contrasting
color-pairs algorithmically -- other than from a manually-constructed table of
some sort?

Very few things are "impossible". :> My point is this is something
that, I suspect, you will find yields disappointing results.
A particular color-pair choice may be "acceptable" on an LCD monitor
and dismal on a CRT -- or, vice versa. ColorA-on-ColorB may look
OK but ColorB-on-ColorA might not (shouldn't they perform *equally*
well??).

Color is tricky. E.g., fine *blue* detail is a lot harder to
perceive than fine *red* detail -- so, blue text on a red field
may be harder to read than red text on a blue field (neglecting
the fact that your eye will focus on the red and blue aspects
at different "depths").

As I mentioned before, I use color-on-black for my "text consoles",
here (where "color" is red, green, blue, etc.). *Surely* anything
on black has *some* contrast, right? One (black) emits *no*
light, the other, *some* light.

Yet, if you arrange "consoles" like this and "hotkey" between
them (i.e., think in terms of DOS screens -- all black with
colored lettering), you can see how dramatic the difference
in readability will be.

Try it. It's an easy experiment to set up. Then, ask yourself
if there are (in practice) certain "consoles" you try to avoid
using and others that you *favor*.

Then, ask yourself how you would deal with the fact that the
machine (your algorithm) may "randomly" have chosen one of the
color combinations that you've been avoiding -- do you support
a "try again" option for the color selection algorithm? Kill
the process and hope for a better selection next time? etc.

Best not to casually muck with user interfaces unless you
can be *sure* all choices are equivalent. How'd you feel
if the positions of the accelerator and brake pedals were
"randomly assigned" in vehicles?

Post by Mikhail T.
If, after all, it can be done, I'd like to try it... Any pointers?

I think you're going to find it an educational experience
after you see how much is involved in color perception and
visual machinery. As I said, *play* -- and then try to rationalize
why there are (significant) differences in choices that,
conceptually, seem like they should be equivalent (e.g., the
A-on-B vs. B-on-A issue).

There is a *lot* of literature out there. People really have
mapped out lots of detail regarding how vision works -- in
an almost mechanical sense!

Have fun! That's the point of learning!
--don

[Joe keane]

Post by Mikhail T.
So, are you saying, it is impossible to reliably generate well contrasting
color-pairs algorithmically -- other than from a manually-constructed table of
some sort?

Y = 0.3 * R + 0.6 * G + 0.1 * B

[Jeff Higgins]

Post by Mikhail T.
Hello!
I am using xterm for most of my command-line work, but am getting bored and
otherwise troubled by the monotonous colors.
I'd like my xterms invoked with a (semi-)randomly picked colors for back- and
foreground -- as long as the two choices provide decent enough contrast.
How would one pick such a pair? The only requirement is that the two are "far
enough" from each other to be easy to use...

<http://www.w3.org/TR/WCAG20/#contrast-ratiodef>

Post by Mikhail T.
If anyone explains the algorithm to me well enough, I should be able to offer
patches against xterm's sources -- the ultimate plan is to make the color-combo
xterm -CR -e ssh foo
would (always) use one pair, while
xterm -CR -e tail -f /var/log/bar
would always use another. (The fictious `-CR' option would trigger the new
behavior.) Thanks in advance for any suggestions. Yours,
-mi

[o***@gmail.com]

Hi

algorithm to calculate an "ideal" tet color can be

/**
* @method
* Returns the ideal Text Color. Useful for font color selection by a given background color.
*
* @return {draw2d.util.Color} The <i>ideal</i> inverse color.
**/
getIdealTextColor:function()
{
var nThreshold = 105;
var bgDelta = (this.red * 0.299) + (this.green * 0.587) + (this.blue * 0.114);
return (255 - bgDelta < nThreshold) ? new draw2d.util.Color(0,0,0) : new draw2d.util.Color(255,255,255);
},

copied from http://draw2d.org source code...

Greetings

[Mikhail T.]

Post by o***@gmail.com
var bgDelta = (this.red * 0.299) + (this.green * 0.587) + (this.blue * 0.114);
return (255 - bgDelta < nThreshold) ? new draw2d.util.Color(0,0,0) : new draw2d.util.Color(255,255,255);

Well, this seems to simply choose between black and white, right? That's not
very interesting :-)

-mi