This thread is for collecting information on HOW people want to use scripting.

There's the original page we did last year:

https://community.kde.org/Krita/Scripting

Here are two answers I got from the 3d-pro mailing list:

Integration with asset management systems seems like "low hanging fruit"
for Python integration: being able to override standard load / save dialogs
so artists can be presented with a "logical" view of the show / sequence /
shot / asset they are working on instead of just filesystem paths, the
ability to publish an asset so it can be passed on to the next stage... You
could take a look at the Shotgun Toolkit code at:

https://github.com/shotgunsoftware

for an example of how integration with third party apps can be done, and
more specifically at the PS integration:

https://github.com/shotgunsoftware/tk-photoshop

----
Hi,
I'm not sure how much I can say with breaking NDA, but at Animal Logic we
currently use Photoshop to do some of the following using Javascript and
Actions:
separating images into multiple layers and applying various image
operations to the new layers
colorspace lookups and color replacement using a combination of layer name
and pixel values
exporting layers as files using custom UIs and export options
Hope this helps!
----

Another mail:

First off, can I say Thanks for asking! I've lost track the number of apps
that add scripting but leave out key functions (Mplay _still_can't script
saving an image after what, 20 years?!) so I appreciate that you're
attempting to hit the important stuff out of the gate.

For me, scripting something like a Paint app is primarily about pipeline
integration. I don't want artists to have to browse, name output files and
likewise I don't want them to have to browse to find input files unless
necessary.

So, as long as it's Python 2.7 and can directly use a company's pipeline
libraries as part of loading and saving images that's a good start.
Ideally the scripts would be able to access things like layers, channels,
alpha, masks etc for loading and saving. With the cool anim stuff, being
able to script loading/saving frames and controlling Anim settings by
scripting easily will also be important IMO.

Colour management would also be something I'd want to script as a pipeline
integration thing, i.e. being able to load and choose different colour
settings.

On-start and on-load hooks are really useful, so that you can do things
like auto-setup the "scene" for the artist based on shot settings etc. or
when they load a new image, some analysis could be done to ensure correct
colour space or bit depth based on show prefs etc. These hooks would
ideally pass a **kwargs dict that would have the maximum info available

I'm sure I've missed something but that's a good start

Another mail:

I'm currently learning krita and pushing hard to get it into our workflow here. Two things that people almost immediately
ask for that would be great to have:

- a shading language for generating images based on input parameters. This sounds like generators but I'm having a little
trouble finding them in 3.01. If so, writing them in c++ would be a high barrier of entry for the people who would want
to write them.
- File I/O with custom metadata. We have a workflow for matte paint that injects metadata into tiff headers. I would
*love* to get that out of photoshop

I'm currently learning krita and pushing hard to get it into our workflow here. Two things that people almost immediately
ask for that would be great to have:

- a shading language for generating images based on input parameters. This sounds like generators but I'm having a little
trouble finding them in 3.01. If so, writing them in c++ would be a high barrier of entry for the people who would want
to write them.
- File I/O with custom metadata. We have a workflow for matte paint that injects metadata into tiff headers. I would
*love* to get that out of photoshop

(my answer:)

