Filter all/selected colors through Lua script

[thezbyg]

Original issue 66 created by thezbyg on 2012-02-17T13:03:00.000Z:

Outline of concept:

• Up to 9 'Custom commands' which invoke Lua scripts to manipulate a table of Colors, which either replaces the selection, replaces the entire palette, is appended to the palette, or is discarded.

See the bottom if you're looking for examples of applications of this.

Currently, be aware that it's slightly amorphous in exact technical specification.

Elaboration:

• 'Custom command' submenu in rightclick menu, containing invokers for up to 9 scripted commands.
• Invoking a custom command calls a corresponding Lua function; the function is passed a copy of either the selected colors, or all of the colors in the palette; they are passed as a table of Color objects rather than a table of Lua tables.
• The script function has access to all of the standard math and i/o functionality of Lua.
• In addition, it can convert the colors between colorspaces, get and set their names, and create new Colors. Particularly, a function is provided to convert a whole table of colors at once.
• The script function must return a table of Colors whose colorspace matches the input colorspace.
• GPick converts the COLORS to standard RGB if necessary.
• according to a per-command setting, the COLORS either replace the currently selected colors, is appended to the palette, replaces the entire palette, or is discarded (this latter is useful for custom export or related commands, where the function wants to return {} for COLORS anyway.

Thoughts on how to simplify command selection:

• Require eligible scripts to 'register' themselves. This will allow specification of a lot of useful info, such as: * Preferred input colorspace
  • Whether to prompt the user for parameters (numeric, string, or color inputs) when invoked, and what those parameters are.
  • Show preview by default? (slow scripts and export scripts will want to disable this.)
• And of course will allow the selection to be via combo box rather than typing function names, which is nice UI-wise.

Justification:

This is a means to support various workflows in which a few key commands work much better if integrated in the palette editor. The actual details of how this is implemented still need quite a lot of thought and hopefully discussion.

Examples of commands that are suitable for implementing through scripts:

• Export to/import from esoteric formats (eg. GBA palette, mobile phone palette, completely custom palette format)
• Custom color transforms or combinations
• 'splitted' export (for example, exporting a palette containing multiple 16color sprite palettes, as a set of palette files)
• Adaptive insertion (insert colors IFF the difference between two neighbouring colors exceeds a certain threshold in LAB space) or adaptive removal (merge them IFF they are too similar)
• Sorting : sort by lightness, sort by name, 'reverse';
• Other statistical functions: merge colors into an 'average color' (good for optimizing palettes), randomize colors (ala 'chaos' parameter in 'generate' dialog), quantize (eg. GBA/DS and mobile phones use 15bit color, only 32 steps of R/G/B)

[thezbyg]

Comment #1 originally posted by thezbyg on 2012-02-17T13:29:30.000Z:

<empty>

[thezbyg]

Comment #2 originally posted by thezbyg on 2012-02-21T05:03:50.000Z:

On reflection, I think sorting is actually a core function, if we want to support color ramps well. It might be smarter to implement that as a combination of C++ (for GUI) and Lua (for calculating sort keys from color -- called once per input color.).

For this issue mainly, I'm aiming at letting people implement project-specific functions without any need to understand C++ and the guts of GPick.

[thezbyg]

Comment #3 originally posted by thezbyg on 2012-02-21T21:08:01.000Z:

The good news is that lots of code that is used to support 'Converters' can be adapted, however a bunch of C++ to Lua wrappers for all the color space transformations, and other stuff, will have to be implemented.

I think that import/export scripts should be separated from other scripts and handled differently. These scripts should add their supported format into the format lists in Open/Save/Import/Export dialogs, and when users open or save a file in that format, the script could do its job.

Why do you want to limit the number of commands in the menu to 9?

Overall, this is a great idea.

[thezbyg]

Comment #4 originally posted by thezbyg on 2012-02-21T22:08:24.000Z:

Thanks for the info!

• As for the wrappers, I've done that before with C code; should be relatively straightforward IIRC.
• "import/export scripts should be separated from other scripts and handled differently". I generally agree, though some -- eg which export to a fixed location, export to multiple files, or import from a file type that's effectively read only -- seem a bit more questionable as to whether they belong there.

Still, that leaves us with a few categories of script in terms of where they get activated; that's handy.

• export/import
• sort
• general
• 9 because -- Keyboard shortcuts. OTOH it's probably more appropriate to let them register their own keyboard shortcut. Shortcuts are another bug, really, with so many of them being undocumented in the interface, and all of them being un-editable.

[thezbyg]

Comment #5 originally posted by thezbyg on 2012-02-22T05:08:42.000Z:

Actually, there's one other category of script, although it's not immediately related to this issue -- 'edit hooks' (run when one or more color is added to the palette, or run when a color is edited in the palette). Why this is important? Getting data through to the place it's used ASAP is important -- http://flowingdata.com/2012/02/20/live-coding-and-inventing-on-principle/