[CSDb] - User Forums - Calculating Interlaced Colors

You are not logged in - nap

CSDb User Forums

Forums > C64 Coding > Calculating Interlaced Colors

2006-01-11 14:34

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?

... 10 posts hidden. Click here to view all posts....

2006-01-12 12:01

MRT
Account closed

Registered: Sep 2005
Posts: 149

@spinal:
What do you mean by "Hals the values"???

2006-01-12 13:22

chatGPZ

Registered: Dec 2001
Posts: 11523

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 :=)

2006-01-12 17:10

Oswald

Registered: Apr 2002
Posts: 5127

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)

2006-01-12 18:22

JackAsser

Registered: Jun 2002
Posts: 2038

@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.

2006-01-12 19:40

chatGPZ

Registered: Dec 2001
Posts: 11523

@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)

2006-01-14 10:06

spinal
Account closed

Registered: Jan 2005
Posts: 47

@ MRT - Half the values, sorry.

Previous - 1 | 2 - Next

Refresh

Subscribe to this thread: