View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0000670Cinelerra-GG[All Projects] Featurepublic2025-02-12 16:062025-03-11 21:02
Reportersge Assigned ToPhyllisSmith  
PrioritynormalSeverityfeatureReproducibilityalways
Status acknowledgedResolutionopen 
Product Version 
Target VersionFixed in Version 
Summary0000670: User Defined Blend Algebra
DescriptionSometimes there appear again questions / complains regarding overlay blending in Cinelerra, that something appears strange, or not exactly that as in Gimp (or in whatever), or not in that art the user needs. Fighting such windmills seems not worth while.

The idea came to provide a new specific plugin where the user could program sufficiently short and simple blending algorithms according to his requirements. And of course, without demanding from the user too much programming skills.

The presented patch cgg-blendalgebra.diff.gz provides two similar plugins which try to realize this goal. The only modification to Cinelerra is the addition of these completely new plugins. Applying the patch to Cinelerra cannot break anything.

After applying the patch to Cinelerra sources, and before executing `make', make sure the new created scripts plugins/blendalgebra/BlendAlgebraCompile.pl and plugins/blendprogram/BlendProgramCompile.pl possess executable permissions. After successful `make', don't forget to run `make install': without several important files which must be installed, the new plugins cannot work.
Additional InformationAdvertisement
=============

To look on the example functions, there is 'Edit...' button in the respective plugin dialog, but you may need a text editor. By default, it is `emacs', and nothing has to be done if it is installed. If not, you can set your favorite editor via the corresponding environment variable, like those:

export CIN_EDITOR=kate
export CIN_EDITOR=nedit
export CIN_EDITOR='konsole -e vim'

If text editor is a console editor without its own GUI, it must be run from some terminal emulator, like `xterm' or `konsole'.

Example 1.
----------

Let's say, we are going to write our own implementation of the Arithmetic Subtract overlay function, according to the formula from CinelerraGG manual. Such a function, attached to the Blend Algebra plugin, could look as follows.

------------------------------------------------------------------------
BLEND_ALGEBRA_INIT /* this is a required statement */

COLORSPACE_RGB /* our working color space, can be also YUV or HSV */
PARALLEL_SAFE /* can be safely parallelized */
REQUIRE_TRACKS(2) /* refuse to work if only one track is given */

BLEND_ALGEBRA_PROC /* this is a required statement */

#define s 1 /* mnemonics for source and destination */
#define d 0

R_OUT = R(s) - R(d); /* for red, green, blue, alpha: */
G_OUT = G(s) - G(d); /* result = source - destination */
B_OUT = B(s) - B(d);
A_OUT = A(s) - A(d);

BLEND_ALGEBRA_END /* this marks the end of our program */
------------------------------------------------------------------------

And here is an Arithmetic Addition variant, working on any number of tracks.

------------------------------------------------------------------------
BLEND_ALGEBRA_INIT

COLORSPACE_RGB
PARALLEL_SAFE

BLEND_ALGEBRA_PROC

int i;

R_OUT = G_OUT = B_OUT = A_OUT = 0; /* preinitialize results */

for (i=0; i<TOTAL_TRACKS; i++) /* repeat for all tracks */
{
  R_OUT += R(i); /* accumulate sum for R,G,B,A */
  G_OUT += G(i);
  B_OUT += B(i);
  A_OUT += A(i);
}

BLEND_ALGEBRA_END
------------------------------------------------------------------------

Blend Algebra functions can be keyframable, i.e. switched between plugin keyframes. Untar the ovl2.tar.gz archive, load the ovl2.xml project and play it. You can see 30 different functions switched one after another. The source files of the functions have the suffix '.ba'.

Example 2.
----------

Let's look on the following short Blend Algebra function:

------------------------------------------------------------------------
BLEND_ALGEBRA_INIT

COLORSPACE_YUV
PARALLEL_SAFE
REQUIRE_TRACKS(2)

BLEND_ALGEBRA_PROC

Y_OUT = (Y(0)-Y(1))/2+0.5;
U_OUT = V_OUT = 0;
A_OUT = 1;

BLEND_ALGEBRA_END
------------------------------------------------------------------------

What do you think this is? It is nothing else as the famous `ydiff' program, written in less than 10 lines of code and working not externally, but directly inside a Cinelerra plugin. Although this is not yet so complete, the standard ydiff program has an argument to enhance or reduce the difference effect, but we can easily add it here, too:

------------------------------------------------------------------------
BLEND_ALGEBRA_INIT

COLORSPACE_YUV
PARALLEL_SAFE
REQUIRE_TRACKS(2)

BLEND_ALGEBRA_PROC

Y_OUT = (Y(0)-Y(1))/2*exp((KEY_A-0.5)*14*M_LN2)+0.5;
U_OUT = V_OUT = 0;
A_OUT = 1;

BLEND_ALGEBRA_END
------------------------------------------------------------------------

Here we changed only the expression for Y, adding a factor which depends on the KEY_A parameter in logarithmic scale. The KEY_A parameter itself is interactively controlled by the opacity slider in the Blend Algebra plugin dialog.

Good, the ydiff program additionally prints some statistics. This printout can also be implemented by us, although the program becomes slightly more complex:

------------------------------------------------------------------------
static int npix=0; /* these variables will accumulate statistics */
static float sum=0, sabs=0; /* parallelizing not possible here */

BLEND_ALGEBRA_INIT

COLORSPACE_YUV
REQUIRE_TRACKS(2)

printf ("sz=%8d err=%10g abs=%10g", npix, sum, sabs);
if (npix > 0) printf (" rel=%10g", sabs*256/npix);
printf ("\n"); /* here we print statistics in CGG console */
sum = sabs = 0; /* and clear accumulators for the next frame */
npix = 0;

BLEND_ALGEBRA_PROC

float diff;
diff = Y(0)-Y(1);
sum += diff; /* update accumulators */
sabs += ABS (diff);
npix ++;

Y_OUT = (Y(0)-Y(1))/2*exp((KEY_A-0.5)*14*M_LN2)+0.5;
U_OUT = V_OUT = 0; /* and make video track output */
A_OUT = 1;

BLEND_ALGEBRA_END
------------------------------------------------------------------------

The statistics is printed in the terminal emulator from which Cinelerra was started.

You can look in the ydiff.tar.gz archive. In the project ydiff.xml there are two identical tracks displaced by 1 frame. The ydiff.ba function from the archive has the commented out line #define NO_PRINTOUT. It works slowly because of statistics printout. If you uncomment this definition, statistics will be switched off, the function will run parallelized, noticeably faster.

Example 3.
----------

Untar the example archive transitions.tar.gz and load the project transitions.xml. It demonstrates how transitions-like effects can be imitated by a Blend Algebra function. Here, depending on the current value of the opacity slider from plugin's dialog, interpolated between keyframes, and the (X,Y) pixel coordinates, the function takes pixels of either track #0 or track 0000001.

Example 4.
----------

Untar the archive swap.tar.gz and load the project swap.xml. Now there is another companion plugin, Blend Program, with its function swap01.bp (ending with the .bp suffix). This example resembles the preceding one which imitated transition. The main difference here is that blend program does not return a function result, but modifies any given tracks directly. The program from this example swaps two tracks, along a transition controlled by keyframable interpolated opacity parameter. To see the effect, the bottom track is up-down reflected, and the top one has a mask applied, through which one can see that the bottom track is also changed.

Example 5.
----------

The preceding example was perhaps somehow artificial demo, not too close to reality. Let's now suggest another application which could be really useful. Untar the ck.tar.gz example and load firstly the project ck.xml.

There is a still picture and a second track with solid white background on bottom. The blend function attached is:

------------------------------------------------------------------------
BLEND_PROGRAM_INIT

COLORSPACE_HSV
PARALLEL_SAFE

BLEND_PROGRAM_PROC

if (ABS(H(0)-KEY_H) < KEY_A*100) A(0) *= SQR((H(0)-KEY_H)/KEY_A/100);

BLEND_PROGRAM_END
------------------------------------------------------------------------

It is a rather complete chromakey plugin, writable by user in only six lines of code! Isn't it cool! With these two new small plugins one can do really much! I do not know if a similar functionality exists in any other NLE.

Here if the 'Hue' component (in HSV color space) differs from that of the key color defined in the plugin dialog less than by the amount scaled by the opacity slider, the aplha component (the transparency) is set proportional to the squared difference (completely transparent where the two Hues are identical). You can open plugin dialog and turn the slider in it to the left and right and see its effect.

Now load another project from here, ckbg.xml. Now there is only one track with the same picture. Instead of the second one contained the background, there is one more Blend Program plugin attached, its function generating the desired background by itlesf. The background color is set via the color selection dialog of the Blend Program plugin GUI.

Introduction
============

Both plugins, Blend Algebra and Blend Program, are similar. I'll describe them together, pointing to differences where they come.

The essential object which defines, what actually takes place inside the plugin, is the piece of code, typically written by the user. Throughout the description I will use the word 'function' to denote this object for any of the two plugins.

Actually, Blend Algebra and Blend Program functions are ELF shared objects (see `man dlopen', `man dlsym') dynamically compiled and linked to the corresponding plugin in run time. These functions are for their plugins same as the plugin shared objects themselves for the main Cinelerra binary. But unlike the complex plugins, these functions are so simple that can be easily written bu users and manipulated not only in binary, but also in source forms.

An experienced user can have a number of such functions reused in many projects. Therefore having a user library of functions as well as a system library can be handy. This feature is provided by the plugins.

The functions work on individual pixels, one pixel at a time from all the tracks the plugin is attached to. Pixels are passed to functions in forms of color components in a definite color space. How exactly it is done, see the description later.

The main difference between the two plugins is the following.

Blend Algebra is like a function: it combines its arguments (tracks) and yields the result which is placed into the single configured track.

Blend Program does not produce a function result. Instead, it directly modifies its arguments (like a void function with side effect in C).

Which one should be used?

If more than one track is to be modified, Blend Program is the only choice.

If only one single track is to be processed, perhaps Blend Program would present more natural approach, and might compute slightly faster.

Any Blend Algebra function can be rewritten to become a Blend Program function. But if a function processes several tracks and modified only one, it will run faster in Blend Algebra form, and will get a few additional controls in the Blend Algebra plugin dialog.

The plugin is attached to a track as usual. Generally, it needs several tracks as arguments. If so, it has to be attached to that additional tracks as a shared effect, as usual for multitrack plugins.

Blend Algebra / Blend Program GUI
=================================

All the parameters described below are keyframable, including user functions themselves.

The top area of the dialog deals with programmatic aspects.
-----------------------------------------------------------

Program: (Function:)
--------------------

Here is the filename of the user's function source text. Although most convenient method to select the function is via the Attach... dialog, it is possible to enter its filename here directly. If the function pathname does not start with '/', it is interpreted relative to the main project directory. Empty function name means that no function will be executed here, the tracks will remain unchanged. If the entered filename does not exist, also nothing will be done (but in this case the user can create source file via the Edit... button).

Although entering any filename is possible here, it is highly recommended to use distinct suffixes: .ba for Blend Algebra, .bp for Blend Program.

Attach...
---------

This button opens the file selection dialog typical of Cinelerra. By default it shows only files with the proper suffixes (*.ba or *.bp), although this can be changed by specifying filter. As usual, the user can select an existing file, or directly enter filename. The user can exit the dialog with Cancel (changing nothing) or with OK. In the latter case, the selected function will be set as current, and its name will appear in the Program: text field above.

If the entered filename does not end with .ba (.bp), the corresponding suffix will be appended automatically. If the user for some reason has to use filename with another or no suffix (which is not recommended), he has to change the name directly in the Program: input field after exiting file selection.

The file selection dialog has six additional buttons specific to Blend Algebra / Blend Program.

The three buttons on top left change the current directory:

=>Project - go to the project directory (where the main project .xml file resides).

=>Userlib - go to user library.

=>Syslib - go to system library.

The three buttons on bottom left do simple file operations:

Copy to project - copies the currently selected function source file in the project directory.

Copy to userlib - copies the currently selected function source file to user library. There is no button to copy a function into the system library because the system library is meant for functions distributed with Cinelerra, which can get overwritten on reinstallation or uprgade.

What copying to/from project, userlib, or syslib is used for, see the section 'User library, system library, and Cinelerra project directories' below.

Edit...
-------

Open the currently selected function source file in the configured external editor. Which editor will be used, is defined by the environment variable $CIN_EDITOR. It must be a windowed editor, like GNU Emacs, or KDE's Kate, or Nedit, or ancient Xedit, not a bare console editor like vi. If you wish to use a console editor, it must be defined to run in a terminal emulator, like xterm, or KDE's Konsole, for example:

export CIN_EDITOR='konsole -e vi'
cin

Currently, emacs is defined as the default text editor (if CIN_EDITOR is not set). Which one should better be used by default? A good question... Is there a text editor which is guaranteed to exist in any Linux distribution? It might be vi, but then we need a guaranteed terminal emulator. Xterm? Isn't there a distribution where there is no xterm? Konsole? But if a distribution is not KDE, but GNOME based, there may be no Konsole...OK, at least GNU Emacs is well known since the last millennium, therefore let it be emacs for now.

The same button 'Edit...' exist also in the main plugin dialog, for the same purposes.

Refresh
-------

External editor, after pressing the Edit... button, is started in background. After having edited and saved a function, the user may leave editor on screen. Moreover, the user can edit a function externally, not from inside Cinelerra at all. In order not to check modification times of all the functions on each video frame, Cinelerra has to know when a function can get changed. Pressing Refresh signals Cinelerra, there is time to check functions, and eventually to recompile some of them.

How and under which conditions the functions are recompiled, see the description below.

Detach
------

This button clears the function name in the Program: input field, which means that no function will be used here, the tracks to which the plugin is attached will remain unchanged.

Color space:
------------

Here is defined, in which color space the frame pixels are to be passed to the function. The RGB, YUV, and HSV color spaces are supported. The most often used, and the default, is the choice 'auto', it means working in that color space which is required by the function itself. The fifth choice, 'of project', means to work in the native color space of the project (as defined in Settings->Format). If the required color space does not match the native one, pixel color components will be transformed to the required space, as floating point numbers. After returning from the function, pixels of the result will be transformed back to the native color space of the project.

Parallelize processing
----------------------

This checkbox (on by default) lets to execute user function code in parallelized (multithreading) manner, provided that the function itself supports this. How exactly the function code is executed, see the description later.

The middle area of the dialog is color specific.
------------------------------------------------

Inside the user written code, some illegal floating point operations may occur, like division by zero (producing Infinity), or square root from minus unity (producing NaN, not-a-number). Even if only legal, finite floating point numbers are computed, the results may go out of bounds. This dialog section controls, what to do in such cases.

Clip color values
-----------------

If this checkbox is on (the default), the function results first of all will be clipped to bounds. Clipping takes place before back transformation to the project color space. The bounds are defined as follows:

RGB: [0.0 .. 1.0] for R, G, B
YUV: [0.0 .. 1.0] for Y, [-0.5 .. +0.5] for U, V
HSV: [0.0 .. 360.0] for H, [0.0 .. 1.0] for S, V
Transparency: [0.0 .. 1.0] for Alpha

'H' color channel of HSV is brought into bounds trigonometrically by repeated rotating around 360 degrees, all the others by simple arithmetic clipping.

If the project color space is RGB(A)-8 Bit or YUV(A)-8 Bit, clipping occurs unconditionally because of intrinsically restricted dynamic range of 8-bit storage per channel. For RGB(A)-FLOAT clipping can be switched off. What occurs with unclipped pixels later, depends on further destinations in the Cinelerra video processing pipeline. Moreover, displaying drivers react on unclipped colors differently. For example, an RGB pixel with unclipped red component R=-1.0 and two other components G=B=0.0 is displayed as black (i.e. with R clipped to zero) by the OpenGL driver, but as red (i.e. taken with opposite sign) by the X11 driver. Explicit clipping in the plugin itself allows to eliminate such driver dependency.

Chroma key or substitution color:
---------------------------------

Even after (optional) clipping, there can still remain some non-finite results, like NaN. Such results are highly undesired and sould be eliminated as soon as possible. If any of color components, or alpha channel, is NaN, this complete pixel (all components) is replaced with the configured color and the configured opacity.

Select key color...
-------------------

This button opens Cinelerra color selection dialog to select the color which will be used as substitution for NaNs or infinities in the results.

Get from color picker
---------------------

With this button the user can copy the color fetched earlier in the color picker tool of the Cinelerra Compositor window.

Substitution opacity:
---------------------

This slider sets the opacity (alpha-channel) value to be used together with substitution color.

Substitution color and opacity are passed as additional arguments to user functions and can be used there for more or less artistic purposes, such as chroma keying.

The bottom area of the dialog has controls for the argument track ordering, similar to that of the well known Overlay plugin.

Track order:
------------

