Dear CinGG users, Does anybody want to taste something brand new and unusual? Here is the patch attached: cgg-blendalgebra.diff.gz Apply this patch and rebuild CinGG. The only change is the addition of two completely new video effects, Blend Algebra and Blend Program. The main CinGG code is not affected, so applying the patch is harmless and cannot break anything. After applying the patch, and before executing `make', check that 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. Motivation ========== Sometimes there appear again questions / complains regarding overlay blending in Cinelerra, that something appears strange, or not exactly that way as in Gimp (or in whatever), or not in that art the user needs. Fighting such windmills does not seem worth while. The idea here is to create 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. Firstly I'd like to make a short introduction, a small demo what one can do with the new features. The shortest demo projects are attached here, for several longer ones I'll give the links to download them. This development is already posted to CinGG bugtracker as BT670: https://www.cinelerra-gg.org/bugtracker/view.php?id=670 To look on the following 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'. To open editor from the plugin dialog, some function must be active at that timeline position (its name in text field not empty). Currently, pressing the 'Edit...' button on the empty function does nothing. Either select some existing function first, or enter a name to create a new one from scratch. Example 1. ---------- See ovl2.tar.gz in the attachment 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 are keyframable, i.e. switchable between plugin keyframes. Untar the ovl2.tar.gz archive from the attachment, 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. The ydiff.tar.gz archive with this demo can be downloaded from CGG bugtracker (2.5 Mb): https://www.cinelerra-gg.org/bugtracker/file_download.php?file_id=995&type=b... Example 3. ---------- Untar the example archive transitions.tar.gz and load the project transitions.xml. It demonstrates how transition-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 from either track #0 or track #1. The transitions.tar.gz archive with this demo can be downloaded from CGG bugtracker (2.5 Mb): https://www.cinelerra-gg.org/bugtracker/file_download.php?file_id=996&type=b... 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 being changed. The swap.tar.gz archive with this demo can be downloaded from CGG bugtracker (2.5 Mb): https://www.cinelerra-gg.org/bugtracker/file_download.php?file_id=997&type=b... 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 from the attachment 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 which 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 that second Blend Program plugin GUI. ======================================================================== Those who have realized that are not interested in the new features at all, can stop reading here. Who has some interest to try, welcome to read the more detailed README.blendalg description from attachment. As a starting tutorial one could, for example, take some of the overlay functions, modify it to calculate according some other formula and look what changes. Or take the 'background' blend program and implement some dependency on PIX_X and/or PIX_Y to convert solid background to a gradient. If some details in the description attached look too difficult to understand, don't bother, skip unclear sections - perhaps everything will work fine also without reading them. _______________________________________________________________________________ Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email [email protected] _______________________________________________________________________________
Wow! I haven't tried it yet, but You did an HUGE Work! And thing really and very important, with the User Manual! Thank you Georgy! Il 13/02/2025 10:42, Georgy Salnikov via Cin ha scritto:
Dear CinGG users,
Does anybody want to taste something brand new and unusual? Here is the patch attached:
cgg-blendalgebra.diff.gz
Apply this patch and rebuild CinGG. The only change is the addition of two completely new video effects, Blend Algebra and Blend Program. The main CinGG code is not affected, so applying the patch is harmless and cannot break anything.
After applying the patch, and before executing `make', check that 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.
Motivation ==========
Sometimes there appear again questions / complains regarding overlay blending in Cinelerra, that something appears strange, or not exactly that way as in Gimp (or in whatever), or not in that art the user needs. Fighting such windmills does not seem worth while.
The idea here is to create 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.
Firstly I'd like to make a short introduction, a small demo what one can do with the new features. The shortest demo projects are attached here, for several longer ones I'll give the links to download them.
This development is already posted to CinGG bugtracker as BT670: https://www.cinelerra-gg.org/bugtracker/view.php?id=670
To look on the following 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'.
To open editor from the plugin dialog, some function must be active at that timeline position (its name in text field not empty). Currently, pressing the 'Edit...' button on the empty function does nothing. Either select some existing function first, or enter a name to create a new one from scratch.
Example 1. ----------
See ovl2.tar.gz in the attachment
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 are keyframable, i.e. switchable between plugin keyframes. Untar the ovl2.tar.gz archive from the attachment, 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.
The ydiff.tar.gz archive with this demo can be downloaded from CGG bugtracker (2.5 Mb):
https://www.cinelerra-gg.org/bugtracker/file_download.php?file_id=995&type=b...
Example 3. ----------
Untar the example archive transitions.tar.gz and load the project transitions.xml. It demonstrates how transition-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 from either track #0 or track #1.
The transitions.tar.gz archive with this demo can be downloaded from CGG bugtracker (2.5 Mb):
https://www.cinelerra-gg.org/bugtracker/file_download.php?file_id=996&type=b...
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 being changed.
The swap.tar.gz archive with this demo can be downloaded from CGG bugtracker (2.5 Mb):
https://www.cinelerra-gg.org/bugtracker/file_download.php?file_id=997&type=b...
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 from the attachment 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 which 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 that second Blend Program plugin GUI.
========================================================================
Those who have realized that are not interested in the new features at all, can stop reading here. Who has some interest to try, welcome to read the more detailed README.blendalg description from attachment. As a starting tutorial one could, for example, take some of the overlay functions, modify it to calculate according some other formula and look what changes. Or take the 'background' blend program and implement some dependency on PIX_X and/or PIX_Y to convert solid background to a gradient.
If some details in the description attached look too difficult to understand, don't bother, skip unclear sections - perhaps everything will work fine also without reading them.
_______________________________________________________________________________
Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email [email protected] _______________________________________________________________________________
I am responding on the mailing list so as not to make the bug tracker chaotic with my incompetent attempts. You answered me: "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." Thanks, I didn't realize to write in “function” before using the “edit” button. I tried writing “subtract” in Function and then hitting the edit button and I get the following lines on the terminal: BlendAlgebraCompile: copying /home/paz/cinelerra5/cinelerra-5.1/bin/dlfcn/BlendAlgebraCompile.pl to /home/paz/.bcast6/BlendAlgebraCompile.pl BlendAlgebraCompile: executing emacs /home/paz/subtract & sh: line 1: emacs: command not found export CIN_EDITOR=kate BlendAlgebraCompile: executing emacs /home/paz/subtract & sh: line 1: emacs: command not found BlendAlgebraCompile: executing emacs /home/paz/subtract & sh: line 1: emacs: command not found I tried doing an export both inside the open CinGG terminal and from an external terminal, but the plugin still seems to refer to emacs. Finally I found the solution (thanks to your answer) to my problems. I use .bcast6 because .bcast5 I leave for appimage. In the file “/home/paz/.bcast6/BlendAlgebraCompile.pl” I changed emacs to kate and .bcast5 to .bcast6. With these changes the plugin works; it opens kate where I paste your example code for the subtract and then save and close kate. I put the plugin in the “top” track, setting “top first” and output in the top track. I put the plugin as “shared” in the bottom track. I get the black compositor window. If I set the output as “bottom” instead the plugin works and I get the blend set. So, if I understand correctly, the plugin goes into the top track (and shared in bottom) and needs to be set: - track order: “top first” or ‘bottom first’ depending on the blend we want to achieve - Output track: “bottom” (I do not understand in which cases ‘top’ could be used) - Hide imput tracks, use output exclusively: active (I do not understand in which cases to use “off”) In other cases I get either black screen or unaltered output tracks. I don't really understand these behaviors and need to do further testing. Given my lack of expertise, perhaps it is better to use the functions in the library than to use EDIT?
On Thu, 13 Feb 2025, Andrea paz via Cin wrote:
Finally I found the solution (thanks to your answer) to my problems. I use .bcast6 because .bcast5 I leave for appimage. In the file /home/paz/.bcast6/BlendAlgebraCompile.pl I changed emacs to kate and .bcast5 to .bcast6.
Here two environment variables are altered simultaneously, $CIN_EDITOR and $CIN_CONFIG. I did not test this situation, only either one from them. Must test today evening. Editing the script will definitely work. But there might come a confusion because there are two versions of BlendAlgebraCompile: that which is installed (system-wide) in bin/dlfcn by make install, and the other which is created by itself as a user copy for editing in ~/.bcast5 (in your case .bcast6). Editable is the user's copy in .bcast6, it is that which is actually executed. You can test what values actually have environment variables inside the script (example): export CIN_EDITOR=kate export CIN_CONFIG=$HOME/.bcast6 $CIN_CONFIG/BlendAlgebraCompile.pl -h At the end of help text the script prints values from his environment, check them.
I put the plugin in the top track, setting top first and output in the top track. I put the plugin as shared in the bottom track. I get the black compositor window. If I set the output as bottom instead the plugin works and I get the blend set. So, if I understand correctly, the plugin goes into the top track (and shared in bottom) and needs to be set:
Andrea, it is really not easy to imagine, what is to be first and last, top and bottom, source and destination compared to what is described in the CGG manual, the section about overlays. As I wrote these example functions, I read the Overlays section in the manual, drawn the green and red rectangles over transparent background (as in manual), took formula from there, tried to attach the regular 'Overlay' plugin, looked what comes out. Then I swapped source and destination in my first test function to get the same picture as with the Overlay plugin (destination became #0, source #1, firstly I thought it should be the other way around). There are more confusions. For example, if you have red and green, both opaque, over black background, and do subtraction, if you subtract red from black, you get black (clipped from '-red'). If you subtract red from green, perhaps you would think, you should get green, but actually you can get black because here you subtract also alpha from alpha, both being 1.0, and as the result you get alpha = 1-1 = 0.0, also black. In CGG there is also a questionable feature, what contents is seen through transparency if there is no completely opaque track in the stack. You must place an extra track with opaque background on the very bottom to get predictable results. It has nothing to do with Blend Algebra, it is a fundamental property in CGG. Perhaps to make yourself familiar, first try unpack some of my examples, load a project from there, play it through. Then edit something other. For the 'ovl2' example, you can test to attach the Overlay plugin and switch Blend Algebra off, to see the difference between the two. For some cases you can switch top or bottom first, and the output track, see the result and understand what happens. But for some other cases it can look really confusing, until replaying the formula in own brain:(
- Hide imput tracks, use output exclusively: active (I do not understand in which cases to use off)
Perhaps if you have additionally a mask over the result track and want that one of the argument tracks be seen through the hole in the mask. _______________________________________________________________________________ Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email [email protected] _______________________________________________________________________________
CIN_CONFIG I apply it at compile time (./configure) via the flag “--with-config-dir=/home/paz/.bcast6”. So I think your plugin fails to catch this change of mine and takes .bcast5 by default. But this is not a problem because it only affects my customization.
At the end of help text the script prints values from his environment, check them.
From the script help I get:
[...] Relevant environment variables $CIN_CC: currently not set, fallback: gcc $CC: currently not set, fallback: gcc CIN_EDITOR=kate $CIN_DAT: currently not set CIN_CONFIG=/home/paz/.bcast6 $CIN_USERLIB: currently not set, fallback: /home/paz/.bcast6lib NOTE: I have a BlendAlgebraCompile.pl also in .bcast5, despite never having started appimage since I did the compilation with your plugin. This file maintains emacs and .bcast5. Come to think of it, there is no reason to use separate .bcast6 and thus create further complications for me.
destination became #0, source #1,
Great, that clarifies a lot of things for me.
There are more confusions. For example, if you have red and green, both opaque, over black background, and do subtraction, if you subtract red from black, you get black (clipped from '-red'). If you subtract red from green, perhaps you would think, you should get green, but actually you can get black because here you subtract also alpha from alpha, both being 1.0, and as the result you get alpha = 1-1 = 0.0, also black.
And this makes me understand some of the many doubts I had about overlays....
In CGG there is also a questionable feature, what contents is seen through transparency if there is no completely opaque track in the stack. You must place an extra track with opaque background on the very bottom to get predictable results. It has nothing to do with Blend Algebra, it is a fundamental property in CGG.
Perhaps to make yourself familiar, first try unpack some of my examples, load a project from there, play it through. Then edit something other.
For the 'ovl2' example, you can test to attach the Overlay plugin and switch Blend Algebra off, to see the difference between the two.
For some cases you can switch top or bottom first, and the output track, see the result and understand what happens. But for some other cases it can look really confusing, until replaying the formula in own brain:(
I tried your ovl2.xml project. Thank you, it is good job. I understand what you are saying, until you examine the formulas carefully, the result is hard to guess. I feel like I am dealing with Quantum Mechanics! :)
- Hide imput tracks, use output exclusively: active (I do not understand in which cases to use off)
Perhaps if you have additionally a mask over the result track and want that one of the argument tracks be seen through the hole in the mask.
Thanks. I would like to use your explanations by summarizing them in the manual (and perhaps keep the full text in a separate file for users interested in further analysis). What do you think? Better to use all your writing in the manual?
On Thu, 13 Feb 2025, Andrea paz wrote:
CIN_CONFIG I apply it at compile time (./configure) via the flag \u201c--with-config-dir=/home/paz/.bcast6\u201d. So I think your plugin fails to catch this change of mine and takes .bcast5 by default. But this is not a problem because it only affects my customization.
Setting CIN_CONFIG at compile time is your choice, it is OK. But to make the environment definitions for the compilation/editing script, you have to set them one after another in the same terminal/console from the same shell, and then start Cinelerra program also from that very same console/shell: cryo.sge:/disk2/sge/test> export CIN_EDITOR=kate cryo.sge:/disk2/sge/test> export CIN_CONFIG=$HOME/.bcast6 cryo.sge:/disk2/sge/test> ~/ct/cin/bin/cin This just works by me.
Relevant environment variables
$CIN_CC: currently not set, fallback: gcc $CC: currently not set, fallback: gcc CIN_EDITOR=kate $CIN_DAT: currently not set CIN_CONFIG=/home/paz/.bcast6 $CIN_USERLIB: currently not set, fallback: /home/paz/.bcast6lib
So, when you set the environment and start the script immediately, it does see them all. But then CGG has to be started also from there.
NOTE: I have a BlendAlgebraCompile.pl also in .bcast5, despite never having started appimage since I did the compilation with your plugin. This file maintains emacs and .bcast5.
This is perhaps because once the script copied itself to ~/.bcast5 to create user editable instance, while no $CIN_CONFIG was set (that it was set somewhen while building CGG binary, is over).
perhaps you would think, you should get green, but actually you can get black because here you subtract also alpha from alpha, both being 1.0, and as the result you get alpha = 1-1 = 0.0, also black.
And this makes me understand some of the many doubts I had about overlays....
OK, but now you can take the arith_subtract function, change the expression for alpha to something like A_OUT = A(s); or even A_OUT = 1;, and you'll get green:)
I would like to use your explanations by summarizing them in the manual (and perhaps keep the full text in a separate file for users interested in further analysis). What do you think? Better to use all your writing in the manual?
I think, in any case I'll add my descriptions in form of plain text to the sources of the plugins as some README files for future reference. Not just now, but in a short time, after the code is stabilized. How much technical info from this to include in user manual, is a difficult question... A programmer and a user imagine differently. So, here I rely on your decision. Here in attachment there is a tiny patch to be applied after the first big one. Then, if you press Edit... while finction name is empty (or in the file selection dialog a directory is selected instead of plain file), an error message will be shown. Perhaps this will be less confusing than silently doing nothing. _______________________________________________________________________________ Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email [email protected] _______________________________________________________________________________
I compiled without the bcast6 flag and putting your latest patch. All OK, thank you. I started from terminal with the two exports and everything works fine, same as you reported. So the problem was just that flag of ./configure. Tomorrow I'm going to do some testing, including the change you suggested: “OK, but now you can take the arith_subtract function, change the expression for alpha to something like A_OUT = A(s); or even A_OUT = 1;, and you'll get green” But first I want to fully understand how the userlib works...
On Thu, 13 Feb 2025, Andrea paz wrote:
I compiled without the bcast6 flag and putting your latest patch. All OK, thank you. I started from terminal with the two exports and everything works fine, same as you reported. So the problem was just that flag of ./configure.
If kate is your generally preferred text editor, perhaps most convenient for you were to place the necessary 'export' commands into your ~/.profile, then relogin in your desktop, and these new environment variables would stay permanent.
But first I want to fully understand how the userlib works...
May be, you have noticed yesterday: if $CIN_CONFIG is set to something non-default, and $CIN_USERLIB not set, then the default for $CIN_USERLIB depends on $CIN_CONFIG. For example, while the usual default for $CIN_USERLIB is ~/.bcast5lib, if your $CIN_CONFIG is set to ~/.bcast6, then the default for $CIN_USERLIB becomes ~/.bcast6lib. _______________________________________________________________________________ Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email [email protected] _______________________________________________________________________________
On Thu, 13 Feb 2025, Andrea paz wrote:
Tomorrow I'm going to do some testing, including the change you suggested: \u201cOK, but now you can take the arith_subtract function, change the expression for alpha to something like A_OUT = A(s); or even A_OUT = 1;, and you'll get green\u201d
Andrea, I have found, the standard Overlay effect seems not to make arithmetic with emulated transparencies if the project has no alpha channel. Therefore I made a small correction: now the fact of having alpha (== 1) or not having alpha (== 0) is also given to user functions as an additional parameter HAS_ALPHA. The patch to CGG source, cgg-blend-noalpha.diff.gz, is in attachment. 5 BlendAlgebra functions have to be changed due to this modification. For CGG distribution, they are in that patch. For the 'ovl2' example the updated functions are in the archive ovl2-upd.tar.gz, also in attachment. And yes, arith_subtract without alpha became green:) All the other functions are not affected by the modifications, either they do not use alpha at all, or the arithmetic on it constantly gives 1.0 anyway. _______________________________________________________________________________ Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email [email protected] _______________________________________________________________________________
Great, everything works perfectly even with this third patch. For example I had already done a test with my Subtracts function, where I put alpha=1, and it comes back the same as your new arith_subtract.ba. Reading your explanations makes it clear how many cases your plugins can be applied to. You really did a great job, thank you. I was thinking of adding the following note to the manual, in the chapter on overlays. Do you think it is correct or should it be made more precise? "OVERLAY Remember that when making the various blends of 2 tracks you should always consider: 1- The colors of the 2 tracks that will be blended. We often consider only these channels to guess the final result. 2- The Alpha channel of the 2 tracks that can interact with each other in ways that are intuitively (but not mathematically) unexpected. 3- The choice of Source track and destination track (top or bottom). 4- The presence of a third black background track (or even the color of the canvas, which in CinGG is black by default but whose color can be varied manually), which can interfere with viewing the blend in the Compositor and show unexpected results. Ultimately, if we get a result that looks wrong to us, we need to look at the formula for that blend and calculate our mathematical result. Then compare our calculation with the result we see on the screen."
On Fri, 14 Feb 2025, Andrea paz wrote:
I was thinking of adding the following note to the manual, in the chapter on overlays. Do you think it is correct or should it be made more precise?
Right! Overlays can be really confusing, unless you have 3D vision from birth. Any additional note would not be superfluous.
1- The colors of the 2 tracks that will be blended. We often consider only these channels to guess the final result. 2- The Alpha channel of the 2 tracks that can interact with each other in ways that are intuitively (but not mathematically) unexpected. 3- The choice of Source track and destination track (top or bottom). 4- The presence of a third black background track (or even the color of the canvas, which in CinGG is black by default but whose color can be varied manually), which can interfere with viewing the blend in the Compositor and show unexpected results.
There exist even more factors. If the footage material in a track has transparency by itself, it might be modified by overlay formula and develop some color, hidden by transparency before overlay was applied. Overlays can be applied at two places: via the patchbay button and in the Overlay plugin. In which sequence in the video processing pipeline plugins are processed, is defined. But when are processed overlays from patchbay? I am sorry, I don't know this. There may be mask. The mask can be applied either after plugins, or before them. The results of Overlay plugin depend on it. There is fader control. To my feeling, fader is applied after all plugins and overlays, but I am not 100% sure. Effects from some other plugins can have transparent parts (Titler, for example). There is a strange behavior of transparency generated due to attached effects, highly resembling a bug. So far we apply a workaround by placing an additional track with opaque background on bottom. But I am still confusing by the fact that without additional track this transparency effect is not always the same. Sometimes really the background, as configured in Settings->Preferences->Appearance->Composer BG Color, is visible through the transparency, but sometimes the original image itself, I cannot yet find an origin or pattern. There are two buttons in the patchbay, Play track (can be switched off), and Don't send to output (can be switched on). In both cases video from the affected track disappears, but the background left can be different in both cases.
Ultimately, if we get a result that looks wrong to us, we need to look at the formula for that blend and calculate our mathematical result. Then compare our calculation with the result we see on the screen."
Yes. In principle, the user, if interested, could now attach Blend Algebra in addition to Overlay plugin, switch one of them on, another off, play with formula in Blend Algebra how the modifications affect the result, even print and analyse the intermediate color values. And using some specially drawn regular color patterns instead of a natural working footage. _______________________________________________________________________________ Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email [email protected] _______________________________________________________________________________
On Fri, 14 Feb 2025, Andrea paz wrote:
1- The colors of the 2 tracks that will be blended. We often consider only these channels to guess the final result. 2- The Alpha channel of the 2 tracks that can interact with each other in ways that are intuitively (but not mathematically) unexpected. 3- The choice of Source track and destination track (top or bottom). 4- The presence of a third black background track (or even the color of the canvas, which in CinGG is black by default but whose color can be varied manually), which can interfere with viewing the blend in the Compositor and show unexpected results.
And even more factors. Overlays effect generally depends on the colorspace of the project (in YUV can differ from RGB). In Blend Algebra this dependency is addressed: the necessary colorspace conversion can be done automatically. Overlays can depend on implicit clipping. In RGBA-FLOAT no clipping is done, in RGBA8888 clipping to 8 bit unsigned cannot be avoided per definition. Blend Algebra addresses this dependency also, clipping for float colorspace can be switched on explicitly, and then the results for float and 8888 should be identical. Unclipped overlays can be displayed differently depending on the graphic driver (bare X11, X11-Xv, OpenGL, etc.). To my mind, OpenGL driver could be more robust in these cases, it runs perhaps under control of some CGG shader and seems to clip the bounds correctly. _______________________________________________________________________________ Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email [email protected] _______________________________________________________________________________
There is fourth patch to Blend Algebra, in attachment. It is against one subtle mistake when under YUV888 (non-alpha) colorspace a function returns alpha not equal to 1.0. Not dangerous, and seldom encountered case. _______________________________________________________________________________ Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email [email protected] _______________________________________________________________________________
I also applied the latest patch and did all the tests with your examples projects and then tried to redo them with two tracks of my own: everything seems to work fine even though some tests with my tracks I don't understand well. :) Nice examples are also ydiff; swap and transition. The chromakey seems to me comparable to CGG's classic chromakey and not avid's. The ability to replace the background via Blend Program is great, though. I am left with the curiosity of combining Chromakey HSV with Blend Program's background replacement, but I will put it off until Monday. Thanks also for the additional insights for the note for the manual; they are all interesting and make one understand some of the problems that have come up over the years (and maybe even find a solution via custom Blend Algebra functions...). I hope others will also test because I am not good as a tester.
On Sat, 15 Feb 2025, Andrea paz wrote:
Nice examples are also ydiff; swap and transition. The chromakey seems to me comparable to CGG's classic chromakey and not avid's. The ability to replace the background via Blend Program is great, though.
I have intentionally chosen several example functions from totally different areas of application, to demonstrate that a user-programmable plugin is a really universal toy and can appear handy even in unexpected cases. If a user needs to tinkern some play with colors or layers and does not know which of the dedicated plugins should help, he can think "Could I firstly try something like this with a blend program?" Even a programmer can sometimes make use of this approach when creating new effects. Here one can much more quickly test different combinations without spending time to restart CinGG, recompile it, reload project, reattach plugins, etc. Blendprogram chromakey was also implied as a remarkable example to demonstrate that even complex things sometimes may be expressed in extremely simple form, in only several lines of text. Can it be used in a real video production? Not obvious. In no way can it replace ChromakeyAvid or something like this. But one can in principle play with the expression in it to tune the sensitivity on the hue difference, for example, or even combine the found expression with further plugins, like alpha smoothing, etc., who knows? _______________________________________________________________________________ Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email [email protected] _______________________________________________________________________________
participants (3)
-
Andrea paz -
Georgy Salnikov -
Igor BEGHETTO