|
Grex > Coop10 > #98: Agenda for the 4/22/98 Grex Board of Directors Meeting | |
|
| Author |
Message |
| 20 new of 44 responses total. |
mdw
|
|
response 25 of 44:
| 
Apr 25 18:26 UTC 1998 |
So far as the computer is concerned, a "different intensity" is a
"different color". You might like to think of colors differently, but
from the computer graphics standpoint, it's simplest to consider white,
light pink, red, and black as 4 different colors, even if some of the
RGB values happen to fall more or less on a line. Of course, one of the
nice things about computers is you can hide the actual implementation
details from the user, and present a completely different user interface
that give people (for instance) a color wheel to select colors from, and
then maps it internally into the actual RGB values for the screen.
|
dang
|
|
response 26 of 44:
|
Apr 27 17:54 UTC 1998 |
resp:24 I think marcus was saying that there is an 8-bit lookup into a
table of 24 bit values, which are the 3 8-bit quantities you mentioned. Thus,
you can only have 256 colors at one time, but which 256 colors you use can
change. That's the cause, if I'm right, of the funky "Screen goes funny colors"
you get in unix when you switch to our netscape window. Netscape want's a
*different* 256 colors than the rest of X-windows. That's alwo why you don't
get it on 32-bit displays, because they can indes all the colors at once.
|
rcurl
|
|
response 27 of 44:
|
Apr 28 05:18 UTC 1998 |
Which 256 of the 256^3 24 bit colors are allowed?
|
aruba
|
|
response 28 of 44:
|
Apr 28 08:00 UTC 1998 |
It works like this, Rane. Somewhere in the computer are two blocks of
memory, which I'll call the "screen array" and the "palette array". Lets
assume that the video mode is 1024x768, with 256 colors.
Then the screen array will be a block of 1024*768 bytes - one per pixel on
the screen. The upper left corner might look like this:
/----+----+----+--
| 00 | FE | 00 |
+----+----+----+--
| 00 | 02 | 01 |
+----+----+----+--
| FF | 03 | FF |
+----+----+----+--
| | | |
The pallete array is an array of 256 3-byte blocks. Each byte represents
a value for one of the 3 colors red, green, and blue. The beginning of
the palette array might look like this:
/----------\
| 00 00 00 | (color 0 has all colors turned off - i.e., it's black)
+----------+
| FF 00 00 | (color 1 has lots of red and no green or blue, so it *is* red)
+----------+
| 00 FF 00 | (color 2 is green)
+----------+
| 00 FF FF | (color 3 has some green and some blue in it.)
+----------+
| |
So when the computer decides what color to make a particular pixel on the
screen, it's a two-step process. First it looks up the value in the
screen array. Then it uses this value as an index into the palette array,
from which it retrieves the actual color. So, for instance, the pixel in
row 0, column 0 has color value 0, which, according to the palette, means
it will be black. The pixel in row 1, column 1 has color value 2, which
means it will be green.
The advantage to this method is that it uses only about 1/3 as much memory
as it would if each pixel had a full color value associated with it. The
disadvantage is that you can only have 256 colors at a time.
|
valerie
|
|
response 29 of 44:
|
Apr 28 13:48 UTC 1998 |
This response has been erased.
|
rcurl
|
|
response 30 of 44:
|
Apr 28 18:36 UTC 1998 |
Thanks^2!
|
dang
|
|
response 31 of 44:
|
Apr 29 00:57 UTC 1998 |
(And you can change what's in the pallette table, so you can have a
*different* 256 colors at different time, but only 256 colors at one time.)
|
rcurl
|
|
response 32 of 44:
|
Apr 29 03:15 UTC 1998 |
Is there a standard (or algorithm) for the 256 colors?
|
dang
|
|
response 33 of 44:
|
Apr 29 18:24 UTC 1998 |
I imagine there's a standard for which 256 colors are used by default, but
I don't know what it is.
|
davel
|
|
response 34 of 44:
|
Apr 30 02:01 UTC 1998 |
<wonders why we're discussing colors in the agenda item for the board meeting>
|
rcurl
|
|
response 35 of 44:
|
Apr 30 05:26 UTC 1998 |
(because the agenda identifiers are colors - why are we wispering?)
|
robh
|
|
response 36 of 44:
|
Apr 30 11:35 UTC 1998 |
(Because it's way too early to shout.)
|
rcurl
|
|
response 37 of 44:
|
May 1 04:41 UTC 1998 |
(..good point..it was way too late to shout when I wrote #35 - and now..)
|
dang
|
|
response 38 of 44:
|
May 1 14:54 UTC 1998 |
IS IT OKAY TO SHOUT NOW?
|
rcurl
|
|
response 39 of 44:
|
May 1 15:18 UTC 1998 |
WHY ARE YOU SHOUTING?
|
dang
|
|
response 40 of 44:
|
May 2 21:34 UTC 1998 |
(Because they said it was too early to shout, so I was wondering if 11 AM was
late enough to shout.)
|
rcurl
|
|
response 41 of 44:
|
May 3 01:11 UTC 1998 |
I think so.
|
srw
|
|
response 42 of 44:
|
May 10 16:27 UTC 1998 |
Congratulations!
This item has now established a new record for drift in a Board Agenda
item.
|
rcurl
|
|
response 43 of 44:
|
May 10 17:25 UTC 1998 |
The tether got cut after 4/22, so drift is expected, even without some
help from physics.
|
dang
|
|
response 44 of 44:
|
May 12 17:54 UTC 1998 |
Maybe intense solar wind?
|