The advantage of using the G’MIC GIMP notation is that After Effects users could write plugins that would be immediately compatible with the G’MIC Gimp plugin. As the processing code is handled in the bridge DLL anyway, these stubs only need some kilobyte of space. Since an AE plugin can only host one single plugin with a fixed parameter set and name within one file, I wrote a little pre-processor that creates small AE plugin stubs from a G’MIC collection file (like the G’MIC standard library). It can also optionally use inplace processing (for effects that don’t require re-assigning the input pointer) and can deal with multiple input layers.
The AE plugin can also parse the G’MIC # definitions and re-create the appropriate native AE UI elements like sliders, text boxes, color pickers, etc. It allows entering any G’MIC commands you want for sending to G’MIC. To test this bridge, I created an effect plugin using the Adobe After Effects SDK that sends the pixel buffers it receives from the host to the bridge DLL for processing. As the library uses a pure ANSI-C interface without any dependencies on G’MIC headers/libs, a MinGW compiled DLL/lib can however be used in Visual Studio and vice-versa. On Windows, this DLL can be compiled in both Visual Studio and MinGW, but since only MinGW supports OpenMP (which is essential for fast processing!), that is the preferred compilation platform. Think of it like a “CLI deluxe” C/C++ interface where in addition to the command line you can send pixel buffers for processing to it. In the last days, I have coded “G’MIC bridge”, a shared library/DLL interface for G’MIC that makes accessing G’MIC from other applications and compilers much much easier. Let me tell you about my recent project, making G’MIC effects usable in Adobe After Effects and Adobe Premiere Pro (other possible hosts or a generic OpenFX interface probably coming later).
0 kommentar(er)
