ok, just to keep rambling here while I'm on a tear...
The main fill color for the slime highlights the challenge I was talking about earlier with using one mapping for an image with multiple different characters on it.
My CLIE algo seems to have made an odd choice for this color, opting for a slightly darker green instead of the yellow or the bright green in DB32 either of which would seem like better fits for a slime. But if you play around with the mapping a bit, you'll see that that color is actually used in a few other places around the image. Specifically, it's used for a highlight in the hair and scalp on the other characters. In those cases, choosing a green would be very odd and even the bright yellow is kind of problematic. Personally, I found the bright flesh tone (#EEC93A) to work best for the hair highlight and either the yellow or the off white (#CBDBFC) to work best for the scalp. So again, this just highlights the limits of trying to use one mapping for multiple different sprites or images.
here's a preview image of Pixel Palette Tool v1.6 showing the mapping my CIE distance maths chose for mapping Tiny16 Basic to DB32.
also:
@William.Thompsonj: One more comment for you, the preview images should be displayed with any texture filtering turned off. They look to be bilinear filtered on my display. Assuming we're dealing with mainly pixel art, 'nearest' or no filtering is what you want.
How awesome! When I started this thread I couldn't find any programs that specifically addressed this issue, now we have several to choose from! :)
@LABORIOUS REX & William.Thompsonj:
I have some general feedback and some specific feedback for you both.
Let me preface my comments by saying that my thoughts and opinions are obviously colored by have written and used Pixel Palette Tool for some time now. So take my comments with a grain of salt and also please don't let me steer you into just duplicating Pixel Palette Tool. I can only offer you my observations and suggestions based on my experience with Pixel Palette Tool but it's important that you follow your own muse and come up with your own solutions.
First, if you look back in this thread you'll see there are two use cases for a tool like this:
1) Converting an image/sprite/etc from one palette to another
2) Re-coloring an image/sprite/etc from one color range to another w/in the same palette (eg. making a 'red' version of an enemy, or an 'ice' version of a tile, etc)
Both your tools seem focused on the first case, but don't forget the second. In my experience, it is actually the most common use case. I might convert an image from one palette to another every so often, but I am constantly wanting to shift colors around to create new tile/sprite variants.
Regarding batch and/or command line processing, it doesn't seem like either of you are headed down that path anyways, but let me just say that this was on my list for Pixel Palette Tool and still technically is, but in several years of using the program, I have yet to encounter a case where I really wanted to do any batch/bulk or command line based palette swapping. Originally, I thought it would be very handy to come up with some general mapping between palettes, like say from NES to SMS or NES to DB32 or something, and then be able to just quickly apply that mapping to a bunch of images. But as time has gone by, I have just never ended up wanting to do that. In the end, I think just blanket mapping colors from one palette to another doesn't end up being very useful because it doesn't take into account the context around how each color is used in each image or sprite. Especially with low color palettes, artists are always using colors in novel and inventive ways so the choices you make for mapping colors in one image aren't always helpful with the next image.
Just a heads up, and it's probably too late for this one, but be careful how you architect things upfront or adding index palette support is going to be tricky indeed. This is definitely a mistake I've made with Pixel Palette Tool. The code is based around the idea of mapping one RGB value to another. I've taken the first few steps towards supporting an index based mapping concept but it's definitely something of a paradigm shift and would have been much easier to support if I'd planned for it ahead of time.
Regarding color sorting. This is a feature I hadn't really considered when I starting working on Pixel Palette Tool, but after some time using it, I can say, having the ability to manually sort and re-arrange the palette on screen is really, really useful. An image invariably uses the colors in the palette in some sort of 'range' or 'ramp' formation (eg. from highlight to shadow), and being able to arrange the palette into those formations really helps.
Finally, by far and away the biggest feature I've found myself wanting again and again in Pixel Palette Tool is one suggested by surt earlier in this thread: the ability to set different color mappings for different sub-sections of an image. If you have an image that's one image or one sprite, it's not too big a deal. But if you are working with a tile sheet or sprite sheet with multiple different characters on it, it's really common for different colors to be used differently across the different tiles or characters. And so having a way to divide the image up and use different mappings for the different sections would be very useful.
TBH the only thing that's kept me from adding this feature has been coming up with a good, simple way to handle the UI for it. surt's mock above actually does a good job of it, but Pixel Palette Tool's UI is more primitive and I haven't been able to dream up a way to easily kludge in support for sub-sections.
@William.Thompsonj:
Definitely having some way to manually tweak the mapping is a must. You only have to try a few images to see the limits of strictly using an auto-mapping. Although, I'll admit, I've had a good bit of fun trying different tile sets out too!
Regarding my previous comment, I have gone ahead and implemented a CIE distance based 'auto map' feature in Pixel Palette Tool (will post new build shortly) and whatever the monkey code I've written is, it does pick the white instead of the yellow for mapping the ghost and skeleton 'white' in Sharm's 'Tiny16 - Basic' from DB16 to DB32. I don't want to bore everyone here with the details, but if you PM me, I am more than happy to share the code with you. At the very least, comparing it with the maths in your code might help you spot what's going on.
@LABOURIOUS REX:
what on earth does the magic knob do? TBH more often than not it just seems to produce garbage results for me. Also, I notice if I slide it to the left far enough, the color mapping bar disappears, attaching a pic of what I mean.
Some UI things:
The palette selector actually takes up an inordinate amount of space in the UI. You only select the palette at the start of doing a conversion, so maybe consider making it a pop up window. That said, showing the preview bars next to the palettes is a very nice touch! :)
Tilting things to indicate which image you are hovered over works ok, but tilting the palette strip when you go to manually select a color mapping is annoying.
Using the selected color as the background for the color editing window (if you click on a color in the palette above the images) is a cool idea, but it doesn't always work if the color is too close to the font color (light grey). I had particular trouble with the NES yellow.
Don't worry at all about competing with my goofy app. The more minds we have tackling this challenge the better!
Already I can say your proggy feels smoother to use than mine. Pixel Palette Tool always gives me flashbacks to my Amiga days but what can I say? I grew up on those Amiga GUIs so when I close my eyes and picture how an interface should look and work it's really hard not to end up with something akin to Dpaint IV. :)
I totally feel you on those color space and distance maths. Been down that road myself a few times and it is indeed a long and winding road, kudos to you for making through! :)
Does this strictly use the CIE2000 color distance calculation to pick the color swaps?
The choice of mapping for the Ghost's white seems very off.
white -> yellow?
DB32 has a pure white and a light blue (#cbdbfc) either of which seem like they would be a better match. Although, I do see where DB16's white has a slightly yellow hue to it so maybe that's what's steering the algo toward the full yellow instead of the pure white or the light blue. It's even possible the yellow is a better match all else being equal, but having the broader context that it's being used in a ghost sprite makes the white or the light blue a more natural fit.
It would be great to see the color mapping and possibly edit it as well, although I hesitate to suggest that because that's basically what Pixel Palette Tool is and I don't want to push you into just doing the same thing I've done. Not because I'm worried you'll do it better (I'd actually be hoping you did! ;) but rather because I don't want to steer you away from your own ideas about what's useful and how such a program should work.
@William.Thompsonj: No worries about opening an old thread, this is one of those threads that's meant to come alive again from time to time. :)
So in those screenshots, have you specified the mapping from one palette to another or is pixelator creating the mapping for you based on some kind of 'nearest color' match algorithm?
It certainly gives me an idea of a feature to add to 'Pixel Palette Tool'. I actually have some code sitting around that will do 'nearest color' matching between palettes based on a few different heuristics. PPT is kind of geared around manually picking the color mappings, but it might be useful to have a button that could auto-populate the mappings based on some 'nearest color' algorithm.
Tuesday, May 12, 2020 - 18:27
@Cougarmint: Hope I gave you an ok credit for the idea in the official Challenge post:
ok, just to keep rambling here while I'm on a tear...
The main fill color for the slime highlights the challenge I was talking about earlier with using one mapping for an image with multiple different characters on it.
My CLIE algo seems to have made an odd choice for this color, opting for a slightly darker green instead of the yellow or the bright green in DB32 either of which would seem like better fits for a slime. But if you play around with the mapping a bit, you'll see that that color is actually used in a few other places around the image. Specifically, it's used for a highlight in the hair and scalp on the other characters. In those cases, choosing a green would be very odd and even the bright yellow is kind of problematic. Personally, I found the bright flesh tone (#EEC93A) to work best for the hair highlight and either the yellow or the off white (#CBDBFC) to work best for the scalp. So again, this just highlights the limits of trying to use one mapping for multiple different sprites or images.
here's a preview image of Pixel Palette Tool v1.6 showing the mapping my CIE distance maths chose for mapping Tiny16 Basic to DB32.
also:
@William.Thompsonj: One more comment for you, the preview images should be displayed with any texture filtering turned off. They look to be bilinear filtered on my display. Assuming we're dealing with mainly pixel art, 'nearest' or no filtering is what you want.
ok, you know I couldn't stay out of this fun, so Pixel Palette Tool officially has an auto-map button now too!
https://withthelove.itch.io/pixelpalettetool
it only maps the colors that aren't already mapped. Not sure if that's how it should work or not, but that seemed the best route at first thought...
it uses CIE color distance, does seem to make some odd choices at times, so perhaps my CIE maths are the ones that are incorrect...
@all:
How awesome! When I started this thread I couldn't find any programs that specifically addressed this issue, now we have several to choose from! :)
@LABORIOUS REX & William.Thompsonj:
I have some general feedback and some specific feedback for you both.
Let me preface my comments by saying that my thoughts and opinions are obviously colored by have written and used Pixel Palette Tool for some time now. So take my comments with a grain of salt and also please don't let me steer you into just duplicating Pixel Palette Tool. I can only offer you my observations and suggestions based on my experience with Pixel Palette Tool but it's important that you follow your own muse and come up with your own solutions.
First, if you look back in this thread you'll see there are two use cases for a tool like this:
1) Converting an image/sprite/etc from one palette to another
2) Re-coloring an image/sprite/etc from one color range to another w/in the same palette (eg. making a 'red' version of an enemy, or an 'ice' version of a tile, etc)
Both your tools seem focused on the first case, but don't forget the second. In my experience, it is actually the most common use case. I might convert an image from one palette to another every so often, but I am constantly wanting to shift colors around to create new tile/sprite variants.
Regarding batch and/or command line processing, it doesn't seem like either of you are headed down that path anyways, but let me just say that this was on my list for Pixel Palette Tool and still technically is, but in several years of using the program, I have yet to encounter a case where I really wanted to do any batch/bulk or command line based palette swapping. Originally, I thought it would be very handy to come up with some general mapping between palettes, like say from NES to SMS or NES to DB32 or something, and then be able to just quickly apply that mapping to a bunch of images. But as time has gone by, I have just never ended up wanting to do that. In the end, I think just blanket mapping colors from one palette to another doesn't end up being very useful because it doesn't take into account the context around how each color is used in each image or sprite. Especially with low color palettes, artists are always using colors in novel and inventive ways so the choices you make for mapping colors in one image aren't always helpful with the next image.
Just a heads up, and it's probably too late for this one, but be careful how you architect things upfront or adding index palette support is going to be tricky indeed. This is definitely a mistake I've made with Pixel Palette Tool. The code is based around the idea of mapping one RGB value to another. I've taken the first few steps towards supporting an index based mapping concept but it's definitely something of a paradigm shift and would have been much easier to support if I'd planned for it ahead of time.
Regarding color sorting. This is a feature I hadn't really considered when I starting working on Pixel Palette Tool, but after some time using it, I can say, having the ability to manually sort and re-arrange the palette on screen is really, really useful. An image invariably uses the colors in the palette in some sort of 'range' or 'ramp' formation (eg. from highlight to shadow), and being able to arrange the palette into those formations really helps.
Finally, by far and away the biggest feature I've found myself wanting again and again in Pixel Palette Tool is one suggested by surt earlier in this thread: the ability to set different color mappings for different sub-sections of an image. If you have an image that's one image or one sprite, it's not too big a deal. But if you are working with a tile sheet or sprite sheet with multiple different characters on it, it's really common for different colors to be used differently across the different tiles or characters. And so having a way to divide the image up and use different mappings for the different sections would be very useful.
TBH the only thing that's kept me from adding this feature has been coming up with a good, simple way to handle the UI for it. surt's mock above actually does a good job of it, but Pixel Palette Tool's UI is more primitive and I haven't been able to dream up a way to easily kludge in support for sub-sections.
@William.Thompsonj:
Definitely having some way to manually tweak the mapping is a must. You only have to try a few images to see the limits of strictly using an auto-mapping. Although, I'll admit, I've had a good bit of fun trying different tile sets out too!
Regarding my previous comment, I have gone ahead and implemented a CIE distance based 'auto map' feature in Pixel Palette Tool (will post new build shortly) and whatever the monkey code I've written is, it does pick the white instead of the yellow for mapping the ghost and skeleton 'white' in Sharm's 'Tiny16 - Basic' from DB16 to DB32. I don't want to bore everyone here with the details, but if you PM me, I am more than happy to share the code with you. At the very least, comparing it with the maths in your code might help you spot what's going on.
@LABOURIOUS REX:
what on earth does the magic knob do? TBH more often than not it just seems to produce garbage results for me. Also, I notice if I slide it to the left far enough, the color mapping bar disappears, attaching a pic of what I mean.
Some UI things:
The palette selector actually takes up an inordinate amount of space in the UI. You only select the palette at the start of doing a conversion, so maybe consider making it a pop up window. That said, showing the preview bars next to the palettes is a very nice touch! :)
Tilting things to indicate which image you are hovered over works ok, but tilting the palette strip when you go to manually select a color mapping is annoying.
Using the selected color as the background for the color editing window (if you click on a color in the palette above the images) is a cool idea, but it doesn't always work if the color is too close to the font color (light grey). I had particular trouble with the NES yellow.
Awesome work!
Don't worry at all about competing with my goofy app. The more minds we have tackling this challenge the better!
Already I can say your proggy feels smoother to use than mine. Pixel Palette Tool always gives me flashbacks to my Amiga days but what can I say? I grew up on those Amiga GUIs so when I close my eyes and picture how an interface should look and work it's really hard not to end up with something akin to Dpaint IV. :)
I totally feel you on those color space and distance maths. Been down that road myself a few times and it is indeed a long and winding road, kudos to you for making through! :)
Does this strictly use the CIE2000 color distance calculation to pick the color swaps?
The choice of mapping for the Ghost's white seems very off.
white -> yellow?
DB32 has a pure white and a light blue (#cbdbfc) either of which seem like they would be a better match. Although, I do see where DB16's white has a slightly yellow hue to it so maybe that's what's steering the algo toward the full yellow instead of the pure white or the light blue. It's even possible the yellow is a better match all else being equal, but having the broader context that it's being used in a ghost sprite makes the white or the light blue a more natural fit.
It would be great to see the color mapping and possibly edit it as well, although I hesitate to suggest that because that's basically what Pixel Palette Tool is and I don't want to push you into just doing the same thing I've done. Not because I'm worried you'll do it better (I'd actually be hoping you did! ;) but rather because I don't want to steer you away from your own ideas about what's useful and how such a program should work.
@FaninhoSC: You got the idea right! 'Flip Left Duel' cabinet looks great!
@William.Thompsonj: No worries about opening an old thread, this is one of those threads that's meant to come alive again from time to time. :)
So in those screenshots, have you specified the mapping from one palette to another or is pixelator creating the mapping for you based on some kind of 'nearest color' match algorithm?
It certainly gives me an idea of a feature to add to 'Pixel Palette Tool'. I actually have some code sitting around that will do 'nearest color' matching between palettes based on a few different heuristics. PPT is kind of geared around manually picking the color mappings, but it might be useful to have a button that could auto-populate the mappings based on some 'nearest color' algorithm.
@Cougarmint: Hope I gave you an ok credit for the idea in the official Challenge post:
https://opengameart.org/forumtopic/june-2020-art-challenge-south-paw-pride
Hi all!
Just wanted to let folks know that I just queued up a bunch of art challenges for the coming months including:
Hobbies
Monster Village
Urban Legends
South Paw Pride
and
My Favorite Palette
Thanks for all the great ideas!
There are many more challenges to come so hopefully we can work through all the great theme ideas folks have shared.
Hi all!
Just wanted to let folks know that I just queued up a bunch of art challenges for the coming months including:
Hobbies
Monster Village
Urban Legends
South Paw Pride
and
My Favorite Palette
Thanks for all the great ideas!
Pages