Small Shift in Color Values

[Marc Lehmann]

On Tue, Nov 29, 2011 at 02:34:20PM +0100, Bastien Dejean <nihilhill at gmail.com> wrote:
> I've looked at grabc[1] (no other dependencies except X), the relevant
> (bogus?) piece of code seems to be:
> 
>     r=(color.red >> 8);
>     g=(color.green >> 8);
>     b=(color.blue >> 8);

yes, that always throws away colour information (it divides components by
256 and throws away the remainder).

For example, with a component of 0xfefe, this results in a display of
0xfe, which corresponds to 0xfe00 - but 0xff00 would be much nearer to the
actual framebuffer colour.

> > thing in the lower right, I get "#9c9c9c" for both normal text and the
> > block your command prints.
> 
> It should[2] be '#9E9E9E'.

Not sure what you mean - if I specify a colour that my hardware cannot
display then I expect the program to choose the nearest colour, not the
next brighter or darker colour. If you disagree with that, feel free to
argue your point :)

> I tried the following:
> 
>     URxvt.foreground: #FFFFFF
> 
> xmag sees it as (fefe, fefe, fefe).
> (Why?)

Thats the nearest colour to the one you specified (#ff00ff00ff00).

Look at it in more detail then: you request a colour with all channels
set to 65280 (ff00). urxvt gives your the nearest hardware colour, which
is 65278 (fefe), which is just 2 units off (65280-65278), a pretty good
match.

The colour you probably expect is 65535 (ffff), but that one is 255 units
away from the colour you requested (65535-65280).

If you want #fffffffffff, then either you have to write it out like that,
or use rgb:ff/ff/ff, rgbi:1/1/1 or some other abbreviated syntax that is
equivalent to #ffffffffffff.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\