If the plugin is attached to N tracks, its user functions get pixels of that tracks numbered from 0 to N-1 (0-based, as in the C language). Here is defined, which of the tracks is to be the first (i.e. get number 0), either top or bottom, much like in the well known Overlay plugin.

The last two controls apply to Blend Algebra only.

Output track:
-------------

Here is defined, into which track (top or bottom) the result will be placed, much like in the Overlay plugin. Such an option is meaningless for Blend Program: its programs produce no result, but modify the arguments directly.

Hide input tracks, use output exclusively
-----------------------------------------

If this checkbox is on (the default), frames of the tracks the plugin is attached to, are cleared and then replaced by the function result. If the checkbox is off, only the output track frame is replaced by the result, all the other tracks are left unchanged. In comparison, the Overlay plugin has no such option, its input tracks are always cleared as if this checkbox were in the 'on' state.

All the parameters described above are keyframable, including user functions themselves. Namely, a plugin can have several functions attached in the same time and switch between them while rendering. The color and alpha channels of the substitution (key) color are interpolated between keyframes, the other parameters are switched.

User library, system library, and Cinelerra project directories
===============================================================

The user library directory is that defined by the environment variable $CIN_USERLIB, or, if CIN_USERLIB is not defined, $HOME/.bcast5lib as a fallback default. The functions for Blend Algebra reside there in subdirectory dlfcn/ba, for Blend Program - in dlfcn/bp (here 'dlfcn' stands for 'dynamic loaded function'). Having user functions in such a library, in a single place, makes it convenient to reuse the same functions in different projects. The 'Copy to userlib' button in the Attach... file selection dialog is handy to save such functions in the user library for future use.

The reason to define user library $HOME/.bcast5lib by default (and not $HOME/.bcast5) is the following. There is a common workaround, if a newer version of Cinelerra does not start, to delete $HOME/.bcast5 completely. Doing so, all user functions, should they be saved in such a library, would be deleted.

The system library is defined by the environment variable $CIN_DAT, the Cinelerra installation path, and there under the same subdirectories dlfcn/ba or dlfcn/bp. System library is meant for functions distributed with Cinelerra.

When a complete project is to be exported, or fed to a render farm, it can be often necessary to place all the resources under the same directory where the project .xml file resides. If some functions are used, which reside elsewhere (for example, in a user library), they could not be found after exporting the project to another computer. The 'Copy to project' button in the Attach... file selection dialog is used to copy such functions to the project directory in a convenient manner.

Blend Algebra / Blend Program workflow
======================================

As in any realtime plugin, the process_buffer() method in Blend Algebra / Blend Program gets a set of frames from the tracks the plugin is attached to. Then the following events take place.

As in any other plugin, it is checked if the configuration (the parameters) got changed. There is one parameter which requires special treatment, the user function name.

In order to prevent from resource consuming recompilation of the functions on each new frame, the plugin maintains in memory cache of the successfully compiled and attached functions. If at some keyframe the function name gets changed, the plugin searches if this function is already known and cached. Among other important function related objects, such as entry points, there is a timestamp, when this function was last checked to be up to date.

If the current function name is empty, it means a function is not used. Nothing else has to be done, all tracks are fetched and passed further in the processing pipeline unchanged.

If the function is not empty and seen for the first time, or its timestamp is older than the global timestamp, it is checked as follows.

File lock is placed on the function source file, to prevent from concurrent modification of object files in case of several simultaneous compilations.

