> Something that probably wouldn't be easy but would also be useful would if I could export a single image with multiple color change options. ... For example, a sprite with blond hair exported quickly into sprites with red, brown, black, and gray.
Currently the tool supports exporting multiple color changes but they are all appended into a single file.
So it's:
Source Image -> Many Color Changes -> Single Destination Image (color changes stacked vertically)
If I understand you correctly, you'd be looking to go:
Source Image -> Many Color Changes -> Many Destination Images (one image per color change)
Batch processing is definitely in the works, and for exactly the scenario you are describing: Setup a color mapping, save it out, then apply to multiple images (or apply multiple mappings to a single image). Before I get too far with it, is a command line interface ok for you? That's always how I do my batch stuff but I can look into a GUI interface if folks don't like using the command line.
> I haven't tested out the program you have so far (not currently on my computer) but I'm excited to. Thanks for this!
If you get to running it, any feedback is definitely welcome! Even if it's just that you hate it! ;)
@dawnbringer:
> The indexed palette is in the analyzis, but I have now made it clearer and labelled.
Thanks! It looks great! Label definitely makes all the difference. I would not have guessed that what's that section was, although in hindsight it's kinda obvious.
> if you're interested, you can beta-test v1.4.
Sign me up!! Sounds amazing! Is there a public link for the beta version or is it invite only?
> hypothetically possible to script your own interface, if one doesn't mind the busy-pointer showing while a script is running
Gotcha, thanks for the 411. 'hypothetically' is defnitely the part that scares me. I don't want to get stuck killing myself trying to trick a scripting system into doing something it fundamentally isn't designed for. Still, as I've previously noted, I see major upsides to implementing the idea within the context of an exisiting image editor. That's sort of the conundrum of it.
> I haven't seen much suggested in this thread that couldn't already be done in seconds with GrafX2 built-in features
Thanks for all the pointers! Using the spare actually works pretty well and gets close to my original goal. It's basically as simple as load the image, copy it to the spare, muck around with the palette, flipping back and forth between original and spare to see changes.
Is there a way to load/save add palettes in Grafx2? I couldn't see an obvious way to do it and googling around came up empty.
> F.ex let's say you wanna try variations on a 16-color sprite
I went ahead and tried this and you're right, it totally works!
It seemed a bit tedious at first, but then I realized you could just drag and select all 16 colors to copy at once. That helps alot!
Again thanks for the suggetions. I grew up on Dpaint IV so Grafx2 is right up my alley. Unfortunately, after spending years learning the Gimp, I never been able to justify the effort needed to re-train my brain for a different editor, so this has been a good excuse to spend some time getting to know Grafx2 a bit better.
@all: I took a bit of pause on development over the last few days to spend some time actually using the new tool for some palette work. I figured that was way to figure out what works and what doesn't. Here are my own thoughts so far:
1) I do like it! I know it's tooting my own horn, but for the very specific problem I was trying to address I think it works really well. It's not just that it does the job, but that it's really simple and fast to use. It has got to be just about the fewest clicks possible to do the job. Click source color, Click replacement color. Don't like, click a different replacement color. It makes auditioning different colors and schemes very easy.
I have a huge pile of tile sprites for the game I'm currently working on and after adding/removing/changing things ad-hoc for far too long, I've undertaken a project to review everything, rationalize it and organize it. So far the tool has proven to be a surprisingly big help with this. By 'rationalize it', I mean going through and making sure each area of the game uses tiles that are distinct. Obviously, artistically they are all unique already, but the tool has proven pretty handy for making sure they're all chromatically unique too. I'm struggling to find the words to describe it, but it's a lot of stuff like 'make sure the swampy area uses dark greens and the sunny area uses brighter greens' I know that sounds a bit obvious and something that should be baked into the art to begin with, but I guess what I'm doing is going back and reviewing everything from a 50,000 foot perspective and saying 'ok, how many dark green areas do I have? are there too many? are these two dark green areas too similar? should I go back and recolor something so the two areas are more distinct?' Having a tool that can quickly swap colors around has proved pretty handy. I've even had a few cases where I got into the tool, fiddled a bit and realized I could totally repurpose something just by recoloring it and moving it to a different area.
2) Being able to quickly create/work on/switch between multiple re-mappings at once is very handy. I find myself making some changes, hitting 'Clone' and then making some more. So I'm sort of iterating through different options, using the previous mapping as the starting point for the next. When I'm done, I go back through and keep the best options and toss the rest.
3) Showing just the colors that are being changed is also very handy.
So thanks very much to surt for pushing both of those ideas!
4) 'picking the index from the preview' would definitley be very nice! Had always intended to add that but now am a bit ashamed I didn't deem it essential as it's definitely a pain to work with out it.
5) Needs a 'Load/Save Project' feature. Something that saves the entire current state (src image, palette, and all color mappings) and let's you load it back in later. Bascially, so you can quit the app and pickup again where you left off later.
Quick question for the gang about this. My initial thought is to implement this as a simple text file that just records the location the the source image and palette (c:\my stuff\picture.png, etc) and a list of all the current color maps. Does anyone see a good reason to try and imbed the images and palettes into the project file? Seems like a hassle and a waste of space to me, but it would technically make the project files more portable.
Some bug notes:
No idea why it's window seems to stop responding to move and resize clicks sometimes. Clicking around on some other windows and then back to the tool does seem to fix it though. I suspect this bug has something to do with SDL and the built in windows file browser dialogues not playing nice together. Will do my best to sort it out.
Definitely chugs power on my laptop! Apologies to other laptop users out there! This largely an artifact of the tool using my game engine, meaning the rendering is done with OpenGL and the core loop is pretty much always trying to run at full throttle, even though 90% the app is going nothing and could probably get away without even updating the screen. Will definitely take a poke at what might be done to make it smarter about this but no promises.
My current 'to-do' list, in rough prioirty order, or at least in the order I was figuring to tackle them (some being larger undertakings than others):
select color from preview
zoom/pan in preview
toggle to load palette with image
load/save project
basic command line batch processing
palette modify/add/edit
index palette support (displaying palette as indexed in image file)
@dawnbringer: i have v1.3 of the toolkit, is that the current release? The analysis my version produces is missing all the labels, which are very handy indeed! :)
One thought for your script, if possible it'd be nice to see a copy of the palette in it's original (index) order somewhere. Perhaps along the top or bottom? I find the analysis great for suggesting ramps, etc. but I frequently end up going back to source file (typically just a grid of swarches) when I want to pick an individual color. I guess it's just that there's typically some kind of manual ordering to the original palette indices that's useful. Also, I won't lie, that'd also be very handy for my little pet project to bring a bunch of standard palettes to OGA as I could just post a copy of the analysis, instead of the analysis plus a copy of the original palette swatches.
Since you have extensive experience with Grafx scripting, do you think something like this color swapping tool would be possible to implement with Grafx LUA scripts? I'd definitely be willing to give writing a script for it a go if it seemed like something in realm of what the scripting system was designed to handle.
ps
your palettes deserve more than a web site, they deserve a shrine!! :)
Gotcha, I think this will come in naturally with index palette support.
Also, yeah, they'll either be a toggle for flipping between mapping by index or by RGB value, or it will be automatically set based on the format of the source file. or both...
Friday, July 14, 2017 - 19:52
> Runs fine in Wine with the exception of file dialogs appearing behing the main window.
hey, that's not bad! It's actually using OpenGL 3.0 for all the rendering so double good on Wine that it works!
> If you don't work with indices then you can't really work with images with subpalettes (NES, SMS, MD, GBC, etc.)
Is there a particular image file format that does this sort of thing?
My vision was: if you want to work with NES, SMS, etc. just load up that palette and have at it.
But then I generally work in full 24bit and save as PNG files. I use palettes as a source for colors but I don't actually formally use them within an image editor very often. But I think that's also partly an artifact of the fact that I use GIMP and it's index palette toolset is just 'Ok'.
> I figured picking the index from the preview was a given.
> Large image is scaled to less than 1x so I can't see individual pixels. Being able to freely zoom and pan preview is a must.
Yeah, both on the to-do list. If you didn't try already, you can resize the window to enlarge the preview. Not the same as being able to zoom about but might help until that stuff's done.
> Be nice is there was an option to use the target palette as the destination palette when an image is loaded so it doesn't need to be loaded again seperately.
Yup, also on the to-do list.
thanks for giving it a try! Let me know any other comments that pop into your head!
oh I should also add that it currently displays the RGBA values for the selected color and it's mapping over on the top right of the tool bar. This is kind of a debug feature, it will be replaced by the proper color editing tools when those come in. But for now it at least gives you a way to verify the colors are coming in correctly and can be somewhat useful when dealing with very similar colors.
oh and the color mappings save as flat text files, you can open them up and twiddle them by hand if you like.
oh and note that the color mappings key off of actual RGB values. They are not in any way based off or tied to the palette index of a color. That seemed the 'correct' way to do it to me. It allows you to use the same mapping no matter how the colors are indexed. But if anyone feels otherwise or can think of a good use for using a mapping based purely on index, I'm all ears.
Friday, July 14, 2017 - 17:36
@Evert: Yeah, GIMP plugin would be awesome. I've done some script-fu stuff before but nothing this deep. I guess the trick would be figuring out how to get a good persistent interface going, all the GIMP scripting I've done has been pretty minimal on the GUI side, just pop up to get some parameters and then do your magic.
@All:
Well, put some more time into this. It's not done by any means, but figured there was enough there that it'd be worth packaging up for anyone who wanted to give it a go and give me their feedback.
multiple map support (one image -> many remappings)
What's todo:
palette editing feature set
palette save
sub-region mapping stuff
gui not as nice as surt's mock up
One note for the folks on here especially, the palettes are ripped directly from the image pixels. Literally, the code scans the image by x then y and builds a list of all the unique colors it finds. What it doesn't do (currently) is read the palette as it is stored in the image file itself. So you may find that your colors don't come in in the order you expect. This is on the 'to be fixed' list.
Wednesday, July 12, 2017 - 09:08
> Whole sheet colour variants were just one use-case. What if you only want to recolour just the hurt frames in a sprite sheet to flash red?
Yeah, I am thinking these are two separate cases with two separate solutions:
make multiple color variants from one source image -> ability to view/adjust multiple map sets at once
map different parts of the same image differently -> ability to setup per-region map sets
Technically, you could mimic the first solution with the second but it's common enough a use case that it probably warrants it's own feature. gotcha on the other points. Hadn't even thought of the color reduction use case! Thanks for all the feedback! I'll work through some of these changes and keep you posted. EDIT -sorry for the horrible formatting on this post, seems to happen every so ofter that OGA just eats all the new lines in a post
@sharm:
> Something that probably wouldn't be easy but would also be useful would if I could export a single image with multiple color change options. ... For example, a sprite with blond hair exported quickly into sprites with red, brown, black, and gray.
Currently the tool supports exporting multiple color changes but they are all appended into a single file.
So it's:
Source Image -> Many Color Changes -> Single Destination Image (color changes stacked vertically)
If I understand you correctly, you'd be looking to go:
Source Image -> Many Color Changes -> Many Destination Images (one image per color change)
Batch processing is definitely in the works, and for exactly the scenario you are describing: Setup a color mapping, save it out, then apply to multiple images (or apply multiple mappings to a single image). Before I get too far with it, is a command line interface ok for you? That's always how I do my batch stuff but I can look into a GUI interface if folks don't like using the command line.
> I haven't tested out the program you have so far (not currently on my computer) but I'm excited to. Thanks for this!
If you get to running it, any feedback is definitely welcome! Even if it's just that you hate it! ;)
@dawnbringer:
> The indexed palette is in the analyzis, but I have now made it clearer and labelled.
Thanks! It looks great! Label definitely makes all the difference. I would not have guessed that what's that section was, although in hindsight it's kinda obvious.
> if you're interested, you can beta-test v1.4.
Sign me up!! Sounds amazing! Is there a public link for the beta version or is it invite only?
> hypothetically possible to script your own interface, if one doesn't mind the busy-pointer showing while a script is running
Gotcha, thanks for the 411. 'hypothetically' is defnitely the part that scares me. I don't want to get stuck killing myself trying to trick a scripting system into doing something it fundamentally isn't designed for. Still, as I've previously noted, I see major upsides to implementing the idea within the context of an exisiting image editor. That's sort of the conundrum of it.
> I haven't seen much suggested in this thread that couldn't already be done in seconds with GrafX2 built-in features
Thanks for all the pointers! Using the spare actually works pretty well and gets close to my original goal. It's basically as simple as load the image, copy it to the spare, muck around with the palette, flipping back and forth between original and spare to see changes.
Is there a way to load/save add palettes in Grafx2? I couldn't see an obvious way to do it and googling around came up empty.
> F.ex let's say you wanna try variations on a 16-color sprite
I went ahead and tried this and you're right, it totally works!
It seemed a bit tedious at first, but then I realized you could just drag and select all 16 colors to copy at once. That helps alot!
Again thanks for the suggetions. I grew up on Dpaint IV so Grafx2 is right up my alley. Unfortunately, after spending years learning the Gimp, I never been able to justify the effort needed to re-train my brain for a different editor, so this has been a good excuse to spend some time getting to know Grafx2 a bit better.
@all: I took a bit of pause on development over the last few days to spend some time actually using the new tool for some palette work. I figured that was way to figure out what works and what doesn't. Here are my own thoughts so far:
1) I do like it! I know it's tooting my own horn, but for the very specific problem I was trying to address I think it works really well. It's not just that it does the job, but that it's really simple and fast to use. It has got to be just about the fewest clicks possible to do the job. Click source color, Click replacement color. Don't like, click a different replacement color. It makes auditioning different colors and schemes very easy.
I have a huge pile of tile sprites for the game I'm currently working on and after adding/removing/changing things ad-hoc for far too long, I've undertaken a project to review everything, rationalize it and organize it. So far the tool has proven to be a surprisingly big help with this. By 'rationalize it', I mean going through and making sure each area of the game uses tiles that are distinct. Obviously, artistically they are all unique already, but the tool has proven pretty handy for making sure they're all chromatically unique too. I'm struggling to find the words to describe it, but it's a lot of stuff like 'make sure the swampy area uses dark greens and the sunny area uses brighter greens' I know that sounds a bit obvious and something that should be baked into the art to begin with, but I guess what I'm doing is going back and reviewing everything from a 50,000 foot perspective and saying 'ok, how many dark green areas do I have? are there too many? are these two dark green areas too similar? should I go back and recolor something so the two areas are more distinct?' Having a tool that can quickly swap colors around has proved pretty handy. I've even had a few cases where I got into the tool, fiddled a bit and realized I could totally repurpose something just by recoloring it and moving it to a different area.
2) Being able to quickly create/work on/switch between multiple re-mappings at once is very handy. I find myself making some changes, hitting 'Clone' and then making some more. So I'm sort of iterating through different options, using the previous mapping as the starting point for the next. When I'm done, I go back through and keep the best options and toss the rest.
3) Showing just the colors that are being changed is also very handy.
So thanks very much to surt for pushing both of those ideas!
4) 'picking the index from the preview' would definitley be very nice! Had always intended to add that but now am a bit ashamed I didn't deem it essential as it's definitely a pain to work with out it.
5) Needs a 'Load/Save Project' feature. Something that saves the entire current state (src image, palette, and all color mappings) and let's you load it back in later. Bascially, so you can quit the app and pickup again where you left off later.
Quick question for the gang about this. My initial thought is to implement this as a simple text file that just records the location the the source image and palette (c:\my stuff\picture.png, etc) and a list of all the current color maps. Does anyone see a good reason to try and imbed the images and palettes into the project file? Seems like a hassle and a waste of space to me, but it would technically make the project files more portable.
Some bug notes:
No idea why it's window seems to stop responding to move and resize clicks sometimes. Clicking around on some other windows and then back to the tool does seem to fix it though. I suspect this bug has something to do with SDL and the built in windows file browser dialogues not playing nice together. Will do my best to sort it out.
Definitely chugs power on my laptop! Apologies to other laptop users out there! This largely an artifact of the tool using my game engine, meaning the rendering is done with OpenGL and the core loop is pretty much always trying to run at full throttle, even though 90% the app is going nothing and could probably get away without even updating the screen. Will definitely take a poke at what might be done to make it smarter about this but no promises.
My current 'to-do' list, in rough prioirty order, or at least in the order I was figuring to tackle them (some being larger undertakings than others):
select color from preview
zoom/pan in preview
toggle to load palette with image
load/save project
basic command line batch processing
palette modify/add/edit
index palette support (displaying palette as indexed in image file)
palette ramp mapping tools
region specific mapping
@dawnbringer: i have v1.3 of the toolkit, is that the current release? The analysis my version produces is missing all the labels, which are very handy indeed! :)
One thought for your script, if possible it'd be nice to see a copy of the palette in it's original (index) order somewhere. Perhaps along the top or bottom? I find the analysis great for suggesting ramps, etc. but I frequently end up going back to source file (typically just a grid of swarches) when I want to pick an individual color. I guess it's just that there's typically some kind of manual ordering to the original palette indices that's useful. Also, I won't lie, that'd also be very handy for my little pet project to bring a bunch of standard palettes to OGA as I could just post a copy of the analysis, instead of the analysis plus a copy of the original palette swatches.
Since you have extensive experience with Grafx scripting, do you think something like this color swapping tool would be possible to implement with Grafx LUA scripts? I'd definitely be willing to give writing a script for it a go if it seemed like something in realm of what the scripting system was designed to handle.
ps
your palettes deserve more than a web site, they deserve a shrine!! :)
Hi! I used the middle one in my Pixel Palette Tool:
http://withthelove.com/ppt/
OGA Discussion at:
https://opengameart.org/forumtopic/tool-for-palette-swappingchanging
Thanks much for sharing! As Krial says, they're a great set, stream lined, simple and elegant.
@surt:
Gotcha, I think this will come in naturally with index palette support.
Also, yeah, they'll either be a toggle for flipping between mapping by index or by RGB value, or it will be automatically set based on the format of the source file. or both...
> Runs fine in Wine with the exception of file dialogs appearing behing the main window.
hey, that's not bad! It's actually using OpenGL 3.0 for all the rendering so double good on Wine that it works!
> If you don't work with indices then you can't really work with images with subpalettes (NES, SMS, MD, GBC, etc.)
Is there a particular image file format that does this sort of thing?
My vision was: if you want to work with NES, SMS, etc. just load up that palette and have at it.
But then I generally work in full 24bit and save as PNG files. I use palettes as a source for colors but I don't actually formally use them within an image editor very often. But I think that's also partly an artifact of the fact that I use GIMP and it's index palette toolset is just 'Ok'.
> I figured picking the index from the preview was a given.
> Large image is scaled to less than 1x so I can't see individual pixels. Being able to freely zoom and pan preview is a must.
Yeah, both on the to-do list. If you didn't try already, you can resize the window to enlarge the preview. Not the same as being able to zoom about but might help until that stuff's done.
> Be nice is there was an option to use the target palette as the destination palette when an image is loaded so it doesn't need to be loaded again seperately.
Yup, also on the to-do list.
thanks for giving it a try! Let me know any other comments that pop into your head!
oh and one more thing...
Windows Defender definitely didn't like running the installer, but if you click 'view more' and then 'run anway' it will let you do it.
oh I should also add that it currently displays the RGBA values for the selected color and it's mapping over on the top right of the tool bar. This is kind of a debug feature, it will be replaced by the proper color editing tools when those come in. But for now it at least gives you a way to verify the colors are coming in correctly and can be somewhat useful when dealing with very similar colors.
oh and the color mappings save as flat text files, you can open them up and twiddle them by hand if you like.
oh and note that the color mappings key off of actual RGB values. They are not in any way based off or tied to the palette index of a color. That seemed the 'correct' way to do it to me. It allows you to use the same mapping no matter how the colors are indexed. But if anyone feels otherwise or can think of a good use for using a mapping based purely on index, I'm all ears.
@Evert: Yeah, GIMP plugin would be awesome. I've done some script-fu stuff before but nothing this deep. I guess the trick would be figuring out how to get a good persistent interface going, all the GIMP scripting I've done has been pretty minimal on the GUI side, just pop up to get some parameters and then do your magic.
@All:
Well, put some more time into this. It's not done by any means, but figured there was enough there that it'd be worth packaging up for anyone who wanted to give it a go and give me their feedback.
download link at:
http://withthelove.com/ppt/
What's done:
image load/save
palette load
map load/save
multiple map support (one image -> many remappings)
What's todo:
palette editing feature set
palette save
sub-region mapping stuff
gui not as nice as surt's mock up
One note for the folks on here especially, the palettes are ripped directly from the image pixels. Literally, the code scans the image by x then y and builds a list of all the unique colors it finds. What it doesn't do (currently) is read the palette as it is stored in the image file itself. So you may find that your colors don't come in in the order you expect. This is on the 'to be fixed' list.
> Whole sheet colour variants were just one use-case. What if you only want to recolour just the hurt frames in a sprite sheet to flash red?
Yeah, I am thinking these are two separate cases with two separate solutions:
Technically, you could mimic the first solution with the second but it's common enough a use case that it probably warrants it's own feature. gotcha on the other points. Hadn't even thought of the color reduction use case! Thanks for all the feedback! I'll work through some of these changes and keep you posted. EDIT -sorry for the horrible formatting on this post, seems to happen every so ofter that OGA just eats all the new lines in a post
whoops, here's that butchered mock up....
Pages