|
<< Click to Display Table of Contents >> Navigation: Python scripting tools > System integration |
The main system integration resource is the integrated Python engine, which is covered in its own chapters Python scripting tools and Mistika python extension library. This chapter is about other external resources and configuration files for programmers and system integrators.
As any Mistika product, Mistika Workflows is an open environment, there are no proprietary databases and all the data structures are stored in text files, either ASCII or XML. A first introduction (for non programmers) was covered in the Mistika Folder structures section.
Here you will find extra details for engineers and programmers.
When you install a Mistika product, the location of the installation folders is defined in the SGO Apps/installation.xml file.
One of those folders is specially relevant for Mistika Workflows, which is the "shared" folder. Among other things this folder contains all the python nodes and their xsd schemas, plus all the display filters that are available.
SGO AppData/shared/config/schemas
SGO AppData/shared/workflowsLibrary
SGO AppData/shared/display_filters
(the shared folder also contains more folders, but in general they are only relevant for other Mistika applications)
The interesting thing of the shared folder is that it is designed to be shared between different computers having any Mistika applications installed. To take advantage of this capability you can copy the shared folder to a shared network drive and then change its location in the installations.xml file of all computers sharing it. In that way, any display filter or python node created (or modified) in any system will be immediately available to the other systems.
You can change the location of the shared folder trough the preferences menu, or directly in this configuration file:
Mac, Linux: .sgoMistika/mistikaPaths.xml
Windows: AppData/Local/sgoMistika/mistikaPaths.xml
The workflow .mwf files use standard Xml syntax. A single file contain all the workflows defined in a Mistika Workflows section. Programming is normally managed in the Python script editor, which provides the necessary Mistika Workflows Python extensions module. You should rarely need direct modifications to these files, although they are indeed possible.
When nodes with Mistika render capability (encoders and MistikaRender) are executed in the queue they will render a temporal .RND File, which is saved in the DATA/RENDER/WORKFLOWS folder of the default project..
Note: In the particular case of the MistikaRender node the path to the .rnd is defined on its own property.
Once the rnd is created, a render process is launched automatically, equivalent to what you could do with the CLI ( workflows -r PathToTemporalRND.rnd ) unless their Write RND only property is active. Then the queue workflow will not continue until this render is finished. (if you want to run more workflows in parallel you can open other instances of the Mistika Workflows application).
Please note that those .RND Files do not contain a whole workflow, just the render job for the ongoing task node.
Display filters are injected in the RND Files by encoder nodes, and they are equivalent to activate the same display filter in the Mistika Ultima & Boutique (going to the display filters panel and selecting the "render" type in there). A display filter can contain any combination of Mistika effects, and it is highly recommended to create them with Mistika Ultima or Mistika Boutique, but not mandatory.
These files are .dfilt files stored in the folder: SGO AppData/shared/display_filters, and they use traditional Mistika ASCII syntax (not Xml)
Display filters can be modified before execution, the CSV To DFILT node is a good example node about how to do it. This particular example will configure a display filter (a watermark overlay in this example) using the text of a .csv file. Find more details about complex (multilayer) display filters in the display filter point.
Python is a powerful language to process "files" and to manage "encoders" of image formats, but this language it is not optimized for processing image content at pixel level, although many python modules exist for that. If you need high performance, Mistika also provides a way to execute GLSL code at render time. To do this you will need to use a display filter node containing a GLSL effect with your code (see Mistika Ultima and Boutique documentation).
The OFX plugin standard is also supported for 3rd party effects included on display filters, although in Mistika Workflows this is only possible for render purposes (access to the GUI interface of an OFX plugin requires Mistika Ultima or Mistika Boutique).
This can be feasible but it is a bit more complicated that you might think. If you plan to run Mistika Workflows on virtual machines there are a couple of important aspects to consider:
1 - The virtual machine needs to have an NVIDIA GPU available to it and a graphic session (desktop) active. This is because many important tasks are GPU based, and on Linux and Windows they require a graphics context with CUDA, OpenGL, and OpenCL. Some formats can be decoded or encoded by GPU, and many image processes like color conversions, display filters, LUT, rescaling, etc are GPU based.
Note: Multiple GPUs are not supported, if there is more than one Mistika will only use one (the one where its session is launched)
2 - A local license may fail to work on some virtual machines (they are serialized to physical mac address, and in some cases the license server can fail depending on how are they ritualized). However, if that happens Mistika can still get the license remotely from a physical machine (see next), so it can be solved in this way.
A particular case are AWS EC2 virtual machines. To run Mistika Workflows on AWS the AMI image used to create the VM needs to include the NVIDIA GRID driver preloaded (also called "NVIDIA RTX software for virtual workstations" ). In the case of linux please note that the driver needs to work in graphics mode, not "compute" mode, which typically requires to have an X11 session active.
In the case of Proxmox VMs, passing the NVIDIA GPU in pass-trough should work fine. In that case the configuration should be similar to using a physical machine.
All Mistika licenses are "floating licenses", which means that they can be obtained dynamically from a remote license server. In the client computer just set the license server ip (or resolvable hostname) using the SGO Activation tool . In the server side nothing needs to be done (apart from activating enough licenses on it). The license is returned to the server the moment the Mistika Workflows is closed (or if the network connection is interrupted for too many seconds). More about licensing procedures here.
Experimental support for Docker is available here:
https://hub.docker.com/r/sgomistika/mistikaworkflows