It's been a while since I've posted here! Does anyone know of a tool that can convert BMP's to 60 colours and convert to MD format with four palettes?
Chilly pointed me at SixPack but its lacking the facilty to do a picture with anymore than 1 palette Now while I could go all out and try to make this image look ok at 16 colours, I'd prefer to make it perfect at its present 41! hehe any suggestions?
I've written a VB app (yes microsoft yuck yuck) that gets the image working with only MD palette colours but I just need this last little push to have something I can roll images out faster with
matteus wrote:It's been a while since I've posted here! Does anyone know of a tool that can convert BMP's to 60 colours and convert to MD format with four palettes?
Chilly pointed me at SixPack but its lacking the facilty to do a picture with anymore than 1 palette Now while I could go all out and try to make this image look ok at 16 colours, I'd prefer to make it perfect at its present 41! hehe any suggestions?
I've written a VB app (yes microsoft yuck yuck) that gets the image working with only MD palette colours but I just need this last little push to have something I can roll images out faster with
This is a feature I've been planning to add to Sixpack ever since I started writing it. It's a fairly complex problem to solve though - at least if you want good results (which I do).
mic_ wrote:This is a feature I've been planning to add to Sixpack ever since I started writing it. It's a fairly complex problem to solve though - at least if you want good results (which I do).
Well I'm kinda half way house at the moment, obviously first off you have to make sure every 8x8 tile has no more than 15 colours.
I'd then guess its a case of taking the top 60 colours within the picture and using that to form palettes....
Is the algorithm used to apply a single palette to a picture complicated? I need to write one shortly...
Applying a palette to a picture isn't complicated: take one pixel P and find the palette color C with the smallest distance between P and C in 3D-space ({R,G,B}).
The tricky part is actually generating the palette. Just keeping the most frequently used colors is generally a bad idea, because it gives preference to colors that happens to appear in large chunks.
Imagine an image that has a background consisting of a vertical gradient with 32 shades of blue, and a few objects in the foreground that mainly use non-blue colors. A "top color" quantizer would obviously have problems with an image like that.
To get good results you should probably use a minimum variance quantizer or a neural network-based quantizer. I use the latter in Sixpack.
mic_ wrote:The tricky part is actually generating the palette. Just keeping the most frequently used colors is generally a bad idea, because it gives preference to colors that happens to appear in large chunks.
Imagine an image that has a background consisting of a vertical gradient with 32 shades of blue, and a few objects in the foreground that mainly use non-blue colors. A "top color" quantizer would obviously have problems with an image like that.
To get good results you should probably use a minimum variance quantizer or a neural network-based quantizer. I use the latter in Sixpack.
My present method is to:
Loop each pixel
Get the Pixels R,G,B
Divide each R, G, B value by 36 and round down the values
For each of the R, G, B values that are above 252, default to 252
For each of the R, G, B values that are below 252 times by 36
Something somewhat relative to this topic; range compression. Perception of a color brightness is partially relative (like anything else). If you avoid using pure black and use 1,1,1/1,0,1/1,0,0/0,0,1 - you get an interesting effect (as long as the person/viewer doesn't see true black anywhere on screen). It changes the perception of all the other colors through out the range. I did this for a video encoding, for 9bit master palette and a single 16color bitmap. Worked out fairly well. I'm pretty sure I've seen some stills that do this as well, in some games.
I wrote my own command line tool to do this (and a bunch of other tile munging stuff). It works OK, but I need to find better palette selection algorithms. I might try the NeuQuant algorithm that mic_ linked to. Here's what I get right now...
Using two layers is the "easy" way out. What I really want is one layer using more than one palette. Like matteus says - 16 colors in an 8x8 cell that might be chosen from 2 or more palettes.
I wrote some notes down how to write one layer convertor, but im too busy at the moment, it would be complicated to write.
This would be straight forward conversion, no compression unless needed.
Find the tile that uses the most colours in one, if > 15 colours do a tile compression.
Complete as many tiles as possible with that pallet, add new colours if original pallet had < 15.
Repeat above 4 times for each pallet.
Hopefully, if the image has 50 or less colours, and aint that complex (same colours used in the other pallets to much), the program shoud be able to complete most images with no compression.
This is only one basic way though, getting a computer to pick the right pallets to put a puzzels together, would be the messy part to write.
Chilly Willy wrote:Using two layers is the "easy" way out.
Yup, you're right, it was pretty easy to implement. I kind of had a different goal in mind though. I'd like to be able to put arbitrary colors next to each other rather than be constrained to using a fixed set of 15 colors within a single block. My idea is to try to find an organization of colors within the 2 or more palettes such that most of the tiles only use colors from a single palette. By doing this, I can leave most of plane B blank, only putting a non-transparent tile where colors outside the first palette are necessary, and hopefully, most of these would only require a single palette. I could even use strategically placed sprites to fill in the missing colors rather than a whole plane. This could be as simple as putting the most common colors in palette 0 and the next most common in palette 1 and so on.
What might be harder than getting the colors organized such that each tile only needs a single palette is an algorithm to effectively use shadow and highlight.
I have to admit, I didn't put too much thought into this and just stopped at 'good enough'.
I put "easy" in quotes because everything is relative. Doing 31 colors in two layers is "easy" relative to other schemes, but still a neat trick.
The issue with two layers is of course, it takes twice the vram. One layer would be better as then the memory requirements don't interfere with whatever else is going on as badly.
I've been thinking about this myself... if I come up with something, I'll probably make an attempt at it myself. Get enough of us all working on it and maybe someone will come up with something good.
A+B+sprite overlay allows for quite some fun.... 47 colors per tile is always interesting ^^ VRAM consumption is twice only if you don't do tile optimization... my GFX converter does tile optimization, sprite conversion, multipart sprite conversion, layer splitting... and quite a few more things... compression support must be added though
...and its got no UI nor command line
Now while I could go all out and try to make this image look ok at 16 colours, I'd prefer to make it perfect at its present 41! hehe any suggestions?
