$12256 / $11500
Hi!
Got a bunch of sprites I'd like to tinker with palette swapping and was wondering if anyone knew of any good tools for that sort of thing?
In the past, I've just sort of done things by hand in the Gimp with a combination of 'select by color' followed by 'flood fill', but have enough images that I'd kind of like something a bit quicker this time.
The idea is simple, take an image with Palette A and create a new image with Palette A', where there is some way to manually specificy a mapping from each color in Palette A to a color in Palette A'.
Thinking specifically of something that allows you to see and set each color mapping individually, and let's you see an A and B version of the image, so you can easily see the mapping and how it affects the image.
Something like a panel showing:
Color A -> Color A'
Color B -> Color B'
Color C -> Color C'
....
plus a panel with: Image -> Image'
Did some googling and came up empty. I don't know if this is something people normally just do within their favorite editor, or if maybe this entire approach is wrong, but I figured I should ask on here before I start down the long and winding path of rolling my own tool for the job.
This website's content is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
I don't usually resurrect old threads but I found something highly relevant to this conversation. While trying to invent my own method of translating images using different color palettes I stumbled on this:
http://pixelatorapp.com/
You can read about it but I attached some screenshots of me using the tool doing a palette swap (in real time) on some tiles from OGA. It's a free tool and it's free to register/license for personal use.
Here are the palettes (use one of the PNG links to save the palette):
https://lospec.com/palette-list/dawnbringers-8-color
https://lospec.com/palette-list/dawnbringer-16
https://lospec.com/palette-list/dawnbringer-32
Here are the settings I used to generate these screen shots:
Pixelation
----------
Pixelation Factor: 1
Resize result to actual pixels: unchecked
Colors & Palette
----------------
Palette Type: From File
Palette File: (choose a PNG palette from above)
Saturation / Enhance: 0
Smoothing Filter
----------------
Smoothing Factor: 0
Smoothing Iterations: 1
Background
----------
Opacity Threshold: 250
Background Color: transparent
Outline
-------
Outline Type: None
@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.
It's using a nearest color algorithm. I spoke with the author briefly, it's still actively developed.
@withthelove
This is all your fault. Thank you. You're awesome for making the desktop program that inspired this.
@DawnBringer
I love your color palettes. I totally google searched your handle several times out of curiosity and found all your palettes on lospec (and promptly downloaded all for testing). Stay awesome.
@surt
Thank you for showing me GraphicsGale, that's an awesome tool I didn't know existed. I saw your mock-up work and I kind of took some direction from it but ultimately what I've made isn't done yet so it can still change.
@Sharm
We've worked together a little and you're awesome. Please give this a try.
@everyone else
I stumbled into this project by complete accident and had no intention of recreating something someone else already made. Next, this is in no way a competition. The previous comments and programs already mentioned/existing are quite good. I've lost track of all the stuff I had to learn and implement in this process so here's a link:
https://williamthompsonj.github.io/Color-Palette-Swapper/
I want your feedback. Comment, message, email, smoke signals, carrier pidgin, whatever. Give me your honest and brutal feedback.
This is still in beta stage but quite stable and usable. I have several controls that I haven't exposed to include:
- #hex->#hex mapping within the interface (copy/paste)
- Achromatic (gray scale) color detection tolerant
- Transparency detection tolerant
- Degrees of separation between hues when sorting (yes, it has a decent automatic color sorting algorithm!)
- Other things that escape me off the top of my head
Some specifications used in the creation process:
- sRGB translation into HSV, YIQ, YUV, CIA XYZ, CIA LAB color spaces
- CIE2000 color distance calculation (all like 17 pages of math it took to describe and the several hundreds of lines of code it required to recreate)
- Color sorting algorithm using HSV and perceived brightness
- A whole lot of math and learning
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.
Thanks for the kind words and feedback. This uses the CIE2000 color distance calculation
https://en.wikipedia.org/wiki/Color_difference#CIEDE2000
but I had trouble verifying it was producing completely accurate results (it's just slightly off when compared to online calculators). It seems to be mostly correct most of the time but sometimes (like with that white->yellow) it will grab a less-than-intuitive color match instead of an obvious match. I'll have to look at it to ensure it really is producing the results it should.
Color mapping is definitely an item of interest (by me). The GUI isn't built for it yet but it produces a #hex -> #hex conversion chart that generates correctly in the debug log. I've been having a great deal of fun putting in tile maps and loading different color palettes to see how it looks with new/different colors.
Hey this is the exact kind of thing I've been working on! Here's a web-based color converter that you can drag sprites to from your desktop.
Not only just color picking - it will automatically generate a suggested mapping that you can adjust with the "magic knob" - most of the sprites in my library look great with just the default setting. Here's some OGA recolors without any adjustment.
I was inspired by the VST Rectula to give it a sort of "toy" UI where you figure it out by playing with it. I tried to minimize text, to make it more useful for my friends who don't speak English.
https://repixel.app/
@williamthompsonj:
Drawbacks: (as far as I can see)
- can't be used in automated work flow with Makefiles etc.
- can't handle palettes with duplicate colors
- automatically sorted palette might be undesirable in certain situations
Feature ideas:
- loading palettes from lowspec
- importing/exporting .gpl (simple text file)
I wasn't able to check whether the swapped image is a paletted png, since the download does not work for me. It's just called `no_image_loaded`
EDIT:
Just remembered this little tool: https://github.com/PureAsbestos/Image-palettizer
EDIT2:
@laborious-rex:
Magic knob does not appear to work on firefox, it just makes the palettes shake.
Thanks for the feedback! I can add a sort of browser-based batch mode, or maybe in the future make a desktop build w/ electronjs
I'll look in to palettes from lowspec & gpl files. Palettes are generated row-by-row, left-to-right, from the image, so if you upload a file in this sort of format (see the db32 palette I attached) it should come in order.
I'll try to see if I can get downloading working for you. Which browser / OS are you using? Can you send me a screenshot of what you're seeing on your end?
Do you have any suggestions for palettes that I should add to the library?
(PS: I'm not sure what you mean by palettes with duplicate colors)
That feedback was meant for William.Thompsonj, I edited that apparently too late.
I overread your post at first and noticed later that my response could be misunderstood as being addressed at you.
The downloading problem and sorting does not apply to yours. But the magic knob issue does.
Even though those ideas could be implemented in yours too, indeed.
> Do you have any suggestions for palettes that I should add to the library?
Zoria (not on lowspec) https://opengameart.org/content/zoria-tileset
And maybe the original palette of LPC (neither on lowspec) https://lpc.opengameart.org/static/lpc-style-guide/styleguide.html
> I'm not sure what you mean by palettes with duplicate colors
In a paletted image each pixel stores the palette index instead of the color. And the palette then is made up of colors, there can be duplicate colors at different indices.
You might not be able to access palettes with JavaScript, at least I wasn't the last time, I tried.
I attached a little bit forced example. It uses a palette of 5 colors. Color #1 and #2 are both black, but #1 is the outline and #2 is the hair color. You can change hair color and outline color independently by changing the color value of those indices.
EDIT:
Added screenshot for palettes
Sweet, thank you for these suggestions Basto!
I just added the palettes you suggested.
I see what you mean now about the duplicate colors. Those might be a bit tricky to handle, since I want people to be able to generate palettes from sprites, too, but I'll see what I can do!
I'm pretty relieved to hear there's no problem with downloading :)
As requested, repixel now supports .gpl files! You can import using the "load from file" button in the palette browser, or you can just drag the .gpl file from your desktop onto the page :)
@LABORIOUS REX
That's another awesome tool, thank you for the comments. Interesting interface, reminds me of a game menu!
@Baŝto
Thank you for the feedback. Regarding not being able to save files, does it generate an error? Can you describe it in some way? Does palette extract work when you try to save? Very interested in this bug and will address first.
- command-line tool: it's very much web based and would be a good bit of work to convert so probably never doing that.
Things I plan to address:
- .gpl files: should be easy to implement
- paletted PNG: I haven't figured out how to generate a palette based PNG with Unity3D (yet) but it's on my list
- duplicate colors: internally it evaluates each color and only keeps the first one encountered.
- lospec palette loading: should be easy to implement (and I've seen that idea, I like this too!)
- sorted palette: I made this to extract palettes of existing images. I can expose a setting in the controls (once implemented) that allow the user to disable the sort algorithm and get a raw palette.
Once I get the CIE2000 color distance formula properly sorting I'll address the rest of these things.
@William Ah, I had been following this and skimming the replies, but somehow I missed that you had a new program that did similar things. Sorry about that! About your message, yes of course I remember you, no worries my friend. Unfortunately I wasn't able to get the linked program to work, my sad little lappy's screen is too small for the UI to fit on screen and when I tried to add the image I got a ? instead. It seems like a more hands off approach to palette swapping, which is cool but not as useful to me so I didn't try terribly hard to figure out what was causing the error. Maybe I added the wrong file type?
@LABORIOUS REX Wow! I really like the way you've handled the auto remap, especially with how easy it is to change it up if the results aren't ideal. The magic knob is presented in a really amusing way too. Because it can be fine tuned after, the auto remap is more useful than I'd originally thought, and saves me time on the setup. I think a way to zoom in and select colors from the image itself would be helpful. Sometimes it's hard to tell exactly which color is being the problem child from just the palette. The current palette loader looks nice, and I like the preview images, but finding exactly which one I'm looking for takes longer than I feel it should. Some sort of order would help, but I think it'll need some sort of overhaul if you intend to add more defaults.
@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.
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...
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, 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.
I love that you guys are helping each other do better, it's awesome. These different programs are getting me excited to work on my art again, so I can take advantage of these and play with them properly.
@Withthelove An updated version? How wonderful! I was convinced that the last version was going to be the end of it since it's been a while. I'm really looking forward to the ability to map differently for different sections, that would make things a lot easier on me when trying to convert a tile set. I was expecting having to cut it up myself then stitch it back together when I was done, but it's a lot of work that I was avoiding.
@withthelove:
You are right, there are different use cases.
I wrote a little tool for changing the palette in an indexed PNG a couple of months ago, since there was no software to be found that was capable of doing that.
-> https://github.com/basxto/loadgpl
Duplicate colors are supported. I sometimes use "subpalettes" in PNGs for different parts of the image, so I can shift them independently.
This tool is obviously not meant for switching to a completly different color palette, but to recolor something within the same palette.
This is nice if you want to create color variations, but also propagate pixel changes you make to the original.
I think one has to distinguish between palettes (DB16) which define all colors that could be used and palettes defined in an image (indexed PNG/BMP), which uses colors from the former, but can have duplicates to easy the automatic generation of color variations.
Ooh, updates for PPT!
Really there are only two features I could wish for - the first, as people have mentioned, would be a way to mask regions for different color palettes - for example, on the attached sprite character image, I would love to be able to mask out the face so the black and white pixels there were NOT swapped to the new palette.
The second feature would actually be a batch processing function. I ended up in a situation where I needed to swap several thousand very small sprite parts from one palette to another for a "paper doll" type program, and the only batch file palette tool I could find was this java applet:
https://github.com/SkyAphid/PaletteSwapper
And honestly ... it was buggy enough that it was only *slightly* better than doing it by hand in an image editing program. I expected to do touch-ups, but there was also a lot of rework I had to do on incorrect swaps.
@Sharm
Sorry for the large screen size. I changed it to 1280x720; I'm working on a decent resolution monitor so it's hard to tell exactly what looks normal now. Does 1280x720 work for your laptop screen? If not please let me know your preferred resolution and I'll scale it. I'm happy to use you as the target audience for tailoring some of these features.
@Sharm & @karmicRetribution
I'll look at how hard it is to setup bounded areas to remap palette colors (effectively making multiple work areas).
Throwing the URL out again for easy reference:
https://williamthompsonj.github.io/Color-Palette-Swapper/
@karmicRetribution
I found that exact same Java app and that's where I decided to build in a #hex -> #hex conversion feature (I thought that was a pretty good idea).
@Baŝto
Is this the normal file format for .gpl Gimp color palettes?
https://gist.github.com/dimaursu/9921467
Example:
[-----begin file-----]
GIMP Palette
Name: Web design
#
105 210 231 Giant Goldfish
167 219 219
224 228 204
243 134 48
250 105 0
255 255 255 separator
233 76 111 Cardsox
84 39 51
90 106 98
198 213 205
253 242 0
255 255 255 separator
[-----end of file-----]
I can implement that very quickly and without issue, that's just an sRGB table with a couple header lines.
I think so.
When I parse them I just skip to after the # line and parse the colors with regex '^\s*(\d{1,3})\s+(\d{1,3})\s+(\d{1,3}).*$'
mtPaint generates them like this:
GIMP Palette
Name: gb
Columns: 16
#
15 56 15 Untitled
48 98 48 Untitled
139 172 15 Untitled
155 188 15 Untitled
EDIT:
I don't even skip to #, I just use the regex. But I think I did the skipping in an older shell script.
@William
thanks! We have so many palette swap tools, now! That's good b/c it's the opposite of a problem :D
@Sharm
Glad you like the magic knob! A zoom would definitely improve the color-by-color swapping experience. I have zoom code somewhere that I might be able to port over, but it adds a fair bit of complexity. So that's a maybe on zoom? It would definitely improve the user experience, so that's a really good suggestion.
You can search palettes with ctrl+f. I should probably put some tips like this in a help box in the corner (because also, nobody who finds the app from outside OGA will know that it supports GPL files). Also, I could put the palettes in abc order.
@withthelove
Way to late for index support on my end I think! haha
Popup would be good for the palette browser. The first draft of the design had the palette browser bigger, in the middle of the app, b/c I wanted to encourage a sense of play. I realized late that people would want to edit the mapping on a color-by-color basis, so I had to wrangle that feature in there somewhere - it wound up being next to the palette browser, so now it's a bit crowded. (I wrote something like 5 versions of the mapping editor!)
I totally agree with you about bulk not being very useful. I think that sprites should be repaletted on a one-by-one basis, as the same color means different things when it's in a different place. Batch might be useful in a jam situation where your time is limited (one of the things I was thinking of with the auto-mapping). It's tempting to build the command line tool anyway, though... ;)
The magic knob is a combination of contrast and hue adjustment. One of the poles inverts the colors, which is sometimes handy when you're converting to a tiny palette. A little bit goes a long way :)
One of Lofus's favorite distortion VSTs is this one called Rectula (http://www.shuttlebugrecords.com/Pages/shuttleplugs.htm). None of the knobs have labels and they all adjust several parameters at once. I think it's a very fun design & wanted to play with that idea, so that's where the "magic knob" idea came from.
PS: I think I replied to everybody, but if there's anything I missed, please let me know!
-🦖
Made some updates, added a GIMP GPL color palette export button, changed the display filter mode to point so it doesn't smooth anymore.
https://williamthompsonj.github.io/Color-Palette-Swapper/
You all have been very busy! I have been watching this thread for a while. :) Il give some of these a go and give some feedback if you like?
Chasersgaming | Support | Monstropolis |
Tip for treating parts of the spritesheet differently:
I sometimes add new (duplicate) colors to the palette, then lock all colors in mtPaint but the one I want to replace, select an area and fill it with the new color. The image itself does not change, since I change only changed the used index, but not the associated color.
You can do that too. You could allow to select an area and then show all colors used in that area and allow the user to split off one of the colors. With that you would have duplicate colors in virtual palette, but the colors could have a different context.
And regaring CLI version:
Maybe you wanna take a look at my fork of https://github.com/basxto/Universal-Spritesheet-Character-Generator
It allows to change the palettes (hardcoded palettes for skin, clothes, metals etc.) both in the browser and in the terminal (node.js)
@Baŝto I know what you're talking about! It was a really common thing to be able to do in art programs back when everything was low colors. I remember using palette swapping to create animations as a kid. Mostly waterfalls. You can assign two spots with the same color in GIMP once the image is indexed, and I've been meaning to play with it a bit, but haven't gotten around to it yet. That really would be a great way to do a sprite recolor.
@William I'll check it out when I'm back on my computer. Currently on my phone, which isn't exactly useful for testing.
@Laborious Rex The knob is fun, but fine control is difficult with the mouse. Useage tips would be great, especially for key commands.
@Everyone Although batch processing won't be used often, for the people who would use it, it'd be a big deal. I think it's okay to keep it until last, but I don't think it should be thrown out entirely. It'd only be about once or twice, but I think I would use it.
I think batch processing is especially useful with stuff from open game art.
If you take assets and manually adapt them and the original submission gets updated, you'll have no benefit from that.
If you do it automated, you can just replace it with the updated version.
Switching to an extended version only works if it keeps the original format. Unless you also automatically change the tile format.
For characters the base and clothings should be seperated like in many LPC submissions, though. If that's not the case it won't work nicely, like it's the case with tiny16 since skin and hair share colors.
The naked guy would work, though. You should be easily able to switch from a dark skinned https://opengameart.org/content/tiny-16-basic to https://opengameart.org/content/tiny-16-expanded-character-sprites or https://opengameart.org/content/tiny-16-more-character-animations
@Baŝto
My apologies, I didn't understand what you were telling me with the error message earlier. Withthelove helped me work out a bug a little while ago and I noticed some very carefully crafted code that handles saving files was being cut out during build because of some macro stuff. Thank you for pointing out that bug.
@Everyone else
I fixed the download functions (and I tested to make sure it actually works this time!). Anyone with Linux or Mac please give my app a test to ensure it's working as expected.
@Sharm
Your Tiny16 sprites translate really well to Gameboy green.
Oh wow, they do! Probably because the original color count was so low. Maybe they'll show up in a GB Studio game.
@all:
Ok, color me convinced!
I've added a very simple command line mode to PixelPaletteTool.
The command line mode is limited to performing a single palette swap using a swap set file previously created and saved via the PixelPaletteTool GUI.
But if you are at all handy with make or shell scripting it shouldn't be a big deal to get it to work on an entire directory or more of files.
The general idea of the work flow would be to use the GUI to create a color swap set, save it and then use the command line tool to apply the swap set to multiple files.
Here's the usage statement for it:
usage: PixelPaletteTool.exe -i infile -o outfile -s swap_file
notes:
swap file should be a color swap file previously constructed in PixelPaletteTool GUI.
Running with no arguments will launch PixelPaletteTool GUI
The url to get it is still:
https://withthelove.itch.io/pixelpalettetool
BTW
PixelPaletteTool saves three types of files:
Images (png, etc)
'Color Swap Set' Files
'PixelPaletteTool Project' Files
You want the 'Color Swap Set' files, the buttons just to the left of the 'View' and zoom buttons. These files contain just the info for matching and replacing colors.
Project files contain the full details of your current session (image file, palette, all color swaps (maps)).
TBH, if you save a swap set and load it up in any text editor, the format should be pretty human readable and even editable if you are feeling ambitious.
If there are other operations that might be useful from the command line, let me know!
@Sharm:
No, those are too many colors.
Transparent is counted as a color, so it's using 5 colors.
But my demake of tiny16 explicitly targets cgb/dmg: https://opengameart.org/content/tinygb-characters
I haven't tested the newly added animations though. Couldn't get myself to implement character animation into my game yet. But the basic walking animation is unchanged.
I used black shadows on humanoid for cgb compatibility, since white is transparent, light grey is skin color and dark grey is clothing/hair color.
All characters in my game are from or based on tiny16, but the tileset is zoria.
@withthelove:
Sounds like a good workflow.
I think you'll need automatic color translation mostly for getting to your final palette translation, which then can be automatically applied.
@William The laptop I'm using is very outdated, and I think most people consider my resolution to be so old that being unsupported is normal. The main problem I have is that things aren't fitting vertically, at least not unless I'm full screen. The main problem with this is that I can't scroll upwards enough to get to the load image icon unless I'm at fullscreen or hit F11. BTW, after I opened the image, it kicked me out of fullscreen mode. I like the process used to pick which colors to remap to, it does a really good job. For many palettes I wouldn't need to do any editing at all, even when swapping to something with far fewer colors. I ran into the question mark error again, but I don't know what causes it yet. Maybe the file name was too long.
@withthelove Thanks! I don't mind a more involved process for something I won't use often, so I think it's a good solution.
@Baŝto Ah, I totally forgot about the 3 color sprite limit. I keep thinking that 4 is fine, since you can use 4 in the background. I'm old enough to remember making pixel art back when everything was indexed, you'd think I wouldn't forget something like that. I think you should try seeing how it looks when you remove the shadows, because then you can use the darkest shade for more than just outlines. It should free up a few more options on the sprites.
@Baŝto
That's a pretty cool looking demake of Tiny16! It makes sense that transparent counts as a color since the original GameBoy only has 2 bit color codes. I probably don't know enough about it but from my rough understanding the original Gameboy allowed up to 4 layers and each layer could have up to 4 colors. I think this is where you can get 3 shades of green + transparent. Since multiple layers allow a total of 4 shades of green it's still technically correct to say 4 shades of green + transparent are true to the original GameBoy palette. It's not the same hardware or layer restriction but it's more in the spirit of the thing.
@Sharm
I reduced the resolution to 1024 x 576 (with full screen support of course). If this is still not low enough resolution I don't know if I can design for it. Full screen should scale to your resolution so hopefully it works well enough. If you still can't see the full thing you can zoom out using control+mouse wheel.
@all
I added hex color import and export support. You can now import color palettes using PNG, Gimp GPL, and HEX codes in a text file (format is #abc123 -> #123abc). My next piece is working on a control panel to change settings that exist in the background so the user can change some of the automatic things, then I'm going to make a visual color mapper so users can manually map color a -> color b separate from auto-color mapping.
@all
Sorry for being overly chatty. In the process of making my online color palette swap tool I realized one of the most basic functions I use different pixel editor programs to do is turn a background transparent (most of the time I use Tiled, mapeditor.org). When I make the GUI color mapping function in my app it will have an option to turn a color transparent (all pixel editing tools should have this). I don't know why this simple function has become such a pain in the rump to find in modern pixel editor programs but I will do my part to reverse this trend!
As a side note, I will make hex mapping support 4 color HEX codes (meaning #ff33cc99, the 99 represents alpha transparency). Setting the last hex value below the alpha tolerance will suffice for turning a color transparent until I get a proper GUI for mapping within my app (you'll get to set that tolerance in the GUI).
@all:
Have released PixelPaletteTool v1.70.
This version adds a command for auto mapping colors to the command line and switches the auto color mapping algorithm from CIE76 to CIE2000.
Many, many thanks to William.Thomsonj for sharing me the code for CIE2000 color distance calculation.
@William.Thompsonj + all:
Since you bring up mapping a color (background color) to alpha 0, I do have another tool I've written that does this and a few other tricks. It's strictly a command line program and (so far) just something I wrote for myself to use internally but if it was useful for others I'd be happy to share it.
Here's the help statement for it:
PixelTool v3.4
usage: pixeltool -i infile -o outfile [command ...]
commands:
-c2a red green blue = set alpha 0 on matching pixels, alpha 255 for others
-outline = add black outline around alpha 255 pixels
-thick_outline = add black outline around alpha 255 pixels (thicker)
-edge = set color of alpha 0 pixels to avg of surrounding alpha != 0 pixels
-regrid w h new_w new_h = respaces image (useful for grid of sprites)
-split w h = split image, 1 new image per grid square, image files named outfile1x1, outfile1x2, outfile2x1, etc.
-skip_empty = skip (don't save) empty images when splitting an image
-fill_color red gree blue alpha = specify color used to replace c2a pixels with and/or fill regrid image with before copying grid pixels
-dim width height = specify width, height of output image
-depth 24|32 = specify bit depth for output image
-palettize = output image is pallete of unique colors found in image (or all images in dir, if given a dir)
The difference between regular (thin) outlines and thick outlines is that thick outline checks /diagonally/ adjacent pixels instead of just up, down, left, right pixels.
The purpose of edge is to get the edges of a sprite/image to blur correctly when using bi-linear (or other) filtering. Classic hardware bilinear filtering just blends all adjacent colors independent of their alpha values. So color from the invisible pixels around your sprite will get bleed into the edges of your sprite if it is scaled or rotated. The '-edge' routine solves this problem by filling transparent pixels with color values from nearby visible pixels. This way the transparent pixels around the edge of a sprite are the same color as the edge of the sprite.
Does this stuff sound useful to anyone out there?
If there is interest, would folks rather see this released as it's own tool or should I just pack these functions into PixelPaletteTool's existing command line interface?
@withthelove
You're welcome. If anyone else wants it I'm happy to share. I'll put my c# project files with my app that get uploaded to github so it's easy for anyone to find. It was a bit of work to get working but it works really well so happy to share.
My 2 cents: if it's available on the command line it's probably worth having available in the GUI. I strive to make all functions self documenting and available through the GUI unless I'm making a command line application.
Added a settings window to my app. Next milestone is adding a manual color picker/mapper window that allows defining custom colors/changing colors of imported palettes. Once this is done it's the official version 1.0 release and I'm posting the source with the project on GitHub. If anyone wants any other significant features please let me know.
https://williamthompsonj.github.io/Color-Palette-Swapper/
@withthelove
Got the GUI together for my color palette swapper. Let me know what you think of the interface and the function.
@William.Thompsonj: Yay! The manual swapping interface definitely gets the job done.
Some thoughts:
1) The manual swap interface pops up over and partially obscures the image. This can make it tough to see the impact of your color selections. For example, what if the color you are swapping is mainly used in the obscured portion of the image?
Consider moving and/or resizing the interface so it doesn't obscure the image so much. For example, it could be made simultaneously wider and shorter and moved down. Or it could be made a free-floating window so users could move it about as needed.
2) Having to click 'apply' every time you change a swap color is cumbersome. I suggest just having the swap take effect immediately but maybe have an 'undo' button (something PPT lacks) so you can easily roll back a change you don't like.
3) The load/save icons seem out of order to me. I would group them either by function (load/save) or by target (image/palette). As it is, the first icon is to load an image, the second is to save a palette, which is confusing to me.
4) 'Add Color' is an awesome feature and one that's still missing from PPT. :)
Feature requests:
Some way displays all the current color swaps. Actually having the swaps permanently displayed somewhere would be best. I find it helpful for a lot of reasons, not least of which is checking to see if I've already used a particular color in another swap.
Some way to manually sort the colors in the manual palette swap interface. This is big help when working with color ranges.
Some way to zoom/pan around the image. Sometimes a color is only used in a small part of the image (ex. a color used for shadows in a single sprite on a larger sprite sheet) so it's nice to be able to zoom in and look at the specific area you are working on.
Some way to load/save not the image or the palette but the swap data (eg. aa55ff -> cc77ee, etc.). This would allow one to apply the same swaps to multiple images and also be handy for saving your current state and returning to later.
@withthelove
1. Menu interfaces pop up over and partially obscure the preview image.
Agreed. Added window dragging. Click anywhere that's not an input field or checkbox and drag the window where you like and it remembers the last place you place it for convenience.
2. Click 'apply' every color swap is cumbersome.
Agreed. Made the preview auto-swap colors and added an undo button in place of the apply button. It undoes color changes and removes colors added.
3. Buttons on the main window are out of order, workflow is not intuitive.
Agreed. Reordered buttons on the main window and added description text to (hopefully) make the interface more intuitive.
4. Thanks :)
#. Hex palette swap data
There's are two buttons to load/save palette swap data as a hex text file. It supports:
- hex mapping (#rrggbbaa -> #rrggbbaa)
- list of colors in hex format separated one color per line
- mixed format (hex mapping one line, single hex color next line)
- auto-map lists of colors
- comments (starting with //) at the end of a hex color / mapping line or on a separate line
- ignores extra line breaks
@withthelove
You have good ideas and advice so I did some more of those features. It now has the capability to zoom/pan and the zoom buttons are visible when doing color swapping. This tool is becoming a lot more interesting every day!
Looking good!
Some more thoughts:
The move should move both images, so the views are always synchronized.
Maybe I'm wrong about that, but I can't think of a time when I would want to look at one part of the source image and different part of the destination image.
Any hope of getting the mouse wheel to zoom in/out?
BMP exports plus RPG default palettes for those BMP files would be a good addition i think. Would appeal to homebrew i reckon. :)
Chasersgaming | Support | Monstropolis |
@all
While testing with Bjorn (author of Tiled, www.mapeditor.org), he presented me with some crazy test cases that bent my brain and forced me to learn parallel thread processing in C#. What a learning experience! My tool now utilizes all available processors and threads! I also had to refactor a large portion of code to reduce memory heap size because it was running out of memory with large images. Should see improved loading and performance.
@withthelove
Got the two preview images to sync position. If you drag one the other will follow. I'll look at the mouse wheel zoom because I had the same thought but didn't act on it.
@chasergaming
I looked at BMP import/export briefly, that may be easy enough to implement but I'll have to rework the buttons again to make everything fit.
After significant testing and refactoring with Bjorn (author of Tiled, www.mapeditor.org) we determined C# does a lot of boxing of variables and crazy nonsense. You can now load PNG and nearly any variant of JPEG and do color palette translations from PNG, JPEG, GPL, or text based HEX mapping files.
@chasergaming
Loading a BMP is an easy idea but somehow the BMP File Format
https://en.wikipedia.org/wiki/BMP_file_format
is not well supported outside Windows so Unity doesn't support it well either. I'll keep looking but for now it's still not supported.
No worries matey. was only a suggestion anyways. keep up the good work! :)
Chasersgaming | Support | Monstropolis |
@chasersgaming
Added BMP reader support (does not allow saving as BMP but will load correctly). Also found some tools for GIF, may try to implement those (they support animated GIF too!).
Pages