Start with a random color palette. Convert the picture to all 4 palettes. Then chose the closest pallette for each attribute block. Then for each color, calculate the average color and round it to the nearest NES color. Then repeat the process again until it's as accurate as possible.
Sounds good except for the "start with a random palette". You would have 2.2 x 10^21 possible palettes to choose from. Unless I'm misunderstanding you.
Edit, or maybe 4 x 10^21. I'm counting 52 unique colors and 13 possible palette colors.
I haven't gotten around to writing this, but I've been contemplating something like
1- Quantize original image to 54 available colors
2- Quantize that image down to 13 colors
3- Requantize original directly to target 13 colors, to reduce loss
Then:
4- Histogram of entire color-reduced picture from step #3. Use most prevalent ("plurality") color is shared background color
5- For each attribute zone (of whatever dimensions; 16x16 down to 8x1), build a histogram of the colors in that zone; ignoring the background color
6- Take the four most prevalent palettes per the histograms
7- If fewer than 13 colors are present, restart at step #3 with the newer shorter palette
Using most frequent colors here will lose regional detail, a different selector could be chosen for that, too...
psycopathicteen wrote:
Start with a random color palette. Convert the picture to all 4 palettes. Then chose the closest pallette for each attribute block. Then for each color, calculate the average color and round it to the nearest NES color. Then repeat the process again until it's as accurate as possible.
This is similar to the
Linde-Buzo-Gray algorithm or
k-means clustering.
Didn't we just have this conversation?Anyway, it's hard to judge the effectiveness of an algorithm without images showing the result. Also, I don't think your description is detailed enough. Here are the things I don't understand:
1- "start with a random color palette": Why a random palette? How many colors does this palette have and where do they come from?
2- "convert the picture to all 4 palettes": Convert the same image to 4 different palettes? Which palettes are these?
3- "Then chose the closest pallette for each attribute block": from the 4 palettes you mentioned before? Do you mean picking the most accurate 16x16-pixel blocks from the 4 different images?
4- "Then for each color, calculate the average color": I don't understand what I'm supposed to average, because you seem to have mentioned 1 input and 1 output.
5- "Then repeat the process": Didn't the previous steps already result in a complete NES image? I don't see how applying this recursively could make things better.
Please explain what you mean in greater detail, and provide a sample picture if possible.
How about this approach...
1.Narrow the original to the 8 most common hues, ignoring their brightness.
2.construct a pallette, each has black, white, and 2 unique colors.
3.divide the picture into 16x16 chunks, decide which palette it fits best.
4.index each 16x16 chunk, dithering with black, white, and those 2 colors.
5.reconstruct the image, and attribute table.
Quote:
Didn't we just have this conversation?
The old conversation was restricted to 1 pallette (4 color)... The new one seems to be about using all 4 palettes (13 colors).
If anyone decides to implement this, as an alternative to a random palette, I wonder whether the following might converge to something reasonable faster or more reliably.
0f001020 0f112120 0f172720 0f1a2a20
Gray ramp, teals (for sky), oranges (for skin), and greens (for plants)
dougeff wrote:
The old conversation was restricted to 1 pallette (4 color)
Oh, I hadn't realized that. My contributions to that thread certainly didn't take this into consideration. Sorry for that!
tokumaru wrote:
Didn't we just have this conversation?Anyway, it's hard to judge the effectiveness of an algorithm without images showing the result. Also, I don't think your description is detailed enough. Here are the things I don't understand:
1- "start with a random color palette": Why a random palette? How many colors does this palette have and where do they come from?
2- "convert the picture to all 4 palettes": Convert the same image to 4 different palettes? Which palettes are these?
3- "Then chose the closest pallette for each attribute block": from the 4 palettes you mentioned before? Do you mean picking the most accurate 16x16-pixel blocks from the 4 different images?
4- "Then for each color, calculate the average color": I don't understand what I'm supposed to average, because you seem to have mentioned 1 input and 1 output.
5- "Then repeat the process": Didn't the previous steps already result in a complete NES image? I don't see how applying this recursively could make things better.
Please explain what you mean in greater detail, and provide a sample picture if possible.
In other words, it will keep adjusting both the image and palette until the image no longer changes with each iteration.
rgb121 is the way to go.
MODS: Please lock this thread.
The RGB121 technique works fine for stills but not so well if you need more than 256 unique tiles without a huge CHR ROM or you want to use CPU time for something other than the raster effect that powers it. If I weren't working on a paid project right now, I might try implementing this LBG method.
The thing is, NES graphics are very primitive, and completely unsuitable for photographic images. No matter how much you try to optimize patterns and palettes, you're still stuck with a certain number of tiles (depending on the mapper), 16x16 or 8x8 (also depending on the mapper) attribute areas using 4 palettes of 3 colors + 1 shared color out of a very limited master palette.
RGB121 looks good because it bends the rules. It tricks the system into displaying a picture that deviates from the normal specs, causing colors to blend in a different way. If you're not bending the rules, I don't see how an algorithm would do better than an artist doing the conversion manually using Photoshop/GIMP. Algorithms will certainly give results faster, but hardly better than a good artist, so I don't think we're gonna see any groundbreaking images coming out any algorithm that doesn't bend the rules of the display. Yes, raster effects often steal 100% of the CPU time, but you hardly need that time anyway when you're showing a full screen still image.
I don't expect to see full color pictures, but anime style flat images and reduced color images could be a possibility. There's a printing concept called 'duotone' that might work and produce nice images.
https://en.m.wikipedia.org/wiki/DuotoneEdit: and when people tell me something can't be done, it just encourages me to think of a way to do it. Maybe that's a character flaw in me, I don't know.
Maybe I should explain how to do a duotone, since the Wikipedia page doesn't...
First you turn the image into a black and white. Then instead of shades of gray in the palette, you use shades of pink (faces) or shades of blue (other things).
This duotone technique resembles the process I used when trying to
make NES-style portraits of #nesdev regulars.
The hardest part is automatically coming up with a palette, and the LBG algorithm described above might work well.
dougeff wrote:
Maybe I should explain how to do a duotone, since the Wikipedia page doesn't...
First you turn the image into a black and white. Then instead of shades of gray in the palette, you use shades of pink (faces) or shades of blue (other things).
This description seems off (you just described variants of monochrome), duotone is more like converting it to a two-channel color format (instead of three-channel like RGB). On the NES, that'd be like treating the tiles as two 1bpp channels instead of a single 2bpp one (and you'd need to resort to dithering too).
At which point just plain grayscale 2bpp with dithering is a better choice, just using a different hue/saturation for the shades.
Here's what I mean. Trust me I've made 100+ duotone images over the years...
1. Color photo
2. convert to black and white
3. convert to duotone
4. convert to NES 4 color palette
And you don't really need step 3, I just included it to demonstrate an actual duotone image.
(Edit)
My point, is that the final product will LOOK like a duotone, not that you need to use these steps to get there.
dougeff wrote:
I don't expect to see full color pictures, but anime style flat images and reduced color images could be a possibility.
Yes, and my point is that you can already make those kinds o images with decent results if you do things manually. Automating the process might make it faster, but it won't generate better results than what good artists usually produce.