| |
MRT
Account closed
Registered: Sep 2005
Posts: 149 |
Calculating Interlaced Colors
Maybe this should be in the pixeling forum, but it occurred to me that there might be some other coder who has done some image cross-converter and had the same problem...
How does one calculate the outcomming interlace colors, when mixing two (or more) native VIC colors
What I've done so far is adding the RGB values of color A to the RGB values of color B and then deviding the results by 2... but, when I display the interlaced colors on the C64 the outcome is not as I predicted...
So, simply adding all values and deviding them by 2 isn't the sollution.
Also, capturing an interlaced image and then sampling the result is also a no-no because there is no accurate way of capturing an interlaced image (as far as I know)
Anyone got some smart ideas for this?
|
|
... 6 posts hidden. Click here to view all posts....
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
hm never heard of gamma space, do you have still color information there ?
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
another problem is that RGB is a different colorspace than what the C64 (or PAL for that matter) works in, so transforming the colors to YUV helps aswell. check http://hitmen.c02.at/html/yuvcolorspace.html for some basic info. also if you are writing a converter, using YUV for finding the closest C64 color gives a LOT better results than doing the same in RGB (find closest luminance, then choose one of two colors).
uhm. alih wrote the same. whatever :=D |
| |
spinal
Account closed
Registered: Jan 2005
Posts: 47 |
Iv done some color mixing in the past (not with c64 though)
what i did, was minus color two's RGB from color one's RGB.
Hals the values, then add them to color one. This should give you the mixed version of those two colors. |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
PAL has a gamma of 2.8 (though in practice often ~2.5 is used)
NTSC has a gamma of 2.2
VGA has a gamma of 1.8
other displays often don't have any defined gamma value.
http://people.ee.ethz.ch/~buc/brechbuehler/mirror/color/GammaFA..
|
| |
MRT
Account closed
Registered: Sep 2005
Posts: 149 |
@spinal:
What do you mean by "Hals the values"??? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
another thing to considerate are out of gamut colors.... eg PAL can not display perfect black (rgb 0:0:0) at all.
@spinal: mixing two rgb colors is as easy as taking the average from their rgb components, what you are saying does pretty much the same, just more complicated :=) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
groepaz,
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
to me it seems like rgb -> yuv, or yuv->rgb makes possible to convert a 0,0,0 color to all directions. So for black the 2 system seems to be the same.
I dont think that comparing colors in this or that color space can be the holy grail of converting. All have their advantages. An algorithm alone wont be as good as an algorithm with human interaction (setting different treshholds, preparing the picture with contrast, saturation, etc tweakings.)
Using a color space where you have HUE informations seems to make more sense, but this also might depend from picture to picture. Sometimes considering the HUE, sometimes Brightness might give better results.
At the end what really counts IMHO, is that how close most of the colors in the original picture are to c64 colors. If they are quite off no matter what, c64 colors cant represent it nicely. (I had my share of trouble trying to convert pictures with little contrast, and most colors very close to eachother, it wont work believe me)
|
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
@oswald: It's how YUV is used in the PAL signal that matters. Luminance is clipped to 16-236 and for chrominance it's clipped to 16-240. I don't remeber the reason completly, but I suspect it's done to make the bursts (for syncs) to be 100% unique in the signal.
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
@oswald: please read up on color spaces, gamut, gamma and all that jizz. it *does* make a difference. and as for converting c64 pictures, using yuv instead of rgb makes a *huge* difference. trust me, i've done a lot of experimenting in that area. if you use rgb color matching, pictures almost always get that typical converter look. if you use yuv that can be reduced a lot, and you get nice c64-like gradients. try it. then after you tried, look at some old rayden pics. OOOOOPS .=P
as a sidenote, picking nearest luminance first, then closest color is exactly what (decent) graphic artists do intuitivly (? orthographie ahoi!) when working around color clashes - infact deekay suggested that when i was working on my converter, and it works extremely well. the human eye works the same - its a lot more sensitive to luminance than color, so a single pixel with wrong luminance is a lot more disturbing than a single pixel with wrong color.
@jackasser: yes, "pure" black is used for sync signals (as in color burst) and 100% white was removed to get rid of too much crosstalk to the audio signal (you still notice it on badly adjusted tuners, but its by far less than it would be with 100% white allowed) |
| |
spinal
Account closed
Registered: Jan 2005
Posts: 47 |
@ MRT - Half the values, sorry. |
| Previous - 1 | 2 - Next |
