I know! I am trying to be careful not to over do it as it's just meant to be a quick little tool and I do still have a game to make. So far, I think it's going ok, but please stop me if I start adding any drawing or image editing features!
> Message me an e-mail address
Done! I actually have a small idea for a script I've been meaing to write as Script-Fu for a long time. Think I'll use this as an excuse to learn some LUA and do it as a Grafx plugin instead. The concept is something that automagically colors the invsibile (alpha=0) pixels around a sprite by sampling the nearby visible pixels. Editors tend to leave junk or black in invisible areas, this can bleed into the sprite itself if you apply any filtered scaling/rotation to it. Filling invisible pixels instead with color sampled from the near by visible pixels minimizes the impact of this 'bleeding' and yields pretty nice results (at least with standard bilinear texture filtering). I actually have a stand along program I've written that does this, along with re-gridding sprites. Just some code I wrote a few years back, but when I saw your scripts can do re-gridding (changing from say 16x16 to 18x18 grid) I thought 'this is a better place to do that alpha coloring thing...'
@Sharm: Glad you like the program!
> It would be a little easier to use if I could rearrange or load the palette for the beginning image
I think I hit both of these in the new update, let me know if it works/helps/make sense.
> the more gui you can make things the better for me
Ok. I think my approach will be: command line batch commands plus a GUI front end for them. Hopefully that will work out to be the best of both worlds :)
@all: Squeezed a little development time in this weekend, and so...
preserve palette order when loading indexed format images (display palette as indexed in image file)
Some notes:
you can pan about with the sliders, or by holding space and moving this mouse (Gimp style).
you can select a color by clicking on either the original or remapped images. In either case you get the color from the original image. In other words, if you have remapped black to white, clicking white on the remapped image will select black. That might seeem counter-intuitive but after using it a bit I found this to be the best approach. Think of it as selecting what mapping you want to adjust not really the color. If it helps, think about how it should work in the indexed image case, you'd want to select by index not color.
you can re-arrange the palette swatches however you like. You'll lose the order if you reload the image or load a new image (even one with the same palette). BUT the order is saved in the project file, so if you get an order you like, you can keep it that way (or for the swap palette by saving it). Also the order for the source image palette and new palette are held separately, so reloading one won't affect the other.
Will work on the ability to keep a custom order when loading a new image, as with 'toggle to load palette with image' it's mostly a matter of how to present it in the GUI.
Note that clicking on a swatch in the 'Palette' area always sets the map for the currently selected color. This is true even if you are clicking to drag the swatches around. To keep this from being a problem, I've made it so that if you click on any empty space it will clear the current color selection (so no color is selected.) Technically, this does penalize errant clicks a bit, want to use for a bit to see if that's a big problem, didn't seem to be in testing.
When viewing multiple mappings, zoom is a bit funny. It truncates the view rather than shrinking it. Makes optimal use of the space but not quite the behavior I'd expect. Working on it...
The debug text showing RGBA for the current color and map is still there, don't worry it will go away (or be made to look nice) someday!
Well, that's all for this update. Think I largely maanged to stick to my original priority order. Here's the todo list in the current order I'm thinking of tackling it:
toggle to load palette with image
toggle to keep custom palette order when loading new image with same palette
palette modify/add/edit
palette ramp mapping tools
index palette support (edit/map by index instead of color)
region specific mapping
command line batch processing
GUI frontend for batch processing
Attaching a screengrab that shows pan/zoom and dragging to rearrange palette in action.
Thursday, July 20, 2017 - 13:24
@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)
@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 - 16: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 - 14: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 - 06: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
@Dawnbringer:
> Your program is getting ambitious! :D
I know! I am trying to be careful not to over do it as it's just meant to be a quick little tool and I do still have a game to make. So far, I think it's going ok, but please stop me if I start adding any drawing or image editing features!
> Message me an e-mail address
Done! I actually have a small idea for a script I've been meaing to write as Script-Fu for a long time. Think I'll use this as an excuse to learn some LUA and do it as a Grafx plugin instead. The concept is something that automagically colors the invsibile (alpha=0) pixels around a sprite by sampling the nearby visible pixels. Editors tend to leave junk or black in invisible areas, this can bleed into the sprite itself if you apply any filtered scaling/rotation to it. Filling invisible pixels instead with color sampled from the near by visible pixels minimizes the impact of this 'bleeding' and yields pretty nice results (at least with standard bilinear texture filtering). I actually have a stand along program I've written that does this, along with re-gridding sprites. Just some code I wrote a few years back, but when I saw your scripts can do re-gridding (changing from say 16x16 to 18x18 grid) I thought 'this is a better place to do that alpha coloring thing...'
@Sharm: Glad you like the program!
> It would be a little easier to use if I could rearrange or load the palette for the beginning image
I think I hit both of these in the new update, let me know if it works/helps/make sense.
> the more gui you can make things the better for me
Ok. I think my approach will be: command line batch commands plus a GUI front end for them. Hopefully that will work out to be the best of both worlds :)
@all: Squeezed a little development time in this weekend, and so...
PixelPaletteTool Version 1.2 available at:
http://withthelove.com/ppt/
Adds support for:
select color from preview
zoom/pan in preview
load/save project
rearrange colors in palette
save palette as image
preserve palette order when loading indexed format images (display palette as indexed in image file)
Some notes:
you can pan about with the sliders, or by holding space and moving this mouse (Gimp style).
you can select a color by clicking on either the original or remapped images. In either case you get the color from the original image. In other words, if you have remapped black to white, clicking white on the remapped image will select black. That might seeem counter-intuitive but after using it a bit I found this to be the best approach. Think of it as selecting what mapping you want to adjust not really the color. If it helps, think about how it should work in the indexed image case, you'd want to select by index not color.
you can re-arrange the palette swatches however you like. You'll lose the order if you reload the image or load a new image (even one with the same palette). BUT the order is saved in the project file, so if you get an order you like, you can keep it that way (or for the swap palette by saving it). Also the order for the source image palette and new palette are held separately, so reloading one won't affect the other.
Will work on the ability to keep a custom order when loading a new image, as with 'toggle to load palette with image' it's mostly a matter of how to present it in the GUI.
Note that clicking on a swatch in the 'Palette' area always sets the map for the currently selected color. This is true even if you are clicking to drag the swatches around. To keep this from being a problem, I've made it so that if you click on any empty space it will clear the current color selection (so no color is selected.) Technically, this does penalize errant clicks a bit, want to use for a bit to see if that's a big problem, didn't seem to be in testing.
When viewing multiple mappings, zoom is a bit funny. It truncates the view rather than shrinking it. Makes optimal use of the space but not quite the behavior I'd expect. Working on it...
The debug text showing RGBA for the current color and map is still there, don't worry it will go away (or be made to look nice) someday!
Well, that's all for this update. Think I largely maanged to stick to my original priority order. Here's the todo list in the current order I'm thinking of tackling it:
toggle to load palette with image
toggle to keep custom palette order when loading new image with same palette
palette modify/add/edit
palette ramp mapping tools
index palette support (edit/map by index instead of color)
region specific mapping
command line batch processing
GUI frontend for batch processing
Attaching a screengrab that shows pan/zoom and dragging to rearrange palette in action.
@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
Pages