Palette Editor: Add Formulas

Suggestions, Wishes, Ideas
#1

Ciao @Jan,

I’m starting to dig further into PM NG formulas, and I can see that this feature has great potential for color manipulation.

I wanted to share some thoughts on how PM NG could be enhanced in the area of procedural color manipulation. Color being a huge subject area, these are just some tentative speculations on the directions that could be explored.

And I’d love to ear from other users what their needs and ideas are regarding color manipulation.

Adding Formulas Support in Palette Editor

I was wondering, though, if formulas could also be extended to the Colors Palette, instead of just paint mode. It would be nice if the same formula system was availabe in a dialog to generate or modify palette colors procedurally, via custom formulas.

The idea is very sketchy, so I’m not sure about the implementation details, but my guess is that it would be cool if the formulas dialog could accept a range of input color indexes (1, 2, or even more) and either an output range (to create new colors from the input) or just overwrite the original range.

For example, one could specify to apply the formula to the colors from index 3 to 8, as input colors, and specify index 100 as the base for the output. Depending on what a formula does, it should be possible to process all the colors in the input range (3–8), apply a formula, and output the result from color 100 onward.

Of course, working with palettes is going to differ from paint mode, for the context here deals with color ramps or palettes. The input range could be made of individual colors from which the formula should create multiple ramps (eg. darker shades). In other cases, the range start and end indexes should be used to interpolate the colors inbetween. Triplets (eg. 1, 5, 10) could also provide stop points for generating gradients (i.e. index 5 being the mid color in the interpolation between 1 and 10).

So the whole system would need to be flexible in terms of how the end user could handle the input and output parameters. Maybe this demands for full scripting support (e.g. Lua, JS), but possibly the current implmentation based on muparser formulas could be adapted to manage this by offering different options on how the color forumla should be interpreted (I know, this would add lots of different dialogs).

I just think that procedural color generation could offer some useful features. Besides allowing a quick way to create harmonious color schemes, it could also be exploited to dynamicall test sprites against different brackgrounds (e.g. I’m creating a character and would like to find the best background color to match it’s average color, or inversely I have to chose its colors based on the background again which it will be shown).

Extending Formulas Color Spaces

As for the formulas dialog in general, I was wondering if in the future we might see other color spaces supported besides HSB and RGB, e.g. CIE Lab and other color spaces commonly used in perceptual color manipulation.

The introduction of Lab color support could then lead to useful builtin functions like CIELAB ΔE* color distance measuring (eg. dE2000) which would allow creation of powerful formulas. (maybe dE200 is a bit computational expensive to be used in real time paint-mode, but for palette formulas it would be great to have).

Script Support?

Maybe color manipulation is too wide an area to be able to fulfill all the possible needs with hardcoded presets, and the easiest solution could be to allow custom scripts (e.g. via Lua or JavaScript), at least to define some custom foregin functions to use in the formula dialog. Maybe integrating a FFI could be easier than adding full external scripts support (variables, name spaces, etc.).

Lua is probably better for this type of application, but definitely JavaScript has a richer echosystem of libraries for color manipulation.

#2

Thank you for your ideas and I think there can be done a lot concerning color manipulation. But as you also pointed out you will quickly reach limits that you won’t have when using true scripting.
You already know about the plugin interface and I think that creating plugins for these purpose would be the best thing. There could even be a plugin that lets you enter simple mathematical formulas or scripting based on predefined i/o variables, so that you can even use loops and conditions etc. but without programming all the other code required for a plugin to work.
This would also match your language independent approach for the plugin interface stubs.
What do you think?

#3

What do you think?

I think that both solutions are viable, with custom plugins offering more power and freedom, on the one side, and a native formulas dialog offering a standard way to share color PMNG formulas between users.

Just like with the current native formulas system (which is a powerful feature), I think that having some native formulas for colors would be great, even if limited in scope. The idea is that these standard formulas should be exportable/importable, so that users can share their creations — when working on a graphic projects as a team, attaching the required formulas to the image/animation project would be essential to allow others to work on the same project.

With PhotoShop, I would always export the third-party plugins custom settings that I used in the various filters, and hand them over to my collaborators; for if they needed to adjust some layers they’d also need to reapply all the various filters in an identical manner (assuming they also had the same third party plugins).

Some PS plugins (eg. the various Alien Skin and Auto FX plugins collections) allowed some rather complex settings for each filter, which you can save to disk and export as an .ini file. I would always export all the settings I used with a project and store them next to the PS files, for if the PC crashed and I had to reinstall it, I’d always need the original setting if I ever needed to work again on those images or add new ones along those lines.

So, I think there are good arguments for both a native dialog and third party plugins. The main difference is that a native dialog for formulas will always be guaranteed to be available in future versions of PMNG (or even next incarnations of PM), while a third party plugin might not be guaranteed to be updated in the course of time, following PM evolution.