Krita/Scripting

From KDE Community Wiki
Revision as of 01:12, 26 June 2015 by Timotimo (talk | contribs) (unmangle IRC log at the top of the page)

This page is going to collect ideas on how to write the new scripting API for Krita 3.x

IRC log

< a----> C------B perhaps I think layer management would be important and useful to start with
< a----> E.g. adding a layer, positioning a layer and controlling common attributes like opacity special layers like masks etc. can come later.
< C------B> a----: that is actually what I am looking at now
< a----> that would be a good place to start I think.
< a----> Things like brush engines, brush opacity control are better done from within Krita and should not need to be used externally.
< A-----o> C------B, I'd love to make a plugin that deletes the current layer (or fills it with a color) when I lift the pen from the tablet, so I guess being able to listen to pen events would be cool
< A-----o> C------B, I'd also love to make some plugins that allow you to use external hardware to control e.g. brush parameters, so that would be cool
< a----> C------B I think its better to start from the outside gross functionalioty and then go to more deeper layers of Krita like an onion.

Usecases

What do people use scripting for in a program like Krita? To automate jobs!

What kind of jobs could be automated with ease?

  1. Exporting and Importing of files and to different filetypes(already possible with the command line)
  2. Layer handling -> Visible, lock, etc.
  3. Filters, or a set of filters.
  4. Transforms.
  5. Pseudo filters like 'split alpha' or 'split layer' or 'seperate image'.

Example use-case: Game Texturer: Has a file with three layers, called 'specular', 'diffuse', 'normal'. What they want to do is to make 'specular' the alpha channel of 'diffuse', and have the diffuse and normal layers exported as filename-layername.tiff. So the commands needed would be...

  • Find layer 'specular'
  • Convert layer to transparency mask.
  • Find layer 'diffuse'
  • Attach transparency mask 'specular' to 'diffuse'.
  • Export layer 'diffuse' as 'filename-diffuse.tiff'
  • Find layer 'normal'
  • Export layer 'normal' as 'filename-normal.tiff'

Example use-case: Comic artist. Has a file with several 'sketchlayers' a 'colour-layer' and 'lineart' layers. They would want to resize their files, and maybe even grayscale them:

  • Find all layers with name 'sketch'
  • Turn all these layers invisible.
  • Find all layers named 'colour'.
  • Put a 'greyscale' filter on all these layers.
  • Flatten the image.
  • Resize the image to have 800px width.
  • save as 'filename-800pxwide.png'

Example use-case: Live export

Export the image as displayed on-screen (all layers merged) to a shared memory region for other applications to read. Interesting for game-developers et cetera who would like to have a preview of the texture they are editing right in their game.

Example use-case: Control brush parameters

Some artists like to use e.g. external hardware (e.g. with a scrollwheel or thumbstick, like an xbox-controller) to interact with their painting program. It would be cool if it was possible for a plugin to manipulate brush parameters (size, flow, ...) on the fly through input it receives from e.g. external control-hardware or other such sources.

Example use-case: Warmup-script

I like to use a script that deletes the entire canvas when I lift the stylus off my wacom tablet. Together with repeated or symmetry mode, as well as a speed sketch brush, it makes for a very nice way to generate shapes very quickly and warm up your "visual library". Currently I have this implemented in a very hacky way, if it was possible for plugins to listen for events such as "stroke end" or "pen lifted" and then issue a "clear canvas" command, this could be a simple 10-line script.

Big idea:

A way to conveniently share scripts, similar to the GHNS mechanism that many other KDE components have, or the gimp/blender plugin registry? Users probably need to be told that plugins are not sandboxed!