Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > Best way to mix 2 RGB colors ?
2003-02-25 08:14
Majikeyric

Registered: Sep 2002
Posts: 83
Best way to mix 2 RGB colors ?

Hi everybody !

In your opinion, what is the best way to mix 2 RBG colors and obtain the intermediate one ?

I was thinking :

adding the 3 RGB components individually and divide by 2 :

ex:
color 1 = $ffffff (white) => R1=$ff G1=$ff B1=$ff
color 2 = $000000 (black) => R2=$00 G2=$00 B2=$00

intermediate color = $7f7f7f because :

R=(R1+R2)/2 = $7f
G=(G1+G2)/2 = $7f
B=(B1+B2)/2 = $7f

Do you think I'm right ?

thanks.
 
... 1 post hidden. Click here to view all posts....
 
2003-02-25 13:17
JCB
Account closed

Registered: Jun 2002
Posts: 241
Graham is right, doing the + /2 method will produce reasonable results and is fast (good for realtime) but to do it properly you really need to convert to another colourspace (HSV/B or maybe YUV) then convert back to RGB. If you use + /2 with RGB the brightness will be wrong.
2003-02-25 17:51
Bert/RDS

Registered: Apr 2002
Posts: 17
Is there a function that describes the 'non-linearism' of RGB on normal VGA-Monitors?
2003-02-26 02:56
White Flame

Registered: Sep 2002
Posts: 136
It's normally called "gamma correction", and I'm sure Google can list the actual function thousands of times over.

RGB is a linear scale. However, most display hardware don't display a 0-100% voltage input as a linear intensity on their output, due to the phosphor or LCD behavior. I'm of the opinion that applications shouldn't have to worry about that calibration, the system running it should. Most modern PC video cards have drivers that let you adjust the gamma, and I believe Macs have been doing this for some time. A lot of LCD projectors can do that too.
2003-02-28 12:28
bubis
Account closed

Registered: Apr 2002
Posts: 18
Quote: Graham is right, doing the + /2 method will produce reasonable results and is fast (good for realtime) but to do it properly you really need to convert to another colourspace (HSV/B or maybe YUV) then convert back to RGB. If you use + /2 with RGB the brightness will be wrong.

If converting to another color space is a linear transformation than averaging there and than converting back is the same than averaging in the original color space.
RGB to YUV is linear as I know.
In HSV H=Hue is an angle that points to a color in a color circle. Here the average of red and blue is green in H. :) This method only works for near colors in this space.
2003-02-28 15:26
Seven

Registered: Jan 2002
Posts: 201
when converting back and forth between color spaces, just keep in mind that the color in one color space may not really be (read: hardly ever is) the exact color you started from in another color space.

As for converting RGB to HSB ... seems like a good idea when the B in HSB stands for brightness anyway... in theory... as you will notice when playing around in the color picker of your choice, a color with a brightness of 100% reduced to 50% gets you half of the RGB value aswell... (at least Photoshop does, and I guess it's safe to say that a company that deep into Publishing Business like Adobe knows what they're doing).

Quote from "Grokking the GIMP" by Carey Bunks (http://gimp-savvy.com/BOOK/index.html?Grokking_the_GIMP.html)

---8<---- SNIP ----------------------

There are many concepts closely related to brightness and that have various useful properties. Brightness is formally defined to be (R+G+B)/3; it is a physical property of color and does not correspond well to human color perception.
[...]
* luminance, Y=0.30 R + 0.59 G + 0.11 B.

Luminance is the representation of brightness that corresponds best to human perception because the weightings 0.30, 0.59, and 0.11 most closely match the sensitivity of the eye to red, green, and blue.

---8<---- SNIP ----------------------

Maybe this helps...
2003-03-01 20:07
chatGPZ

Registered: Dec 2001
Posts: 11088
ok...to add some more to what seven posted.... here is the info you need about YUV:

oh and about the gamma correction.... as the "correction" part suggest, that calculation is to "linearize" the data before manipulating, and to "non-linearize" it again afterwards (for displaying). this is a very very sensitive field, many ppl have implemented gamma wrong in the past (also in so called state-of-the-art image processors), many many existing pictures have fucked up gamma, few ppl really understand what gamma is all about. have a look on the web, there is tons of information on this topic. read some of it, implement gamma correction yourself, and you will eventually see how it could help with further calculations in colorspace. btw i think pepto had a nice summary on the topic on his "vic colors" page.

RGB - red, green, blue

Y - Luminance Signal, "Lightness"
U / V - Color Difference Signals
S - Saturation
H - Hue

convertion from/to YUV

RGB -> YUV
Y = 0.299*Red+0.587*Green+0.114*Blue
U = -0.147*Red-0.289*Green+0.436*Blue
V = 0.615*Red-0.515*Green-0.100*Blue

YUV -> RGB
Red = Y+0.000*U+1.140*V
Green = Y-0.396*U-0.581*V
Blue = Y+2.029*U+0.000*V

relation between U-V and H-S

U = S * cos(H)
V = S * sin(H)

H = atan2(V,U)
S = sqrt((U*U)+(V*V))

mixing colors

color-mixing works simelar to RGB, just average each component seperatly:

Y' = (Y1+Y2)/2
U' = (U1+U2)/2
V' = (V1+V2)/2

H' = (H1+H2)/2
S' = (S1+S2)/2

computing color difference

simelar to RGB, you may compute a color-difference value like this:

Y' = abs(Y1-Y2)
U' = abs(U1-U2)
V' = abs(V1-V2)

YU' = (Y'*Y')+(U'*U')
YV' = (Y'*Y')+(V'*V')
UV' = (U'*U')+(V'*V')

diff = YU' + YV' + UV'

oh btw...whoever said that converting forth and back from/to a colorspace doesnt change the original color is wrong.... some reading on the subject is suggested :o) (color "gamut" is the key here)
2003-03-02 10:04
Graham
Account closed

