| | Vent
Registered: Jul 2003
Posts: 6 |
A little gfx conversion experiment..
On this page is presented step by step a conversion of a 24 bit test image to Drazlace format. Includes different C64 palettes for Adobe Photoshop etc.
I'd be glad to get ideas concidering the topic.
http://www.cs.tut.fi/~vtr/c64conv/ |
|
| | Oswald
Registered: Apr 2002
Posts: 5086 |
Im used to play with conversion of pictures, but in my method only the last step is to use konv1.exe and not the first!!
just get any advanced pixel editor (photoshop, whatever)
- increase the contrast as much possible
- increase the hue level too
- I use an effect of coreldraw wich is called 'smart blur' it basically kills all little small contrast details, makes to pic look cartoonish.
- then I convert the palette to c64 palette, sometimes FS dithering helps a lot sometimes not
so the key thing in converting a picture is how good you can pre-manipulate the pic, b4 converting it to c64 format.
another very important thing is the picture itself, its a good idea to use pictures with big flatcolor areas, not too
much too little details, good contrast, colors close to c64, etc.
and after finishing your job with konv1.exe there comes the last phase: the experienced hand of a c64 gfxman :)
|
| | Cruzer
Registered: Dec 2001
Posts: 1048 |
Another thing you should do b4 converting a pic is making it about 16% wider before converting, since the c64 pixels aren't square like PC pixels, but only about 86% as wide as they're high, according to my experiments @least. Take a look at the startup screen on a real C64 compared to e.g. Vice to see the difference. |
| | Vent
Registered: Jul 2003
Posts: 6 |
I've noticed that C64's and PC's 320x200 aspect ratio are quite close to each other. So if you draw with a PC, you should use some DOS software like Grafx2 or DP2E, if you want to keep the aspect ratio correct, right? :) |
| | Cruzer
Registered: Dec 2001
Posts: 1048 |
@Vent: That's prolly right. I normally use Photoshop and adjust the horizontal width of the screen to see how it would look. |
| | algorithm
Registered: May 2002
Posts: 705 |
Just use my BMP2MCI or BMP2IFLI application to convert the image in very high quality.
Thats all there is to it.
www.algotech.co.uk |
| | Vent
Registered: Jul 2003
Posts: 6 |
Those programs seem to be quite cool! If you don't mind, I'd love to refer to those utilities on my website.
Though, I must say the main reason for making that gfx conversion page was not only to experiment with converting true colour images to c64 but to make gfx converting easy in general.
In my honest opinion, all those native C64 graphics editors suck - at least when compared to e.g. Deluxe Paint or Grafx2. So I personally rather use those for drawing C64 pics.
The only drawbacks in using those programs are:
At first, it's quite difficult to remember to count the amount of colours in 8x8 blocks all the time. It's quite depressing to do a cool picture with Grafx2 and when you convert it, most of the details are f*cked up because of the colours/block limitation. Also Konv1 does not warn you about the faulty blocks - it just converts the pic and you have to check the flaws from the result and fix the original and convert again and fix again and...
At second, you have to use correct RGB values for the colours so the picture would not look stupid when converted due to wrong colour values. For example, if you draw using C64S's or CCS64's palette, the colours are everything but natural so the resulting picture will look radically different on your TV screen when you look the pic with a real sixtyfour. And because Konv1 supports those palettes, you first have to use a realistic palette and then change the colours before converting.
So, your programs seem to do the trick better than Konv1, at least one can see the result simultaneously and compare to the original. I'd just like to know what RGB values did you use in your programs for the native C64 colours?
It would be cool if someone would make a program with Windows GUI, that would show the flaws from a 16 colour picture so it would be easier to fix the pic with a decent gfx editor and one would not need to be a masochist and use C64 editors at all. A stupid analogy: I want a C compiler and there are only macro recorders available ;)
Sorry for stupid typos and grammar fuckups. I am tired and this is the second time I'm writing this same message because Internet Exploder decided to crash when posting the first one. |
| | jailbird
Registered: Dec 2001
Posts: 1578 |
http://c64.rulez.org/~jailbird/conv/conv.html
"so the key thing in converting a picture is how good you can pre-manipulate the pic, b4 converting it to c64 format."
Sort of, yes. But it depends from converter to converter, and nevertheless the interlace/non interlace and the expectation of color-bugs, what kind of pre-manipulation will suit you the best.
Now, for interlace, or drazlace (multi color interlace), as in this case:
- First of all, increase the contrast indeed, but not as much as possible, you'll lose important color-fades ( "short" fade-areas, f. e. "borders" of face, hand, small areas).
- IMO, don't increase hue at all, rather decrease brightness - interlace likes darker colors.
- Blurring doesn't seems to me like a good idea, unless for IFLI, but I don't get the reason anyway.
So, where all converters fail at !interlace! are the following areas: dithering, anti-aliasing and colorfades. I guess it's just the inability of a converter to "think" as a "smart" graphician, plain multi-colour interlace will never look so good with a simple convert as if it was pixelled or post-improved with care.
Dithering: ordered or alligned pattern-dithering is not the best way to dither in interlace, according to my experience, dithering will look the most effectual if it consist of (blurred) spots bigger or much bigger than a single pixel, and mixed with huge dithered areas of a 1-0-1-0-1... dithering scheme. Hard to explain, you have to see that in practice. Converters fail, as they're mostly forceing ordered ditherings that will make the picture too flat or floyd-steinberg that will make interlace too flickery.
Anti-aliasing: basically, converters are anti-aliasing as they're programmed to, and not by their instinct, as graphicians would do. That's a huge lack of every converter, and that's why you shouldn't blur the original picture too much. Blurring will of course, decrease sharpness of areas that *have* to be sharp to get better results.
Coloring, color fades: a color fade, or colors one beside another that look OK for non-interlace images, can look very shitty if they're interlaced. Most converters use the same scheme for noninterlace/interlace, and do not make any differences.
My suggestions are the following: use Photoshop, Photo Paint, any 24bit picture mainpulating thingie. Increase contrast to get to a level where you get quite a lot of white but you still clearly see the details of the face. Decrease brightness to a level where the darker areas are really black. After this you can convert the picture as-is, or to try messing with 32-64 colors and pattern-dithering, to get the dithering right. Next is to manipulate the picture a bit with GFX2 or any other painter program and finally, to convert it. But ofcoz, if you want to get the best results, you still have to work a lot on it in Drazlace afterwards, or at least to improve the small details and the colorbugs, nevertheless to work a bit on the anti-aliasing.
One more thing, I constantly notice that monitors of PC users are set too bright, consequently, they see palettes differently to you, in this case, a palette won't look C64ish on a PC monitor that is set more brighter or darker. A quite easy solution (but perhaps for win users only?), to use Adobe Gamma (in the Control Panel) to set your monitor's gamma values right. IMHO, Pepto's colortable is still the closest one to C64.
I missed the deadline of Attitude just by several hours with an article about this topic, so as I wrote a lot about it already, don't want to repeat myself. Well, as they say, patience is a gift. |
| | algorithm
Registered: May 2002
Posts: 705 |
The BMP2IFLI utility dithers the image based on pepto's C64 colour palette. |
| | HCL
Registered: Feb 2003
Posts: 727 |
My thoughts as a coder (and sometimes gfxer): No converter will ever be able to *see* if it does well or not. All we can do is more or less smart algorithms that will optimize the conversion in some or another way. From an artistic point of view, this is useless.
Still i can imagine that a converter may be cool to have, and would do about 90% of the job. But *PLEASE* do those last 10% with your own hands, if you don't want to do all 100%. |
| | Oswald
Registered: Apr 2002
Posts: 5086 |
jailbird:
increasing contrast and hue comes from experience...
ofcourse I didnt mean to turn the contrast to the maximum that your high tech gfx tool is capable of. just as much as the picture still looks good (=as much as possible).
and I still think increasing the hue level helps, as these operations will get all colors in the picture closer to the c64's palette. (wich has lot of maximum colors in rgb I mean f.e. max green 0 255 0.. )
also I didnt mean that usual blur routine, that you can find in all of those gfx tools. this is a special one wich will kill only the almost anyway invisible little details (low contrast stuffs, with almost no color differences.. but depends also on the settings), but it KEEPS the important details edges, etc. |
| | Ninja
Registered: Jan 2002
Posts: 411 |
if groepaz somewhen moves his ass away from the gamecube and continues working on his c64-projects, you can expect the ultimate converter tool somewhen. Well, if.. ;) |
| | White Flame
Registered: Sep 2002
Posts: 136 |
As far as the aspect ratio goes, every time I program some C64 graphics stuff on the PC, I set the screenmode to 640x400. Same aspect ratio as 320x200, but you get plenty of "offscreen" space, and you don't get that ugly scandoubling. I also run VICE in 640x400 (with Double Size turned off), getting the full border and proper aspect ratio. |
| | chatGPZ
Registered: Dec 2001
Posts: 11364 |
Oswald: the feature you mean is "despeckle" no? :o)
i would suggest some matrix/convolve based blur that preserves edges and blurs at adjustable radius and threshold.... some gaussian blur variants are good at this aswell.
Ninja: patience :o) atm its way to hot for _any_ sort of coding anyway :=P |
| | Oswald
Registered: Apr 2002
Posts: 5086 |
Groepaz: coreldraw simply calls it "smart blur", dunno what the algo's name could be.. but it also has a jaggy despeckle effect, so I think it would call it simply despeckle if it would be that :) |
| | MagerValp
Registered: Dec 2001
Posts: 1074 |
First of all, any graphics converter that works with RGB values is fundamentally flawed. Colour 0 is black, colour 1 is white, etc, regardless of the RGB values of the palette. Anything else is just silly, and leads to a dithered mess.
As for the aspect ratio, no, VGA 320x200 is not very close to the C64's aspect ratio, at least not on a PAL machine. The visible C64 resolution is closer to 384 x 288, with perfectly square pixels. It all depends on your TV/monitor of course, but it's not as stretched as a PC's 320x200.
|
| | algorithm
Registered: May 2002
Posts: 705 |
Overall, The best results are achieved when actually drawing the picture from scratch rather than converting it. A good graphic artist will be able to utilise their own color transitions methods (hashing, stipples etc) on the image which in nearly all cases will look better than floyd steinberg dithering using conversion programs.
|
| | Vent
Registered: Jul 2003
Posts: 6 |
Oh yes! And the conclusion is:
There should be a converter which works the way MagerValp described. And it should _not_ try to alter the picture in any way. If there are blocks with more colours than possible in the original image, the converter should just give an error message, and not try to fix or dither the image. This would prevent all the flaws.
In practice, that means that one could completely draw a picture on a decent pixelling program, and then just save the picture in a c64-compatible file format with this "converter" tool.
That kind of program should not be too hard to write? ;)
I think I have repeated myself. |
|
