[CSDb] - User Forums - converting graphics...

You are not logged in - nap

CSDb User Forums

Forums > C64 Pixeling > converting graphics...

2006-01-15 21:58

spinal
Account closed

Registered: Jan 2005
Posts: 47

converting graphics...

I've started a GFX converter, just for fun.

I started by calculating the possible colors mixable from a fairly accurate C64 palette, and came up with the following 135 color palette (including the origional 16 C64 colors).

Using it, I did an RGB comparison to the 135 colors, an plotted the two colors which compose the mixed color on odd or even lines, ie, if the line being drawn was even, then color 1 was plotted, if odd, color 2. The result follows...

I have yet to do lo-res color reduction(3+background), but there is plenty of time for that.

I was wondering if anyone can offer advice for better quality output, I read in another post, that a luminosity check should be done first, then an RGB check (I assume only checking close luma values), I gave that a go first, but ended up with a very similar output.

2006-01-15 22:26

chatGPZ

Registered: Dec 2001
Posts: 11523

for best results a recommend this:

1. transform your image into yuv colorspace

2. for each pixel do the following:
a) pick the nearest match for one of the 8 possible luminances
b) pick one of the the two colors with that luminance

3. for fixing colorclashes, do the same, except you pick from the remaining possible luminances/colors in a certain cell.

DONT do any calculation/color matching in rgb at all, unless you want that typicall "converter look".

2006-01-16 00:38

Oswald

Registered: Apr 2002
Posts: 5127

groepaz: your YUV space method might generate nice images, but I dont think taking first the brightness, and only then the hue is more correct than rgb color distance.

consider the difference between "nice" and "correct" before writing your reply :)

this way of YUV space converting gives probably nicer gradients, but color wise it will be incorrect.

the c64 has only 16 colors, you will get converter look most of the time no matter what, if you dont choose ur picture carefully, and dont pre adjust it.

spinal, you should ask graham that which pixels mix good in that way and which not, as is your algo is prolly less good than any dithering. Remember the c64 has only 16 colors, there are no miracles. Conversion depends mostly on the source pic, if the colors are not close to c64 colors conversion will suck no matter what.

2006-01-16 00:40

Oswald

Registered: Apr 2002
Posts: 5127

spinal, check your routine, it might have a bug, dark blue, and blueish black is converted to red / dk brown.

2006-01-16 01:10

chatGPZ

Registered: Dec 2001
Posts: 11523

Quote:

consider the difference between "nice" and "correct" before writing your reply :)

mmmh well...if it looks nice, i couldnt care less if its "correct" :=P

2006-01-16 05:02

A Life in Hell
Account closed

Registered: May 2002
Posts: 204

As groepaz said, one important thing is to convert in the YUV colourspace - this is because human perception is optimized for lumanence, not chromanence, and hence it doens't distinguise colour information at terribly high resolution (jpeg, mpeg, and such like work like this, too, sending the colour information at half resolution)

I'm handling things in my tool a little differently to what groepaz suggests - I do a colour difference, as you would normally do with RGB (colour different is always (channelDiff^2)+(channelDiff^2)+(channelDiff^2), btw - to give larger differences more "hurt"), but I have a variable "colour importance", which scales how important the chroma is within this calculation - 0.25 is the current default.

My colour clash algorythm does work exactly like his explanation, however - although for my current convertor, which I've uploaded source (commandline, requires imagemagick to get the images into yuv in the first place, and exomiser to generate c64 executables - but has a bunch of .prg samples as well. needs PAL emulation on vice to look good, or real c64, since it takes advantage of horizontal chroma mixing, and of coruse it fixes aspect ratio so will look squished on vice. use http://dspaudio.com/~jaymz/wirescan.prg if you have netdrive to watch the progress in realtime) at http://dspaudio.com/~jaymz/eciwire-v5.zip . havn't written any UI as of yet, since I just wrote it for the technical challenge - I would, but I sort of assume that no-one other than me loves ECI mode :).

Anyhow, due to the odd colour limitations (2 colours per 8x1 per interlace field), I'm actually literally brute forcing every "sensible" colour combination - created in a table at the start of the program. This works actually surprisingly well, and might not be the worst idea for multicolour mode where colours are tight, as well. Just a thought, anyhow.

Oh, yeah, given that you're not fli, did you consider x-y modulating your dithering instead of just y modulating? I believe it would look better, on hardware at least, but I could be wrong.

Good luck with your tool :). I like the test image, btw.

2006-01-16 05:07

A Life in Hell
Account closed

Registered: May 2002
Posts: 204

Oh, I almost forgot - do _ALL_ operations at gamma 1.0, which means for images from the PC, converting them to gamma 1.0 by multiplying the luma by pow(1.0/2.2) or pow(2.2/1.0), i forget which way around :). I do this in the 0.0 -> 1.0 floating point space, so I don't need to rescale after. You might do it other ways.

The only exception to this is the differnece calculation - which I found gave truer results when the difference was calculated at gamma=2.8 or 2.2, depending on your view of the world (I thought i did 2.8, but now that i look at my code i did 2.2 - but it they're not _that_ far away, for this purpose it's okay. but i'm sure it caused some small bugs :).

And, of course, get a good YUV pallette - i stole mine from a combination of vice and the "all you ever wanted to know about vicii" page, but ymmv. But if your palette sucks, so will your output!

Oh, and you absolutely want a limit on which colours can be combined - i set that to lumeDifference=160 max, but again ymmv. But seriously, some sources WILL look shite without such a tweak.

2006-01-16 07:25

spinal
Account closed

Registered: Jan 2005
Posts: 47

I'll check the red/brown bug, I didn't notice it myself.

Currently the 135 color palette is calculated at run-time, and then some of the colors are removed (ones where the grayscale of the mixing colors are vastly different) i did this by graying the two mix colors (R+G+B) then checking how different they were, if theye were too different, the combination was egnored, e.g. if yellow and black, then dont use. this gave much better results than using all possible combinations.

2006-01-16 08:03

Oswald

Registered: Apr 2002
Posts: 5127

anyhow YUV or RGB converter, the best result will only come if a gfxer retouches about every pixel in a converted pic. So searching for the ultimate converter is like the search for the holy grail.

converting from 24 bit to 8 bit paletted, and dithering, and fancy stuff makes sense.

converting from 24bit to 4 bit fixed colors will never make much sense :)

imho

2006-01-16 08:13

A Life in Hell
Account closed

Registered: May 2002
Posts: 204

Quote: anyhow YUV or RGB converter, the best result will only come if a gfxer retouches about every pixel in a converted pic. So searching for the ultimate converter is like the search for the holy grail.

converting from 24 bit to 8 bit paletted, and dithering, and fancy stuff makes sense.

converting from 24bit to 4 bit fixed colors will never make much sense :)

imho

Isn't doing something for the technical challenge of it enough?

2006-01-16 10:36

Oswald

Registered: Apr 2002
Posts: 5127

for some yes for some not :)

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

Previous - 1 | 2 | 3 | 4 - Next

Refresh

Subscribe to this thread: