(Phil Barrett edited the old version of this page on Apr 29, 2020)
- What version of the OFX standard do you support?
1.4, but not completely
- What pixel types do you support?
CPU: short, float, half GPU: half
- RGB, RGBA, A-only?
RGBA, A
- Do you support RoI/RoD?
Yes
- Are you premult or non-premult or both?
Currently agnostic as the renderer doesn't have much alpha support. This is changing for Baselight 6.0.
- Is your viewer premult? (I.e. can you see zero-alpha pixels when you load such a clip)
Currently viewer discards alpha.
- Do you return Opaque for frames that are actually opaque (alpha=1 everywhere)?
No.
- Can your host access frames at other times? Are there restrictions?
Yes; no restrictions.
- Can your host access param data at other times?
Yes.
- Do Point2D params get on-screen manipulators?
No.
- What exact string(s) do you return for kOfxPropName?
"Baselight"
- Do you support categories for plug-in names?
Yes.
- Can plug-ins set param values?
Yes, but only from the UI instance. There is no way for a rendering instance to change params.
- Can plug-ins get length of input & output clips?
No.
- Is param layout columnar or grid?
Both, switchable by preference.
- Do you support fields?
Yes but outside the plugin; see kOfxImageEffectPluginPropFieldRenderTwiceAlways
- Are there separate slider limits vs. hard limits for params?
Yes (for Double types only)
- What contexts do you support? Any limitations?
Generator, Filter, General, and (to some extent) Transition
- Do you support kOfxImageEffectInstancePropSequentialRender?
No.
- Do you support the OpenGL Render suite?
Yes.
- Do you render more than one frame at a time in the same process?
No.
Further host-specific information
(current as at 2019-06-19)
- Architecture
OFX plugins are instantiated in the Baselight UI application in order to manage parameters and to render thumbnails.
However rendering of images is done using ephemeral instances created and then destroyed for each frame being rendered.
The rendering instances are generally in a completely separate process from the main application, and on Baselight TWO and Baselight X systems are run on a completely separate computer system.
There can be no communication between the UI and rendering instances apart from via OFX parameters. The rendering instances cannot present any UI (except by burning it into the image).
The two-machine architecture can lead to challenges in implementing plugin licensing.
The OFX host in rendering processes sets kOfxImageEffectHostPropIsBackground to 1.
Baselight TWO and Baselight X systems have a "node" and a "UI host" computer. The node is the larger system, often with multiple GPUs. The UI host is a smaller and quieter system that runs the application UI in the grading suite. The UI host netboots from the node and shares most of its filesytems, notably including /usr/OFX/Plugins and /usr/local. Users should be advised to install plugins on the node.
The OFX Host string property "uk.ltd.filmlight.nodetype" is set to "ui" on a UI host, to "node" on a Baselight TWO/X node, to "ws" in the application process on a Baselight ONE (and macOS), and to either "ws" or "node" in rendering processes on a Baselight ONE (and macOS with AJA hardware) depending on the process being used.
- Sequential rendering
Baselight does not support sequential rendering. The host property OfxImageEffectInstancePropSequentialRender=0 and render property OfxImageEffectPropSequentialRenderStatus=0 indicate this.
Each frame render is entirely separate and is performed by a separate plugin instance, within its own single-frame OfxImageEffectActionBeginSequenceRender/OfxImageEffectActionEndSequenceRender.
While it is extremely likely that frames will be rendered in order, this is certainly not guaranteed, for example when some frames of a sequence are already cached and some are not. The plugin has no way to tell which timeline frame it is being asked to render - indeed it cannot know whether the frame being rendered has any relationship whatsoever to any previous frame it has been asked to render.
A plugin must therefore request all the inputs it needs to render a frame, and base its output solely on those inputs and its parameters. It must not attempt to use information from a previous render.
- Button actions
A button parameter may set the property "uk.ltd.filmlight:OfxParamPropMainThreadAction" (int, default 0) to 1 to indicate that the InstanceChanged action it triggers should be called in the main UI thread rather than from a subthread. You may find you need to set this to allow your button to present custom dialogs etc.
- Image orientation
Baselight's images are stored top-down on the CPU, so kOfxImagePropRowBytes is always negative for CPU rendering. On the GPU, textures are flipped to the expected bottom-up orientation. In both cases no special code is required in your plugin, as long as you can correctly handle a negative value of kOfxImagePropRowBytes.
- Colour space handling
By default images passed to and from OFX plugins in Baselight are in a linear tone curve and whatever primaries the user has chosen to use in the grading stack at that point in the timeline.
To afford better control, Baselight defines a host property "uk.ltd.filmlight.OfxImageEffectPropSupportedColourSpaces" (multi-string) which lists the colour spaces it is able to use with OFX.
When the plugin defines a clip, it can optionally set an entry in the clip's property set "uk.ltd.filmlight.OfxImageEffectPropSupportedColourSpaces" containing one or more strings. This forms an ordered list of the colour spaces the plugin can work with for that clip. When the Baselight stack is using a colour space not in the list, it will convert it from a scene-referred colour space to the first scene-referred entry in the plugin's list; and from a display-referred colour space to the first display-referred entry in the plugin's list.
During OfxImageEffectActionRender, the host sets the "uk.ltd.filmlight.OfxImageEffectPropColourSpace" (string) property on each clip to indicate the actual colour space used.
Baselight currently supports the following spaces:
"unknown/linear" - unknown primaries, linearised - this is the default in Baselight "unknown/unknown" - no conversion at all, no information at all "rec709/linear" - Rec.709 primaries, linear tone curve "aces/linear" - ACES primaries, linear tone curve "arriwg/arrilogc" - ARRI WideGamut primaries, ARRI LogC tone curve "sonysgamut3cine/sonyslog3" - Sony SGamut3.cine primaries, Sony SLog3 tone curve "rec709/rec1886" - Rec.709 primaries, Rec.1886 tone curve (display-referred)
Currently no DRT is applied if converting to/from these spaces involves a switch between scene-referred and display-referred colour spaces. This may change in the future.
If a clip sets OfxImageClipPropIsMask or it only supports OfxImageComponentAlpha, then no colour space conversion is done to it, including linearisation, and it is presented as "unknown/unknown".
- GPU resource arbitration
The Baselight renderer can allocate all the VRAM on all the GPUs in the system for its own use. Plugins can make use of GPU resources but to avoid memory errors they must request memory be made available from the application, and they must only use resources on the GPU they are assigned.
A plugin which uses the OpenGL suite is allowed to use 256 MB of VRAM (in addition to the input and output textures). If the plugin needs more than this, it must set the instance property "uk.ltd.filmlight.AlwaysUsesVRAM" (int) to 1, and the instance property "uk.ltd.filmlight.DesiredVRAMRequired"[0] (double) to the amount of VRAM (in bytes) it requires in order to render. Optionally it can also set the instance property "uk.ltd.filmlight.DesiredVRAMRequired"[1] (double) to a larger amount of VRAM (in bytes) that it would ideally like to use.
A plugin which does not use the OpenGL suite but wishes to use GPU resources to perform its rendering of CPU images must set the instance property "uk.ltd.filmlight.AlwaysUsesVRAM" (int) to 1, and the instance property "uk.ltd.filmlight.DesiredVRAMRequired" (double) to the amount of VRAM (in bytes) it requires in order to render.
During OfxImageEffectActionRender, inArgs will include these properties: "uk.ltd.filmlight.CLPlatform" (pointer) - the OpenCL platform of the GPU the plugin is permitted to use "uk.ltd.filmlight.CLDevice" (pointer) - the OpenCL device of the GPU the plugin is permitted to use "uk.ltd.filmlight.CUDADevice" (int) - the CUDA device of the GPU the plugin is permitted to use (currently on Linux only) "uk.ltd.filmlight.AllocatedVRAM" (double) - the amount of VRAM (in bytes) that the plugin is permitted to use on that GPU
The plugin must only use resources on the specified GPU, and must not use more than the allocated VRAM.
At any time the host may call the action "uk.ltd.filmlight.ActionSetAllocatedVRAM" passing the same four arguments in inArgs. If "uk.ltd.filmlight.AllocatedVRAM" is less than the current VRAM usage (typically it will be set to zero) then the plugin must immediately release resources it holds on the GPU to reduce its VRAM usage to the specified amount.