Master palette editing

Are you interested in editing your game's master palette, especially with a dedicated indexed-palette editor such as you can find in GrafX2?

I recently looked at the state of master palette editing, and it's still pretty annoying to do right.
Either you do a lot of manual manipulation of individual pixel colors, or go to unusual lengths to get colors out of the image, into a freeform palette format (such as GIMP Palette) that can be rearranged readily.
Editing the palette directly using a dedicated indexed-palette editor is also unreliable, as the 24bit input format makes the order of the indexed palette unreliable and usually wrong.

I wasn't happy with this state of things, and GrafX2 is my pixelling tool of choice, so I made a script that you can install into GrafX2.
It fixes the misarranged indexed palette that comes from importing a 24bit palette, in a single step.
This effectively allows you to handle indexed palettes and 24bit palettes (ohr standard format) with equal ease.
You can use the standard color tools (Curves, Levels, Color Balance) etc in GIMP/PS/etc to adjust the palette's overall characteristics, and GrafX2 for editing individual colors, building gradients, and rearranging easily.

In short, loading a 24bit palette in the standard OHR-recommended format into GrafX2 results in this:


(note the difference between the image layout and the indexed palette layout)

After invoking the script:

(layouts match, you can edit the palette to your heart's content and both OHRRPGCE and GIMP will understand it.
After doing a 24bit edit in GIMP, all you'll need to do to get the updated palette is 1. reload the image, 2.run the OHR palette arranger script.)

I've also clarified and updated the GrafX2 page on the wiki, and am planning on doing some screencasts on the OHRRPGCE-related topics covered there (animation, advanced tile editing, master palette editing,). Tell me if you're interested in anything particular and I'll see what I can do.

You can get the script from here: http://rpg.hamsterrepublic.com/ohrrpgce/File:Grafx2_ohrpalarrange_script.zip
Installation instructions are included in the zipfile. Feedback from Windows users is particularly appreciated .

Thanks to The Wobbler -- spotting his HoTOHR request inspired me to take care of this.

Neat!

That is a very useful script. However if you don't plan to apply colour manipulation tools to the whole palette in something like GIMP but just want to edit some colour ramps (which GrafX2 is indeed very nice for) then you can more easily import the palette with colours in the correct order by importing an 8 bit screenshot of the game rather than starting from a 16x16 24 bit bmp.

Oh actually, one thing: GrafX2 has an option called "Safety Colors". Turn this OFF before playing with colours. If it is on GrafX2 will silently modify your palette without telling you in order to ensure that its UI colors exist in the palette. Extremely frustrating. I think it also does that in some other circumstance.

Good point. To be fair, I envision the workflow to typically encompass both, since overall adjustment needn't apply to the whole palette -- GrafX2 is good when you think "those 3 ramps should be bluer" but it's not so good for fulfilling thoughts like "Those 3 ramps should have more contrast" or "Those 3 ramps should become yellower as their colors brighten."

This script is good also if you are eyedropping from photos to get colors, as I did today for a screencasting test, and just painting them into a 16x16 image as pixels (that's actually the current easiest way to get them into GrafX2 since GrafX2 doesn't have a colorpicker that works on external windows.).

There's also another style of palette editing which is exemplified by GPick (devel ver, especially), which is better than GrafX2 for ramp building and arrangement IMO. Once I finalize the GIMP Palette-to-Image and Image-to-Palette scripts, this will also become more accessible.

Allowing GrafX2 to load GPLs is also on the table. In general I am hoping that eventually 256-color GPLs can be supported in OHRRPGCE, as the ability to name colors has one very good effect: you can use those names to specify one or more ramp memberships and positions (eg "carrot05 fire04") -- so you can arrange the master palette into whatever ramps you want, without actually reordering it, and with the ability to have those ramps' contents add up to >256 items. I feel this would make designing 16-color palettes much easier, the ability to select from logical ramps rather than often being constrained by the actual master palette layout; it would be worth the slight increase in complexity.

If the above doesn't make sense, disregard it



Thanks for that, added to the instructions on the wiki! Safety Colors has never bit me in this way that I noticed, fortunately. The 'other circumstance' you mention is when you have really few and unfitting colors in your palette -- imagine CGA It will add colors in the final slots of the palette to ensure the GUI is not an unreadable mess. This should have no significant effect unless you care about saving 2bit GIFs, or actually end up using those gui colors in your image.

Actually, if you hit F1 in the Settings dialog, it will tell you that that is the exact function of the Safety colors setting:


EDIT:
GIMP Palette-to-layer-pixels and layer-pixels-to-palette scripts are working and nearly finished (only need to make sure that wide 'palette' layers fit inside the image when applicable.)
I plan to do a screencast on quickly building alternate 16-color palettes for a sprite using these.
This will showcase how much use you can get out of 'photoshop-ish' color manipulation tools in this way.
The package I've linked here, and the palette <-> layer pixels plugin will both go up on my DA account http://aicaz.deviantart.com when they're ready.

Actually that description is a lie though. I realize now that enabling it installs those colors at the end of the palette regardless of whether a close enough match already existed or not. So good point.

A short update:

* the GIMP palette<->layer transfer plugin is ready (available here)
* GrafX2 support for GPL palettes is complete at a basic level, but hasn't been added upstream yet -- yrizoud and pulkomandy want to do the palette editor rearrangement first.
* GPick palette/selection info has been implemented in development versions. (shows total number of colors in palette, and if any colors are selected, shows how many and the starting/ending palette indices of the selection)

Which reminds me, it's been some time since the last GPick release, 0.2.4; since that time 98 commits have been made, implementing:

* Reverse the ordering of the selected colors
* Sort and group colors
* Autonumbering
* Simple zoomed measurement tool
* Quantization transform (simulates older RGB colorspaces like EGA64, CPC, 15bit hicolor, SNES)
* Configurable auto-naming for colors created by tools such as Mix Colors
* Lua library is now in-tree, so no external dependency.
* LCH color sliders
* Masking out invalid RGB colors for LAB and LCH sliders
* Configurable white point + observer for LAB/LCH conversions
* Can hide individual colorspaces from the sliders panel entirely
* Multi-color DnD
* DnD supports color replacement, inc. multi-color selections
* Quick replacement of a color in the swatch hexes from a color in the palette (press [1-6] in the palette)
* Quick replacement of a palette color with a color from the swatch hexes (CTRL+[1-6])
* Multi-color DnD between GPick instances works
* Autoname command (set the name of colors according to the best match in the color name database)
* GPL and ASE are now supported as save/load formats, not just import/export
* Autosave
* Palette can be hidden/shown
* Blend Colors tool (like Mix colors but with more context. Builds a gradient out of 3 input colors and 2 numbers representing the length of the 2 sub-gradients. Realtime preview.)
* RGB color mixing (Mix Colors, Blend Colors..) uses linear RGB, which is much more accurate and reliable
* Support editing the exact numeric channel values of colors, not just via sliders
* Color vision deficiency transform
* Several bugfixes, of course.

Wow, that's a lot. We should definitely look at getting the next release out soon.