As you said it gets a bit long to process everything when there are many colors. I noticed many results are not relevant, just as images lacking contrast making the sprites not “readable”.
Maybe there could be an option to only try a palette color on an initial color with a similar level of brightness? This would preserve brightness contrast (although not hue contrast).
Then we could have another option to make sure that the same color is never used twice, assuming the palette has at least as many colors as the original image.
We could also have a special case where palette colors = initial image colors: in this mode, you only need to input one image. Then it effectively does a color permutation, in the sense that it remaps every color to some color in the initial image, bijectively (two different colors map to two different colors; and since the initial and target number of colors is the same, we also cover all colors in the final image).
"Then we could have another option to make sure that the same color is never used twice, assuming the palette has at least as many colors as the original image."
This is what the "no color re-use" checkbox does.
I have been thinking about treating different brightness levels (shadows, specular highlights) as being the same color, and mapping them to brightness levels of another color (just like in the procedural tileset generator palettes). The problem I encountered was how to objectively determine what colors are part of the same material in the original image. Do you treat neighboring pixels as being the same material?
This tool was created a few years ago before I discovered L.A.B and made the procedural tileset generator. I may take another look at this issue to improve the tool.
← Return to tool
Comments
Log in with itch.io to leave a comment.
It’s nice!
I had a few issues when using it though:
As you said it gets a bit long to process everything when there are many colors. I noticed many results are not relevant, just as images lacking contrast making the sprites not “readable”.
Maybe there could be an option to only try a palette color on an initial color with a similar level of brightness? This would preserve brightness contrast (although not hue contrast).
Then we could have another option to make sure that the same color is never used twice, assuming the palette has at least as many colors as the original image.
We could also have a special case where palette colors = initial image colors: in this mode, you only need to input one image. Then it effectively does a color permutation, in the sense that it remaps every color to some color in the initial image, bijectively (two different colors map to two different colors; and since the initial and target number of colors is the same, we also cover all colors in the final image).
"Then we could have another option to make sure that the same color is never used twice, assuming the palette has at least as many colors as the original image."
This is what the "no color re-use" checkbox does.I have been thinking about treating different brightness levels (shadows, specular highlights) as being the same color, and mapping them to brightness levels of another color (just like in the procedural tileset generator palettes). The problem I encountered was how to objectively determine what colors are part of the same material in the original image. Do you treat neighboring pixels as being the same material?
This tool was created a few years ago before I discovered L.A.B and made the procedural tileset generator. I may take another look at this issue to improve the tool.
Ah, I didn’t see the checkbox, and it works! It was too slow to test with many colors but I could check it with 4 -> 4 colors.
I didn’t know about CIELAB, sounds useful to ensure perceptible contrast indeed. I’ll check out your other tools!