The compilation script BlendAlgebraCompile.pl (BlendProgramCompile.pl) is started. The script checks if the resulting shared object file exists and is newer than the source, and recompiles it, if not (just like the well known `make' program).

The plugin checks if the shared object timestamp became newer than the timestamp of this function in cache (if any). If the cached version of the function in memory is up to date, it stays there. If not, the outdated function is detached from the plugin, the updated one is reattached, its entry points are fetched and memorized in cache. The function's timestamp in cache is set to the current time (as the function just has been checked).

While recompilation and dynamic linking various things may go wrong.

If the given function file does not exist, the program does nothing, as for empty function. No error message is shown in this case, to prevent possible deadlocking situations. This case is not very probable because usually the user will select functions via the Attach... dialog and clearly see if the chosen function exists.

If recompilation was unsuccessful (because of a syntax error), the error message is shown. More detailed diagnostics from the compiler can be seen in the terminal window in which Cinelerrs was started. Although it would be possible to fetch the compiler output and show it together with error message, modern compilers, like gcc, bring more descriptive coloured diagnostics, better than we can show in a Cinelerra dialog.

If compilation succeeded, but dynamic linking did not, error message is shown. In case of any error, the failed function is marked with the current timestamp in cache, so that such error messages appear only once before global timestamp gets updated.

Updating global timestamp forces all cached functions to be checked for recompilation at their first access. The global timestamp itself is updated by the following events: changing function name, pressing Edit... or Refresh button, exiting the Attach... dialog with the OK button.

If currently active function is ensured to be up to date and correctly attached, the plugin fetches video frames from all the affected tracks, with the important parameters like frame width and height. Then the 'INIT' phase of the function is executed (once for each frame). Here, several important parameters are requested, which are defined by the function. They are:

Working color space needed inside the function. If it is not the same as the color space of the project, then color space conversions have to be done.

The required number of tracks the function works on. If less than the required number of tracks is available, error message is shown and the function is not executed.

Whether the function supports parallelizing or not. If the function does not claim parallelizing support, it will be executed sequentially independently on the corresponding checkbox in the plugin GUI.

After this preparation phase, the processing itself takes place. In case of sequential flow, the following is done, for each frame pixel individually.

For each input track, the corresponding pixel is splitted to color components according to the actual color space of the project. All color components are converted to float (type of the C language) in the ranges [0.0 .. 1.0] for R, G, B, A, Y or [-0.5 .. +0.5] for U, V. If the project color space has no alpha channel, the alpha component is set to 1.0.

If the function requires other color space than the project uses, the necessary conversions are performed. The key color components (selected in the plugin GUI) are also converted to the function color space in the same manner.

For Blend Algebra, the values for output are preinitialized from that track which the output is to go to. All the other tracks are cleared if the corresponding checkbox in the plugin GUI says to do so. For Blend Program, this step is not needed.

The user function is called with the parameters: actual number of tracks, 4 arrays for the 4 color components (dimensions are equal to number of tracks), 4 key color components, current pixel coordinates x, y (upper left frame corner is (0,0), lower right is (width-1,height-1), width and height. For Blend Algebra, placeholders for the result additionally.

The user function returns. First of all, the color components of the relevant pixels are clipped to bounds if the corresponding checkbox in the plugin GUI is on. Relevant for Blend Program are pixels of all the tracks (all tracks can be modified), for Blend Algebra the result only.

After optional clipping, the color components are checked for not being NaNs. If so, the pixel is replaced with substitution color.

Then backconversion to the project color space is performed.

If the project has no alpha channel, but the function returned something not equal to 1.0, alpha channel is simulated as if an opaque black background were used.

If the project color space is not FLOAT, unconditional clipping followed by 8-bit transformation takes place.

For Blend Algebra, the result is placed to the right output track. For Blend Program, this step is unnecessary, all tracks are modified in place.

Then the loop is repeated for the next pixel in a row, next row in a frame, next frame in the whole sequence...

If the function is to be run parallelized, the necessary number of threads is created (as defined in Settings->Preferences->Performance, Project SMP cpus). Although it might seem that running parallel on 1 cpu be the same as running sequential, strictly speaking it is not the case. To run parallel on 1 cpu, an extra processing thread is still created, while sequential execution takes place inside the main plugin thread. This could induce some subtle differences if the function uses static variables inside or something else which is thread unsafe.

Syntax of Blend Algebra / Blend Program functions
=================================================

Blend Algebra / Blend Program functions are written in C (not C++, for simplicity), and with usage of a set of special cpp macros hiding from the user all the Cinelerra internals. This approach allows to write functions of moderate complexity with almost no background in C programming. All macros defined for user functions are written in capital letters.

A typical Blend Algebra function consists of the following logical blocks.

------------------------------------------------------------------------
<optional static variable definitions>

BLEND_ALGEBRA_INIT

<macros and/or C statements for the INIT (preparation) phase, will be executed once before processing of each frame>

BLEND_ALGEBRA_PROC

<macros and C statements for the PROC (processing) phase, will be executed repeatedly for each pixel in the frame>

BLEND_ALGEBRA_END
------------------------------------------------------------------------

The macro BLEND_ALGEBRA_STOP terminates execution of the INIT or PROC phase immediately and returns to the calling plugin.

The structure of a Blend Program function is the same, only the word 'ALGEBRA' in all macros must be changed to 'PROGRAM', here and below.

The following macros can be used in the INIT phase.

COLORSPACE_RGB
COLORSPACE_YUV
COLORSPACE_HSV

Declare the working color space inside the user function. If there is no such declaration, the native color space of the project (RGB or YUV) will be used.

REQUIRE_TRACKS(<no of tracks>)

Declares the minimum required number of tracks the function uses. If the effect is attached to more tracks, it is OK. If there are less tracks, it is an error, and the function is not executed.

The absence of such declaration means that the function can process any number of tracks (one or more).

PARALLEL_SAFE

This declaration means that it is safe to execute the function in parallel. Without this statement function will be executed sequentially, independent on the state of the parallelization checkbox in the plugin GUI.

The following special variables (macros) can be used for queries.

PARALLEL_REQUEST

1 == parallelization requested in the GUI
0 == parallelization switched off

TOTAL_TRACKS

The actual number of tracks passed to the function.

WIDTH, HEIGHT

The dimensions of processed frames, in numbers of pixels.

The following variables (macros) can be used in the PROC phase.

TOTAL_TRACKS, WIDTH, HEIGHT - can be used as well.

R(i), G(i), B(i)
Y(i), U(i), V(i)
H(i), S(i), V(i)
A(i)

Color (and alpha) components of pixel from i-th track. Tracks numbering is 0-based, as standartized for C arrays. Although it could be possible to write macros for 1-based indexing, it does not look as a good idea as it would lead to confusion with standard array definitions and regular C for-loops. So, the first track has number 0, the last one - number TOTAL_TRACKS-1. All the color components are floating point values of the C type 'float'.

Here the letters R, G, B, H, S, V, etc. are for readability. If the user has declared COLORSPACE_RGB, and then written something like H(i), it does not mean that he should get the H-component of color autoconverted to the HSV color space. Actually R, Y, H are mutually identical to the 1-st color component, so are G, U, S to the 2-nd, and B, V to the 3-rd one.

Do we need such a true conversion inside a user function? Can a function need more than one color space simultaneously? I do not yet imagine such a case. Should it come, we can consider adding the explicit color space conversion possibility.

KEY_R, KEY_G, KEY_B
KEY_Y, KEY_U, KEY_V
KEY_H, KEY_S, KEY_V
KEY_A

Corresponding color components of the key (substitution) color, in the working color space of the function, and the opacity slider.

R_OUT, G_OUT, B_OUT
Y_OUT, U_OUT, V_OUT
H_OUT, S_OUT, V_OUT
A_OUT

Color components for the result, for Blend Algebra only. Blend Programs return no result, and do not have such definitions.

PIX_X, PIX_Y

Integer X and Y coordinates of the current pixel in its frame, in the ranges of [0 .. WIDTH] and [0 .. HEIGHT], respectively.

CLIP_RGB(i)
CLIP_YUV(i)
CLIP_HSV(i)
CLIP_RGBA(i)
CLIP_YUVA(i)
CLIP_HSVA(i)
CLIP_A(i)

These macros clip color components of the i-th track to the bounds appropriate in the respective color space.

CLIP_RGB_ALL
CLIP_YUV_ALL
CLIP_HSV_ALL

Clip all color components (including alpha) for all tracks.

CLIP_RGB_OUT
CLIP_YUV_OUT
CLIP_HSV_OUT
CLIP_RGBA_OUT
CLIP_YUVA_OUT
CLIP_HSVA_OUT
CLIP_A_OUT

Like clipping track color components, but for the result of a Blend Algebra function. Not relevant for Blend Programs.

Clipping is done according to the inherent bounds of the respective color space, as follows:

RGB: [0.0 .. 1.0] for R, G, B
YUV: [0.0 .. 1.0] for Y, [-0.5 .. +0.5] for U, V
HSV: [0.0 .. 360.0] for H, [0.0 .. 1.0] for S, V
Transparency: [0.0 .. 1.0] for Alpha

'H' color channel of HSV is brought into bounds by repeated rotation around 360 degrees, all the others by simple clipping.

ABS(x), SQR(x), MAX(x,y), MIN(x,y) - absolute value, square, max and min values for floating point arguments. Can be used in any phase of a function.

TO_RAD(x), TO_DEG(x) - conversion from degrees to radians and vice versa.

CLIP(x,y,z)
CLAMP(x,y,z)

Both macros clip the 'x' argument to bounds between y and z. CLIP returns value leaving x unchanged. CLAMP assigns that value to x.

All the macros are defined in the text header $CIN_DAT/dlfcn/BlendAlgebraStart for Blend Algebra and the analogous header Blend ProgramStart for Blend Program in the same dlfcn subdirectory of the Cinelerra installation directory. These headers are prepended to the user functions while compilation. The user with a basic C knowledge can easily understand what happens in these headers.

Of course, it is allowed to use any valid C statements inside user functions. As they are linked with -lm, the standard C math library, and of course with glibc, almost any mathematical or C library function can be called. C-style comments can also be used, and are welcome.

The compilation script
======================

Compilation of Blend Algebra and Blend Program functions is carried out by Perl script BlendAlgebraCompile.pl and BlendProgramCompile.pl, correspondingly. Both scripts are distributed in the dlfcn subdirectory of $CIN_DAT, the Cinelerra installation directory. Much like the famous ContextManual.pl script of Context Help, the system script at the first call is copied into $CIN_CONFIG ($HOME/.bcast5) where can be edited by the user and adapted according to his needs.

While a regular compilation, the script works in that directory where the function source file resides. Firstly, the BlendAlgebraStart (BlendProgramStart) header is prepended to the source to produce an intermediate file with the '.c' suffix. This C source is compiled by the system C compiler (gcc by default) and linked with -lm to produce the shared object ready for dynamic loading (attaching to the plugin).

Usually the script is executed by the respective Cinelerra plugin when a user function is to be compiled. But the script can also be run by the user explicitly. Execution can be controlled by options starting with the '-' character, the first argument not starting with '-' being the function name to compile. The following options are recognized.

-compile don't check modification time, compile unconditionally
-cfile don't remove intermediate .c file
-opt add optimizing options to compiler command line
-debug add debugging options to compiler command line
-warn add warning options to compiler command line
-edit open function source in text editor
-verbose verbose execution
-noapi don't copy itself to $HOME/.bcast5
-h, -help, -? print short help and current configuration

In the beginning of the script some variables can be redefined according to the user's needs: the C compiler executable, compiler options for optimization or debugging, text editor executable.

Environment variables influencing plugin configuration
======================================================

The following environment variables are taken into account in various places in Blend Algebra / Blend Program.

$CIN_CC: C compiler executable (default: gcc)

$CC: C compiler executable if $CIN_CC is not defined (default: gcc)

$CIN_EDITOR: text editor (default: emacs)

$CIN_DAT (set by Cinelerra binary): Cinelerra installation directory. The Blend Algebra / Blend Program system library with scripts, headers, and functions distributed with Cinelerra resides in the subdirectory $CIN_DAT/dlfcn.

$CIN_CONFIG (set by Cinelerra binary): user's config directory, usually $HOME/.bcast5

$CIN_USERLIB: user's library (default: $HOME/.bcast5lib). User's functions reside in the subdirectory $CIN_USERLIB/dlfcn.

What comes in the distribution
==============================

In the distribution 30 Blend Algebra functions are provided for all the 30 CinelerraGG overlay modi, according to the formula defined in CinelerraGG manual. In principle, they are not needed in themselves: the built in overlayer engine is OpenGL accelerated and runs faster. Nevertheless, these functions can be handy as starting examples for users who may like to modify formula in some way. Secondly, their behavior differs from that of the standard overlayer in several aspects:

Overlayer produces different results in RGB and YUV color spaces, Blend Algebra yields identical results independently on color space of the project.

In RGB(A) FLOAT color space overlayer results can get out of bounds, and then be rendered differently depending on the display driver used. In Blend Algebra clipping, when switched on, can prevent from this undesirable effect.

Overlayer always clears its input frames. In Blend Algebra the user has a choice, either to clear them, or to leave intact.

Besides the 30 example overlay functions, we provide the ydiff simulator function actually representing the complete ydiff application running inside Cinelerra plugin.

Two functions are provided in forms of Blend Programs: the chromakey and background functions. They can also serve as nice starting points for further user's experimentations.

`make install' copies the functions into the Cinelerra's bin directory in source (*.ba, *.bp) and binary (*.so) forms by `cp -a', to preserve modification times of the files. Otherwise, if modification time of the function source accidentally becomes newer than that of its binary, the plugin will repeatedly try to recompile the function. And if they are installed system-wide, so that the user has no permission to modify them, such recompilations will fail.

Assorted considerations
=======================

Caveats
-------

User's functions can have bugs. By axiom, any program has at least one more undetected bug, and there is proof that any program has infinite number of undetected bugs.

Most probable bugs in a user function can be illegal arithmetic such as division by zero or logarithm of a negative number (FPE, floating exception), and out of bounds indexation of arrays (usually leading to SEGV, segmentation violation).

Most modern processors don't generate FPE. Instead, they generate NaN as the result of an illegal arithmetics. After calling user functions the plugins test the results not to be NaN and replace them with the configured substitution color if necessary.

SEGV is more problematic. If the user has written in his function, let's say, REQUIRE_TRACKS(2), and then accessed R(1000000), most probably Cinelerra binary will crash. Although theoretically it could be possible to trap SEGV via sigaction()/setjmp()/longjmp(), in Cinelerra it is problematic. In a multithreaded application, which Cinelerra is, only one signal handler for all its threads in the same time is allowed, and Cinelerra has already its SEGV handler which we are not allowed to overwrite. Thus, the user is responsible for his indexation bugs, where most attention has to be paid, as usually, to the off-by-one errors, like referencing elements like R(TOTAL_TRACKS) (the last legal element being R(TOTAL_TRACKS-1)), or R(i) where i has been decremented to -1.

The user is allowed to call any C function from the -lm and glibc libraries. But some functions are not thread safe (which means, PARALLEL_SAFE macro should not be used), and some others have undesired side effects. For example, should the user write inside his function something like exit(R(0));, the whole Cinelerra would immediately halt. The user is left to imagine what would happen after the following expression, for example:

R_OUT = R (system ("killall -9 X"));

Acceleration
------------

Blend Algebra / Blend Program functions are not accelerated. Hardware acceleration would mean, the function algorithm is to be programmed as an OpenGL shader. I think, if the user is sufficiently experienced to write in the OpenGL shader language, it would be not so difficult for him to write a complete Cinelerra plugin.

Nevertheless, functions can be parallelized (using the load balancing engine of Cinelerra), and can be compiled with optimization (switched on by default). The default optimizing option (defined in BlendAlgebraCompile.pl and BlendProgramCompile.pl) is -O2. One can redefine it to -O3 or -Ofast, for example. However, it has to be noted that using -Ofast or -ffast-math options can lead to ignoring some IEEE rules for floating point math, namely, some intrinsic tests on infinities or NaN can yield unpredicted results.

Debugging
---------

Although user's function can be compiled with debugging option such as -g or -ggdb, debugging functions can be tricky. The programmer can set breakpoint into the function only after its code has been loaded in memory by the plugin, and set another breakpoint into plugin only after that plugin itself has been attached to a track. Moreover, a function can get detached from memory under some conditions, and then its breakpoints will be lost.

Debugging printout inside the PROC phase, although possible, would seem too verbose: the PROC phase would be called for full-HD footage 2073600 times per frame! Here perhaps one could make use of PIX_X, PIX_Y coordinates at some selected place like in an example:

if (PIX_X == 320 && PIX_Y == 200) printf ("%f %f %f\n", R(0), G(0), B(0));

Editing functions
-----------------

Thus far, to edit user functions an external editor has to be used. Although it would be possible to implement editing directly in Cinelerra via some multiline scrollable text field, this could hardly present features comparable with a dedicated text editor. I'd say, we should not do it.

Portability
-----------

The current implementation should be rather portable. One prerequisite is a working C compiler. That compiler which was used to build Cinelerra itself, will work by definition. But other compilers perhaps are compatible as well. I tested at least functions which were compiled with clang, attached to Cinelerra compiled with gcc, they worked.

If the user has built Cinelerra from sources, he definitely has a working C compiler. But if one has installed the binary distribution, then the compiler clearly is a prerequisite.

Will Blend Algebra / Blend Program work under Cinelerra in an AppImage form? Perhaps they should if a C compiler is installed. Can somebody who is familiar with AppImages test this?

What about other architectures? It has to be tested. If some other architecture is Unix-like, and is ELF based, the things should be portable.

But under Windows it is not the case. Unlike Unix/Linux, Windows does not have ELF shared objects, and its DLLs are not fully position independent. There exists a definite probability of conflicts between virtual addresses which can prevent some user's functions from dynamic load. But does a version of Cinelerra exist for Windows at all? No idea so far...
TagsNo tags attached.

Activities

PhyllisSmith

PhyllisSmith

2025-03-11 21:02

manager   ~0005788

@sge
Patch applied. Thank you again.
sge

sge

2025-03-11 16:35

reporter   ~0005787

@PhyllisSmith
I found a tiny bug: one parameter, output track of Blend Algebra, was absent in copy and interpolate functions.
Moreover, as I ported the plugins to CinHV, it crashed in several places while closing or resizing dialogs because of race conditions between threads of different windows, so I had to find a fix for that. Although CinGG does not crash in similar scenario, I think it would be safer to apply the precautions to CinGG as well.
Please apply this small patch.
No user visible changes.

cgg-blend-pars.diff.gz (2,351 bytes)
PhyllisSmith

PhyllisSmith

2025-03-06 01:58

manager   ~0005786

@sge
@IgorBeg
@Andrea_Paz
@Andrew-R
Checked in the patch -- I like the way Refresh works now. It makes it easier to see immediate results and avoids confusion for those of us who do not always read all of the directions and for casual users.

Also checked in earlier today for the 2 new Blend plugins, IgorBeg's icons and the short info/plugins.txt that you see if "Info on" is enabled in the Resources window. The "info" is not really needed any more because of the Alt-h help, but it does provide a quick one liner and was added before the availability of Alt-h.
sge

sge

2025-03-05 15:46

reporter   ~0005784

@PhyllisSmith
Please apply this cgg-chdir patch. As the result:
1) Buttons =>project, userlib, syslib should reach target dir also with empty function name.
2) Refresh should induce immediate recompilation of that function (if any) which is under timeline cursor (if source became newer than shared object). Other functions (away from cursor) will be recompiled on first access.

cgg-chdir.diff.gz (802 bytes)
PhyllisSmith

PhyllisSmith

2025-02-25 20:20

manager   ~0005782

Last edited: 2025-02-25 20:21

View 2 revisions

 @sge
Patch applied, compiled, and checked into GIT today. I am testing as I edit the Manual latex version from Andrea, but it is slow going for me. As I flail in my testing, I will probably execute weird stuff that may expose issues.
sge

sge

2025-02-25 16:34

reporter   ~0005781

With filebox it was still not all good. If one presses Attach... while function name not empty, and is in some other directory than the project is, and no visited history yet, then file dialog is opened not in the expected directory where the given function should be. This behavior can be very inconvenient.
I introduced explicit updating history between filebox creation and its create_objects(). Despite this code block addition, I think, the whole logic became slightly less shamanic, and there should be no reason for SEGV.
Please apply the filebox3 patch from here to the current git (i.e. in addition to all the preceding patches already applied).

cgg-filebox3.diff.gz (2,119 bytes)
PhyllisSmith

PhyllisSmith

2025-02-23 01:56

manager   ~0005780

@sge
@Andrea_Paz
Checked into GIT source, cgg-blendreadme.diff, with the doc/Makefile change and included README.algebra file. Good idea to put in doc directory for easy access. P.S. still working on latex manual.
PhyllisSmith

PhyllisSmith

2025-02-21 01:55

manager   ~0005779

@sge
Checked into GIT, the patch for blendalgebra/blendprogram.C earlier today.
Until I get a better understanding of the buttons/Copy to project (by going over the latex/Andrea documentation version + your changes), I can not tell if they are working as designed or not. They do not seem to cause any issues but will be testing parts while reading the documentation.
sge

sge

2025-02-20 05:21

reporter   ~0005778

@PhyllisSmith
On filebox quirks. It should be tested, if the buttons =>Project, =>Userlib, =>Syslib, Copy to project still work. The need of these quirky shamanic calls to update visited directories history was the problem that filebox forgot the target directory because it had not been added to history in time. To my feeling (in my tests) the buttons usually work. Sometimes a button did not enter the needed directory at the first click, but entered correctly at the second click on the same button.
On the documentation. I suggest the patch here. It adds the new text file README.blendalg to the doc directory, and one line to Makefile so that `make install' copies this readme into the installation directory bin/doc. So this information will be always at hand in plain text form.
I have slightly updated this readme in comparison with the initial BT description, namely given the information about added function parameter HAS_ALPHA.

cgg-blendreadme.diff.gz (13,924 bytes)
PhyllisSmith

PhyllisSmith

2025-02-19 21:48

manager   ~0005777

@sge
The new/alternative patch works GREAT when tested with my failing Cinelerra_rc PLUS it has the added benefit for everyone to retain the value of the Function that was keyed in from the previous session since many users always put their stuff in the same directory. Thank you -- I will check into GIT the next time I boot the desktop.
sge

sge

2025-02-19 14:47

reporter   ~0005776

@PhyllisSmith
Please apply this filebox2 patch instead of the preceding one, perhaps it can be better.

cgg-filebox2.diff.gz (435 bytes)
sge

sge

2025-02-19 05:48

reporter   ~0005775

@PhyllisSmith
I saw the finally illegal BC_ListBox reference where 'this' class instance was at address 0x0. It was because BC_ListBox is created at the time filebox creates its numerous child widgets. But the buggy reference came from the update_history() function before create_objects() was called, i.e. when BC_ListBox was not yet created at all.
But if I call create_objects() first, another quirk comes: some recently visited directory memorized in BC_ListBox earlier is taken instead of the needed directory, as a consequence the buttons '=>Project', '=>Usrlib' and similar become not working.
This is definitely a bug, but don't worry, we do know exactly the reason and we'll get it working in some way. Don't lose your specific .bcast5 so we can test it once more.
It is good that the patch from yesterday worked, the guess has been confirmed. Don't apply it if it has drawbacks, I'll solve it in some other way.
PhyllisSmith

PhyllisSmith

2025-02-18 23:41

manager   ~0005774

@sge
It does not crash when the patch is applied, but unfortunately it negatively affects at least one other filebox -- File=>Load files loses the "Directory" value and returns to the default rather than what was last there. I did not check other fileboxes for similar results.

Also of note, I ran gdb without the patch again and noted that when it crashed, got the following:
  (gdb) p* this
  Cannot access memory at address 0xff0000ffff0000ff
  (gdb) p this
  $1 = (BC_ListBox * const) 0xff0000ffff0000ff
sge

sge

2025-02-18 16:41

reporter   ~0005773

@PhyllisSmith
Against SEGV - please apply this tiny patch and test the case again. If it still crashes in some further place, please backtrace to me.

cgg-filebox.diff.gz (290 bytes)
Andrea_Paz

Andrea_Paz

2025-02-18 08:04

manager   ~0005772

In Arch, transition.xml has the “reverse play” green with plugin active and black without plugin. In swap.xml the reverse play is black both with plugin and without. Ovl2.xml on the other hand is fine in reverse, with and without plugin.
sge

sge

2025-02-18 02:15

reporter   ~0005771

@IgorBeg
@PhyllisSmith
I tried earlier playing backward. Unfortunately, with my very short test projects I saw usually black screen, even without any plugins attached, with bare unmodified video tracks. And the same when setting cursor somewhere in the middle of timeline. No great idea why so. Indexes?
When rendering, brendering, all OK.
Renderfarm (2 renderers) - starts and finishes fine, the part of output from the 2nd renderer black screen, same with no plugins attached. Too short for renderfarms?
Perhaps will try once again...
PhyllisSmith

PhyllisSmith

2025-02-17 22:44

manager   ~0005770

@sge
Unless you are just curious, I would not be concerned about the Segv I get - (1) I should not be clicking on Attach without a Function keyed in (2) My setup is unusual and (3) Workaround is easy. However, attached is the gdb backtrace and my Cinelerra_rc file. Deleting all of the FILEBOX_ lines in this startup file still resulted in the segv. I still will work on modifying this startup file to find the culprit.

Also, not sure if you saw the previous note from @IgorBeg who tested your included xml files.

And, as already noted in the mailing list, BlendAlgebra and BlendProgram are now checked into git. They are a huge and most helpful addition so that now anyone who wants a different blend version can have it -- it is interesting that SVG, Gimp, Porter Duff, and who knows what other programs have some different variations and there is no standard. Unfortunately, making changes to the existing blending in CinGG would cause difficulty for some previously existing projects.

segv_problem.tar.gz (8,809 bytes)
IgorBeg

IgorBeg

2025-02-17 18:33

reporter   ~0005769

I dowloaded the sge's test files and tested them, on UbuntuStudio_16.04, thanks to the "cin-x86-64_blendplugins.AppImage" by Phyllis (thanks Phyllis).
I just loaded the sge's xml(s) (Project) files and Played.
- transitions.xml
- ovl2.xml
- swap.xml
- ck: ck.xml and ckbg

If I do Play Forward (Numpad 3) it seems to work good; but if I do Play Reverse (Numpad 6), from the end of the timeline, on the Compositor I see only green screen, for "transitions.xml", and black screen, for "swap.xml".
PhyllisSmith

PhyllisSmith

2025-02-17 15:36

manager   ~0005768

@Andrea_Paz
About the appimage results you had -- not sure why it did not work for you but not to worry -- it could be anything.
sge

sge

2025-02-17 14:04

reporter   ~0005767

@PhyllisSmith
I expected that filebox should work with a fresh .bcast5. But I think, the quirk was not because of two monitors. Perhaps there was something filebox-related in the rc-file, for example, some earlier memorized file or directory path.
You can try the following.
1. Start again with the old .bcast5 (with two monitors). Check if it crashes. If possible, get backtrace.
2. When CinGG is not running, edit Cinelerra_rc with a text editor, namely, remove from it all lines starting with 'FILEBOX_'.
3. Start CinGG again and check if something changes.
PhyllisSmith

PhyllisSmith

2025-02-16 20:27

manager   ~0005766

Last edited: 2025-02-16 23:16

View 2 revisions

 @sge
Short response to SEGV problem -- it is my existing root $HOME/.bcast5/Cinelerra_rc setup. I will attempt to track down which parameter causes the error.

Quote by SGE: "To open file selection dialog, there is a rather shamanic preparation sequence. In the case of empty program name the project directory is given to the dialog to get it opened at least in the probable place."

Yes, the "PROBABLE PLACE" is the problem when I login as root using the $HOME/.bcast5/Cinelerra_rc that I have always used. It just so happens that ubuntu 16 system I am using has 2 monitors with the default X terminals coming up on the second monitor. When I start CinGG, it loads the program start display on monitor 2 but then the 4 windows load on monitor 1 (a convenience as setup by Bill a long time ago). If I login as an ordinary user, it works just fine with monitor 2 being the default "probable place", but this is because it created a new .bcast5 since I never logged in as an ordinary user on that system before. And as you noted, if I use a new .bcastx as root: "CIN_CONFIG=/tmp/bcast5 bin/cin" it works just fine -- except for my personal inconvenience of working with CinGG on monitor 2! Forgot to mention that if I actually keyin the Function box a non-existent filename, it works but does come up on monitor 2 rather than 1
Andrea_Paz

Andrea_Paz

2025-02-16 10:50

manager   ~0005765

@Phyllissmith
@All
Unfortunately, the appimage does not start for me. In the terminal I have these lines:

lang changed from '' to 'it_IT:it_IT:it'
BC_DisplayInfo::gl_fb_config failed
build plugin index for: /tmp/.mount_cin-x8PaXmlM/usr/bin/plugins
int PluginServer::open_plugin(int, Preferences*, EDL*, Plugin*):
PluginServer::open_plugin: load_obj /tmp/.mount_cin-x8PaXmlM/usr/bin/plugins/themes/theme_blond.plugin = /tmp/.mount_cin-x8PaXmlM/usr/bin/plugins/themes/theme_blond.plugin: impossibile abilitare lo stack eseguibile come richiesto dall'oggetto condiviso: Argomento non valido
int PluginServer::open_plugin(int, Preferences*, EDL*, Plugin*):
PluginServer::open_plugin: load_obj /tmp/.mount_cin-x8PaXmlM/usr/bin/plugins/themes/theme_blond_cv.plugin = /tmp/.mount_cin-x8PaXmlM/usr/bin/plugins/themes/theme_blond_cv.plugin: impossibile abilitare lo stack eseguibile come richiesto dall'oggetto condiviso: Argomento non valido
int PluginServer::open_plugin(int, Preferences*, EDL*, Plugin*):
PluginServer::open_plugin: load_obj /tmp/.mount_cin-x8PaXmlM/usr/bin/plugins/themes/theme_blue.plugin = /tmp/.mount_cin-x8PaXmlM/usr/bin/plugins/themes/theme_blue.plugin: impossibile abilitare lo stack eseguibile come richiesto dall'oggetto condiviso: Argomento non valido
int PluginServer::open_plugin(int, Preferences*, EDL*, Plugin*):
PluginServer::open_plugin: load_obj /tmp/.mount_cin-x8PaXmlM/usr/bin/plugins/themes/theme_blue_dot.plugin = /tmp/.mount_cin-x8PaXmlM/usr/bin/plugins/themes/theme_blue_dot.plugin: impossibile abilitare lo stack eseguibile come richiesto dall'oggetto condiviso: Argomento non valido
int PluginServer::open_plugin(int, Preferences*, EDL*, Plugin*):
PluginServer::open_plugin: load_obj /tmp/.mount_cin-x8PaXmlM/usr/bin/plugins/themes/theme_bright.plugin = /tmp/.mount_cin-x8PaXmlM/usr/bin/plugins/themes/theme_bright.plugin: impossibile abilitare lo stack eseguibile come richiesto dall'oggetto condiviso: Argomento non valido
int PluginServer::open_plugin(int, Preferences*, EDL*, Plugin*):
PluginServer::open_plugin: load_obj /tmp/.mount_cin-x8PaXmlM/usr/bin/plugins/themes/theme_cakewalk.plugin = /tmp/.mount_cin-x8PaXmlM/usr/bin/plugins/themes/theme_cakewalk.plugin: impossibile abilitare lo stack eseguibile come richiesto dall'oggetto condiviso: Argomento non valido
int PluginServer::open_plugin(int, Preferences*, EDL*, Plugin*):
PluginServer::open_plugin: load_obj /tmp/.mount_cin-x8PaXmlM/usr/bin/plugins/themes/theme_hulk.plugin = /tmp/.mount_cin-x8PaXmlM/usr/bin/plugins/themes/theme_hulk.plugin: impossibile abilitare lo stack eseguibile come richiesto dall'oggetto condiviso: Argomento non valido
int PluginServer::open_plugin(int, Preferences*, EDL*, Plugin*):
PluginServer::open_plugin: load_obj /tmp/.mount_cin-x8PaXmlM/usr/bin/plugins/themes/theme_neophyte.plugin = /tmp/.mount_cin-x8PaXmlM/usr/bin/plugins/themes/theme_neophyte.plugin: impossibile abilitare lo stack eseguibile come richiesto dall'oggetto condiviso: Argomento non valido
int PluginServer::open_plugin(int, Preferences*, EDL*, Plugin*):
PluginServer::open_plugin: load_obj /tmp/.mount_cin-x8PaXmlM/usr/bin/plugins/themes/theme_pinklady.plugin = /tmp/.mount_cin-x8PaXmlM/usr/bin/plugins/themes/theme_pinklady.plugin: impossibile abilitare lo stack eseguibile come richiesto dall'oggetto condiviso: Argomento non valido
int PluginServer::open_plugin(int, Preferences*, EDL*, Plugin*):
PluginServer::open_plugin: load_obj /tmp/.mount_cin-x8PaXmlM/usr/bin/plugins/themes/theme_suv.plugin = /tmp/.mount_cin-x8PaXmlM/usr/bin/plugins/themes/theme_suv.plugin: impossibile abilitare lo stack eseguibile come richiesto dall'oggetto condiviso: Argomento non valido
int PluginServer::open_plugin(int, Preferences*, EDL*, Plugin*):
PluginServer::open_plugin: load_obj /tmp/.mount_cin-x8PaXmlM/usr/bin/plugins/themes/theme_unflat.plugin = /tmp/.mount_cin-x8PaXmlM/usr/bin/plugins/themes/theme_unflat.plugin: impossibile abilitare lo stack eseguibile come richiesto dall'oggetto condiviso: Argomento non valido
int PluginServer::open_plugin(int, Preferences*, EDL*, Plugin*):
PluginServer::open_plugin: load_obj /tmp/.mount_cin-x8PaXmlM/usr/bin/plugins/video/chromakeyavid.plugin = /tmp/.mount_cin-x8PaXmlM/usr/bin/plugins/video/chromakeyavid.plugin: impossibile abilitare lo stack eseguibile come richiesto dall'oggetto condiviso: Argomento non valido
int PluginServer::open_plugin(int, Preferences*, EDL*, Plugin*):
PluginServer::open_plugin: load_obj /tmp/.mount_cin-x8PaXmlM/usr/bin/plugins/video/chromakeyhsv.plugin = /tmp/.mount_cin-x8PaXmlM/usr/bin/plugins/video/chromakeyhsv.plugin: impossibile abilitare lo stack eseguibile come richiesto dall'oggetto condiviso: Argomento non valido
int PluginServer::open_plugin(int, Preferences*, EDL*, Plugin*):
PluginServer::open_plugin: load_obj /tmp/.mount_cin-x8PaXmlM/usr/bin/plugins/video/svg.plugin = /tmp/.mount_cin-x8PaXmlM/usr/bin/plugins/video/svg.plugin: impossibile abilitare lo stack eseguibile come richiesto dall'oggetto condiviso: Argomento non valido
build lv2 index for: $CIN_PATH/lv2
MWindow::init_plugins: can't create plugin index: /home/paz/.bcast5/Cinelerra_plugins
build ladspa plugin index for: /tmp/.mount_cin-x8PaXmlM/usr/bin/ladspa
MWindow::init_theme: tema preferito Cakewalk non trovato
MWindow::init_theme: non theme_plugin trovato
unjoined tids / owner 1
  000079937ffff6c0 / 00007993b4268900 12BC_Clipboard



.bcast5 directory contains:

Cinelerra_plugins
Cinelerra_rc
ladspa_plugins.CINGG_20250216_004719

I append the file "Cinelerra_plugins"

Cinelerra_plugins.tar.gz (4,277 bytes)
sge

sge

2025-02-16 05:14

reporter   ~0005764

@PhyllisSmith
If you can reproduce SEGV under Ubuntu, could you perhaps get a traceback to see in which code part it happens?
To open file selection dialog, there is a rather shamanic preparation sequence. In the case of empty program name the project directory is given to the dialog to get it opened at least in the probable place. Then update_history() is called, without this preparation call the dialog takes some other path if the needed path is not yet present in history. And this could behave differently, for example, in a fresh created empty .bcast5 and with a fresh created new project so that no history exists, etc...
PhyllisSmith

PhyllisSmith

2025-02-16 01:34

manager   ~0005763

@sge
@IgorBeg
@andrea_paz
@Andrew-R
It took me awhile because I do things differently, but I was able to get all 4 patches in and compiled on Fedora 40, Fedora 32, Debian 9.1 32-bit, and Ubuntu 16. I put an Ubuntu 16 appimage (not the alternative shortcut version and no help included) on the server for anyone who wants to test early at:
    https://cinelerra-gg.org/download/testing/cin-x86_64_blendplugins.AppImage
which should work even on the latest operating system distros/versions (Andrea could you try if you have time?) I did get a SEGV on ubuntu 16 for both plugins when I clicked on "Attach" and no file was specified but THIS IS MY PROBLEM because when I executed the appimage on Fedora 32, I did not get the segv. I will retest tomorrow to see what I did wrong. And then the "fun" testing can begin. Hopefully Andrea will have the Manual updated pages for check in and I will check in the source after I get the chance to do a little testing too.

Again, thank you SGE!
sge

sge

2025-02-15 11:50

reporter   ~0005762

There appeared one more subtle mistake when simulating non-unity alpha in colorspaces without alpha. The additional patch is attached here.

Thus, to add the whole blend package to CinGG, four patches should be applied in this sequence:

cgg-blendalgebra.diff.gz
cgg-blend-editmsg.diff.gz
cgg-blend-noalpha.diff.gz
cgg-blend-yuvalpha.diff.gz

cgg-blend-yuvalpha.diff.gz (473 bytes)
sge

sge

2025-02-14 17:07

reporter   ~0005761

One more update to the blending plugins: one additional parameter is made available in user functions (both INIT and PROC phase) which can be accessed under the name HAS_ALPHA (1 == project color space has alpha channel, 0 otherwise). Please apply this cgg-blend-noalpha patch in addition to the first two.

5 Blend Algebra functions now make use of HAS_ALPHA, they are updated by this patch. Additionally, ovl2-upd.tar.gz contains this update to the corresponding ovl2 example (with programmed overlays).

All other functions do not depend on this new parameter and need not to be changed.

cgg-blend-noalpha.diff.gz (3,098 bytes)
ovl2-upd.tar.gz (678 bytes)
sge

sge

2025-02-13 16:49

reporter   ~0005760

@Andrea_Paz
Here is a tiny patch, after which an error message will be shown if the user presses Edit... with empty function name or when a directory is selected in file selection dialog instead of plain file. This second patch has to be applied after the first big one.
Your quirks with starting kate editor are strange, I cannot reproduce them. I just did:

export CIN_EDITOR=kate
export CIN_CONFIG=$HOME/.bcast6
~/ct/cin/bin/cin

CGG started normally and created the new .bcast6 directory. In the moment I pressed Edit... it printed in the console:

BlendAlgebraCompile: copying /home/sge/ct/cin/bin/dlfcn/BlendAlgebraCompile.pl to /home/sge/.bcast6/BlendAlgebraCompile.pl
BlendAlgebraCompile: executing kate /disk2/sge/test/ovl2/ovl_normal.ba &

Then kate itself printed:

kf.sonnet.core: No language dictionaries for the language: "C" trying to load en_US as default
Qt: Session management error: networkIdsList argument is NULL
E[22:53:22.965] Could not build CompilerInvocation for file /disk2/sge/test/ovl2/ovl_normal.ba

Perhaps it could be printed because kate knows nothing about the 'ba' language. Nevertheless, kate opened the right file and showed it just normally.

Perhaps it should be mentioned: cinelerra must be started in that very same console (from the same shell session of the same terminal) where the export CIN_EDITOR= etc. commands were given. Otherwise, add the export... commands to your ~/.profile, then logout and login again.

cgg-blend-editmsg.diff.gz (755 bytes)
sge

sge

2025-02-13 03:58

reporter   ~0005759

@Andrea_Paz
The EDIT button, if pressed while the text field of the function name is empty (i.e. no function selected), does nothing. If it is the case for you, try first to select some function (or enter a name for the new one), then edit. Perhaps we should show some error message in such cases, saying that a function should be selected first.

If there is a problem with text editor start at all, it can be easily debugged from outside CinGG. Create some text file (tmp.txt), and do in a console:

export CIN_EDITOR=kate
~/.bcast5/BlendAlgebraCompile.pl -verbose -edit tmp.txt

You can also try ~/.bcast5/BlendAlgebraCompile.pl -h, looking what it prints at the end about environment settings.
Andrea_Paz

Andrea_Paz

2025-02-12 21:22

manager   ~0005758

Great job, thank you.
The compile with your patch went smoothly. I had to put execution permissions on the two *.pl files as you suggested. I set the editor to kate.
CinGG starts without any problems and also apply the two plugins works without any error reported. However, the EDIT button, which should open kate, does not work for me. maybe I need to indicate the absolute path when I do the export?
If it helps I attach the cin5.log, although, as I said, I found no problems during the compile.

cin5.tar.gz (309,535 bytes)
Andrew-R

Andrew-R

2025-02-12 20:15

reporter   ~0005757

@sge, oh, cinelerra can be compiled under cygwin on windows 10 (64bit). I did exercuse yesteryear, cygwin.patch need some fixes and cygwin install kinda big at 30gb, you also need Xserver for Windows and pulseaudio. I also manually compiled ffmpeg for cingg to use. So cinngg-on-windows more like proof of concept, not something you want to use "in production".

NetBSD should be ELF based (and cingg works there), and I never figured out how macos mach-o sections/linking works ...
Andrew-R

Andrew-R

2025-02-12 20:08

reporter   ~0005756

@sge, wow this definitely counts as BIG WORK! Thanks for documenting it as well, guess our manual destined to grow. Yes, OpenGL + rgba-float still clips (and probably does other things depending on driver). May be shaders hiding inside .C files should take variable (global) allowing to opt out this clipping. But this is separate problem ....

I hope to test this as fast as it hits our main git.

As sidenote there was shadertoy plugin for ffmpeg, should I redigg it and try to compile with some version of ffmpeg it was created against?

Sorry,I slided down from development, reading comments us SO much simpler!
PhyllisSmith

PhyllisSmith

2025-02-12 19:24

manager   ~0005755

Last edited: 2025-02-12 19:25

View 2 revisions

 @sge
Will test and implement the mods. Thank You.
@Andrew-R
@andrea_paz
@IgorBeg
sge

sge

2025-02-12 16:06

reporter  

transitions.tar.gz (2,527,473 bytes)
swap.tar.gz (2,527,302 bytes)
cgg-blendalgebra.diff.gz (45,219 bytes)
ovl2.tar.gz (7,056 bytes)
ck.tar.gz (37,297 bytes)
ydiff.tar.gz (2,527,407 bytes)

Issue History

Date Modified Username Field Change
2025-02-12 16:06 sge New Issue
2025-02-12 16:06 sge File Added: cgg-blendalgebra.diff.gz
2025-02-12 16:06 sge File Added: ovl2.tar.gz
2025-02-12 16:06 sge File Added: ck.tar.gz
2025-02-12 16:06 sge File Added: ydiff.tar.gz
2025-02-12 16:06 sge File Added: transitions.tar.gz
2025-02-12 16:06 sge File Added: swap.tar.gz
2025-02-12 19:24 PhyllisSmith Assigned To => PhyllisSmith
2025-02-12 19:24 PhyllisSmith Status new => acknowledged
2025-02-12 19:24 PhyllisSmith Note Added: 0005755
2025-02-12 19:25 PhyllisSmith Note Edited: 0005755 View Revisions
2025-02-12 20:08 Andrew-R Note Added: 0005756
2025-02-12 20:15 Andrew-R Note Added: 0005757
2025-02-12 21:22 Andrea_Paz File Added: cin5.tar.gz
2025-02-12 21:22 Andrea_Paz Note Added: 0005758
2025-02-13 03:58 sge Note Added: 0005759
2025-02-13 16:49 sge File Added: cgg-blend-editmsg.diff.gz
2025-02-13 16:49 sge Note Added: 0005760
2025-02-14 17:07 sge File Added: cgg-blend-noalpha.diff.gz
2025-02-14 17:07 sge File Added: ovl2-upd.tar.gz
2025-02-14 17:07 sge Note Added: 0005761
2025-02-15 11:50 sge File Added: cgg-blend-yuvalpha.diff.gz
2025-02-15 11:50 sge Note Added: 0005762
2025-02-16 01:34 PhyllisSmith Note Added: 0005763
2025-02-16 05:14 sge Note Added: 0005764
2025-02-16 10:50 Andrea_Paz File Added: Cinelerra_plugins.tar.gz
2025-02-16 10:50 Andrea_Paz Note Added: 0005765
2025-02-16 20:27 PhyllisSmith Note Added: 0005766
2025-02-16 23:16 PhyllisSmith Note Edited: 0005766 View Revisions
2025-02-17 14:04 sge Note Added: 0005767
2025-02-17 15:36 PhyllisSmith Note Added: 0005768
2025-02-17 18:33 IgorBeg Note Added: 0005769
2025-02-17 22:44 PhyllisSmith File Added: segv_problem.tar.gz
2025-02-17 22:44 PhyllisSmith Note Added: 0005770
2025-02-18 02:15 sge Note Added: 0005771
2025-02-18 08:04 Andrea_Paz Note Added: 0005772
2025-02-18 16:41 sge File Added: cgg-filebox.diff.gz
2025-02-18 16:41 sge Note Added: 0005773
2025-02-18 23:41 PhyllisSmith Note Added: 0005774
2025-02-19 05:48 sge Note Added: 0005775
2025-02-19 14:47 sge File Added: cgg-filebox2.diff.gz
2025-02-19 14:47 sge Note Added: 0005776
2025-02-19 21:48 PhyllisSmith Note Added: 0005777
2025-02-20 05:21 sge File Added: cgg-blendreadme.diff.gz
2025-02-20 05:21 sge Note Added: 0005778
2025-02-21 01:55 PhyllisSmith Note Added: 0005779
2025-02-23 01:56 PhyllisSmith Note Added: 0005780
2025-02-25 16:34 sge File Added: cgg-filebox3.diff.gz
2025-02-25 16:34 sge Note Added: 0005781
2025-02-25 20:20 PhyllisSmith Note Added: 0005782
2025-02-25 20:21 PhyllisSmith Note Edited: 0005782 View Revisions
2025-03-05 15:46 sge File Added: cgg-chdir.diff.gz
2025-03-05 15:46 sge Note Added: 0005784
2025-03-06 01:58 PhyllisSmith Note Added: 0005786
2025-03-11 16:35 sge File Added: cgg-blend-pars.diff.gz
2025-03-11 16:35 sge Note Added: 0005787
2025-03-11 21:02 PhyllisSmith Note Added: 0005788