| |
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?
|
|
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
There are multiple problems with that. For example there is a nonlinearity on display. An RGB value of $C0C0C0 is not twice as bright as $606060. |
| |
MRT
Account closed
Registered: Sep 2005
Posts: 149 |
True... I found that out the hard way... :-)
For example...
The colors MedGray (12) and LightGray (15) are LESS bright then the mixed colors Black (0) and White (1)
|
| |
Twoflower
Registered: Jan 2002
Posts: 434 |
There's really only one way to find this out - by testing out the interlaced colors in practice, on both old and newer VIC's. A good way to see how it works is to do it on the real thing and make 2x2 chars squares with different interlaced colors and place them besides eachother. The good old eye will spot the differences in a flash. Since colors works so differently on the real thing with an oldfashioned TV or monitor, this is one of the things which are essential to check out on the real machine.
The colors will also differ depending on the technique of the interlacing. Often you'll find that the colors will be percieved different. I guess this have something to do with how PAL works or sth. Better ask Graham about it. :-)
I'm quite sure that this isn't of much help for you, but my point is that interlaced colors on the C64 are quite hard to "calculate". Just experience the mixes and make tables out of visual luminosity/color and use these. A good trick to use is the "make everything green" button, which atleast I have on my Philips monitor. |
| |
MRT
Account closed
Registered: Sep 2005
Posts: 149 |
:-)
What if I told you I was color-blind... :-)
But still... If I could see all colors, then I would still need the RGB values if I want to use it for a cross-platform image converter.
Is the Project 1 tool also able to create interlaced images?
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
P1 doesnt cares of lace colors. laced pics are handled as straight 320x200. |
| |
A Life in Hell
Account closed
Registered: May 2002
Posts: 204 |
Quote: 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?
The key is that one needs to do the colour mixing calculation in gamma-1.0 space, not the gamma 2.2 that a pal tv has (or is it 2.4... whatever). This is actually true of dithering as well, btw.
A quick paste from my conversion tool (note that you can do this in integer space, but you will lose quality!)
double palGamma=2.2;
double srcGamma=2.2;
#define dstGamma 1.0f
#define gamma(in) (pow(((in)/256.0), dstGamma/srcGamma)*256.0)
#define igamma(in) (pow(((in)/256.0), srcGamma/dstGamma)*256.0)
How I handle this in my conversion tool is by converting all RGB colours incoming from their appropriate gamma (I'm assuming 2.2, though i've heard 2.4 and 2.8 from other people) and doing all comparisons in that space - and it gives quite good results (look at http://dspaudio.com/~jaymz/miho-1.prg and http://dspaudio.com/~jaymz/miho-1a.prg for an example... eci mode, tho, which has odd colour limits, heh).
I probably should slap a UI on it and release it, but laziness, you know :)
One other note: You should do _all_ of your comparisons in the YUV space, not the RGB space - you will end up with much more accurate colour representation. This also allows you to have a luma:chroma tradeoff variable, which can assist on making some pictures come out as not grey blobs of mess :) |
| |
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. |