our first point is rather interesting, because _we used to have that_! We
used to use openctl and openshiva (http://www.opengtl.org) to make it possible to
script generators. But the author of both languages sort of lost interest,
and the plugin fell into disrepair. So, right now, the generator plugins
are writting in C++, and there are only two of them! But if we allow either
to convert a numpy array into a pixel layer, or allow per-pixel access
to a layer (that'd be slow, though), then it should be possible again with
not too much work.

As for your second point, that sort of fits in with another refactoring I'm
doing right now -- at the moment, our import/export plugins are pretty limited
and only can read the last-used configuration instead of making it possible
to set that programmatically. I'm fixing that now, and then it should be
possible to extend the tiff import/export plugin to add extra metadata.

Or, if you're using your own python library to sae the metadata, having
access to the actual pixel data would make it possible to do all the
saving from Python.

hanks for asking! There is a lot of bad API here and there so I'm always
happy to see peoples ask what can be usefull _before_ write code.

Here are my two cents, do what you want with it.

You can consider scripting as "what users do in UI" but exposed in scripts:

- open/save files
- create/move/rename/remove layers/groups/brushes/colors
- change brush/layer/preference/anything parameters
- apply filters/transforms/resize

This apprach improve automation scripts and also motivate artists to try it
wich is a good start.

As said before, pipelines try to remove the "monkey click" (non-artistic)
work from user time so the point is to do what user do, but faster and
without error.

onSomething() callback are important yes but its often used to call
lightweight callbacks:

* on app start/close
* on open/load/save/close
* on layer/group created

All are usefull imho but I always consider other way as it can slowdown app.

I suggest to don't use scripting for things related to computation (filter,
real time brush, etc.).

I can explain a use case I had scripting Photoshop:

I asked users to organized their layer groups with specific names (SPEC1,
DIFF, etc.). When they published .psd, the script do roughly this:

for each layer group:
hide all other layer except the current one
erase the image stack
do some color conversion with particular options based on the layer name
(SPEC, DIFF, DSP, BUMP, etc.)
save at the "good place" with particular export options.
(optional: open and run some OpenImageIO code on the exported image)

Doing so, user had textures ready and just had to update texture path in
renderer (using a tiny script) and they where seeing the results on their
render.

About this, the scripting (a sorta JS) in Photoshop was DOM which is very
interesting IMHO. Organize your app like a tree make scripting easier as
you can quickly have a good perspective on how objects are organized. An
interesting point was that you can write getter to get most informations
from it and improve recursively adding functions to manipulate (change)
datas where it's needed.

1) design the app tree
2) write every getters
3) write setters for obvious parameters
4) write the object manipulation functions (parenting, etc.)

# code example
import krita

app = krita.app

# get prefs
p = app.preferences << return a krita.Preferences objects
p.

# layers
for layer in app.layers:
print layer.name

# get layer by name
layer = app.layers['LayerName']

# or, a bit less pythonic:
layer = app.layers.get('LayerName')

layer.move_in(layer_group)

# don't do
layer.rename("foo")
layer.set_visible(True)

# do
layer.name = "foo"
layer.visible = True

This is a specific use case but hope it helps.

Anothers interesting triggers is "Does the document changed since last
save?". Save a document can be slow, when you save, do something, then
undo, the document should state it didn't has changed:

if app.document_has_changed:
# do something

Another one: The undo stack. If you can manipulate it in script (a push/pop
approach can be interesting) it can ensure you can modify document in
script for pipeline related stuff and fall back to it's orginal state once
you've done what you wanted. My "bake and export" is a good candidate to
undo stack manipulation.

* File naming, import, export
* Since Krita is Qt5, it would be great if it could ship with PySide2 and
defer the UI tools to Qt instead of needing to define it all itself. It
would just need a way to get a pointer to the Krita UI that shiboken/sip
could convert to PySide2/PyQt5 use.
* Ways to manage and create layers, set their blending modes.
* Image dimension, cropping etc
* Basic compositing tools like text, masking, etc
* The ability to grab the current layer or entire image and pass it to
Pillow or something like that so that we can do image processing outside of
Krita if needed.

Hi!
Quick Intro: I'm a Blender user, Krita user, and a pipeline TD among other things. Currently working on http://wiresforempathy.org (aka the tube open movie project) and on some pipeline and project management tools that will be called 'spine'.
Some interests:

Texture artists might have a .kra file with many layers (e.g. veins, pores, dirt, etc.) and output many maps (bump, diffuse, normal, etc.) via turning layers on and off, changing their blend modes, changing their opacities, etc. This needs to be automatable so that the process can be repeated via a build system whenever the source file changes or otherwise needed.

Similar to the above, storing extra data in a kra file as a 'parasite' or 'metadata'

Blender style access to tools and properties: creating addons that automate various tasks, with consistent access to data and tools.

Automatically figure out external dependencies of .kra files that reference other data (I believe this is possible to happen), could be done through krita api or by inspecting the file format directly.

Python 3.5 support: since the python api is in its infancy I think it makes sense to target the more recent python version, this will also nicely make it similar to blender

Blender has a background mode, allowing headless running via commandline, and also running scripts like "blender -b -P script.py". It would be nice to do the same for krita for automation. Bonus points for a standalone kra module (bpy has a similar experimental option)