Registered: Dec 2002
Posts: 990
still, mixing two rgb colors is best done in some way like first described. the only difference would be to make rgb linear first, so you just need a function to remove the gamma.

R_linear = inverse_gamma(R)
G_linear = inverse_gamma(G)
B_linear = inverse_gamma(B)

done this, you can indeed simply do (R1+R2)/2 to average the colors.

the gamma function is usually taken as exponential function which best describes the physical non-linearity of the phosphor of a CRT. if 255 in an 8-bit RGB color channel would refer to maximum voltage output:

255^(1-gamma) * x^gamma

this formula should result in a value which should be in linear color space. to invert this formula (take back into exponential space) you simply have to invert the gamma exponent (i.e. 1/gamma).

which gamma to choose? this is quite difficult since os developers never cared too much for gamma. it depends on the monitor you use and on the gamma settings your os might or might not have. if no gamma values are set for the os:

VGA: gamma = 2.2
PAL: gamma = 2.5 (2.8)
NTSC: gamma = 2.2
Mac-monitor: gamma = 1.8
TFT: gamma = unknown, not defined

PAL is defined to have a gamma of 2.8, but hardly any PAL devices actually have this gamma. most use 2.5
2003-03-02 22:31
White Flame

Registered: Sep 2002
Posts: 136
Gamma shouldn't be applied to the pre-screen values. Work with the "theoretical" RGB values internally, then only apply the correction at the final copy to the frame buffer if you want to do gamma correction. RGB *is* linear; I don't see where "make RGB linear first" comes from. The gamma function warps the RGB away from linearity so that when the CRT warps it again, the effect on your retina is linear, but the internal values 0-255 represent a linear scale from zero to full intensity.
2003-03-03 02:37
chatGPZ

Registered: Dec 2001
Posts: 11088
WhiteFlame: the "make it linear first" comes from the fact that many (if not most) exisiting images have been gamma-corrected (although they shouldnt have been). so if you take some image, and want to fiddle with it, you should "un-gamma" it first.

ofcoz you are right that gamma-correction should _only_ be applied before making the image visible. (ie NOT before saving it to disc like some paintprogs did, and some still do). that said, you actually _should_ never really have to care about gamma at all, since your OS should do it. thats plain theory though :o)
2003-03-03 11:41
Graham
Account closed

Registered: Dec 2002
Posts: 990
exactly.
Previous - 1 | 2 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
iAN CooG/HVSC
hedning/G★P
DKT/Samar
Mihai
Zorch
Mason/Unicess
Guests online: 291
Top Demos
1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 No Bounds  (9.6)
6 Comaland 100%  (9.6)
7 Uncensored  (9.6)
8 The Ghost  (9.6)
9 Wonderland XIV  (9.6)
10 Bromance  (9.6)
Top onefile Demos
1 Party Elk 2  (9.7)
2 Cubic Dream  (9.6)
3 Copper Booze  (9.5)
4 Rainbow Connection  (9.5)
5 TRSAC, Gabber & Pebe..  (9.5)
6 Onscreen 5k  (9.5)
7 Dawnfall V1.1  (9.5)
8 Quadrants  (9.5)
9 Daah, Those Acid Pil..  (9.5)
10 Birth of a Flower  (9.5)
Top Groups
1 Booze Design  (9.3)
2 Nostalgia  (9.3)
3 Oxyron  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)
Top Logo Graphicians
1 Sander  (10)
2 Facet  (9.7)
3 Mermaid  (9.4)
4 Pal  (9.4)
5 Shine  (9.3)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.047 sec.