Issue 66 in gpick: Filter all/selected colors through Lua script
gp...@googlecode.com
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 66 by 00a...@gmail.com: Filter all/selected colors through Lua
script
http://code.google.com/p/gpick/issues/detail?id=66
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)
gp...@googlecode.com
Status: Accepted
Owner: 00a...@gmail.com
Comment #1 on issue 66 by 00a...@gmail.com: Filter all/selected colors
through Lua script
http://code.google.com/p/gpick/issues/detail?id=66
(No comment was entered for this change.)
gp...@googlecode.com
Comment #2 on issue 66 by 00a...@gmail.com: Filter all/selected colors
http://code.google.com/p/gpick/issues/detail?id=66
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.
gp...@googlecode.com
Comment #3 on issue 66 by thez...@gmail.com: Filter all/selected colors
http://code.google.com/p/gpick/issues/detail?id=66
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.
gp...@googlecode.com
Comment #4 on issue 66 by 00a...@gmail.com: Filter all/selected colors
http://code.google.com/p/gpick/issues/detail?id=66
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.
gp...@googlecode.com
Comment #5 on issue 66 by 00a...@gmail.com: Filter all/selected colors
http://code.google.com/p/gpick/issues/detail?id=66
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/