Re: [Cin] Some tests on blending
сб, 29 мар. 2025 г., 16:14 Andrea paz : > > I wonder how other software solves it > > I can't answer that. I think the best possible is DaVinci resolve's > Color Management, but they are unattainable levels for anyone. You can > see their manual from p. 215 to p. 250: > > https://documents.blackmagicdesign.com/UserManuals/DaVinci_Resolve_19_Reference_Manual.pdf Ah, from p. 222: A key benefit of the color space conversions that RCM applies is that no image data is ever clipped during the Input to Timeline color space conversion. For example, even if your source is log-encoded or in a camera raw format, grading with a Rec. 709 Timeline Color Space does nothing to clip or otherwise limit the image data available to the RCM image processing pipeline. All image values greater than 1.0 or less than 0.0 are preserved and made available to the next stage of RCM processing, the Timeline to Output color space conversion. = > > > In some sense I think we are much more OG opensource/libre/community > software, not piggybacking on big corporate codedrop/development, but few > cares about that ... > > I, too, think that Stalmann's Free software is dead and that Open > Source managed and supported by big companies is now predominant > (Linux Foundation). Just look at the success (I think deserved) of the > Rust language, which is replacing other languages, however with the > side effect of eliminating all GPL licenses in favor of MIT and Apache > licenses (they have now remade the GNU core utils in Rust). Praise to > CinGG (and you few contributors) who still follow the beautiful idea > of GG and Phyllis! > -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Some tests on blending
вс, 30 мар. 2025 г., 00:32 Phyllis Smith : > About the following commentary by Andrew -- Cinelerra in any version is > still a worthwhile tool even if the only people who use it are us. As long > as my desktop/laptop that were set up to automatically get files to the > webserver, I hope to keep working as a moderator. I like it! > ;) And here is little (just 250kg) reminder about what kind of problem digital editing initially aimed to simplify/solve: https://m.youtube.com/watch?v=PSYNL5FXAPg at around 25:00 ;) Imagine spending years alongside those machines! > > Problem is - I tried to ignite some interest in cingg but may be I am >> wrong person to do that, or developers want different codebase (more modern >> c++, etc). >> >> But we do not have thousands of users who can somewhat cooperate and buy >> year or so of professional developer time (HaikuOS gains like $50k in >> donations yearly, but they whole OS .. without /proc fs curiously ). >> >> So we stick in circle where devs consider our program irrelevant/too >> complex/too alien and users lack feature/bug resolution so they just >> install whatever others install - DVR, blender . >> >> In some sense I think we are much more OG opensource/libre/community >> software, not piggybacking on big corporate codedrop/development, but few >> cares about that ... >> >> -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Some tests on blending
With:
printf ("%g\n", R(0));
gives me a very long series of “1's”; perhaps a result for each pixel
of the 1920x1080 frame?
With:
if (PIX_X == 0 && PIX_Y == 0) printf ("%g\n", R(0));
It gives me a simple “1” for all plugins, with very few exceptions
when the frame is replaced by other colors for which the different
value is shown (always under “1”).
For example, “Color Swatch” replaces the solid red with its own
palette and then the result depends on the new color of the pixel
(0,0). Another example is “Lens” which causes the red frame to shrink
to a central part leaving the rest (including the pixel (0,0)) black.
In fact the result is “0” and not “1”). However, by changing the Blend
Program function and setting X=960 and Y=540 (i.e., the center pixel,
where Lens still produces solid red) the result is still “1”.
Other exceptions are HistEQ which turns the whole frame black and thus
the result is “0,” Histogram Bezier which gives 0.96 (which is “1”
anyway) and Posterize which gives 0.99678.
I can't interpret the results: I always get 1, even for Choma Key
(Avid) and for Blender Algebra itself. I have tried all the internal
plugins of CinGG, even those of only geometric transformations (Scale;
Transform; Lens; DownSample, etc) and the result is always “1”.
Maybe something limits (clips) the signal regardless of the plugin
used? Perhaps the print_hdr.bp function is not suitable for checking
the actual pixel value?
I think the issue is too complicated so it's better to give up.
However, I better understood Blend Algebra and Blend Program and their
tremendous possibilities.
--
Cin mailing list
Cin@lists.cinelerra-gg.org
https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Some tests on blending
@Georgy I wanted to try Blend Program, as you suggested, to check the various color plugins. The first one, “solid_red.bp” works fine. The second, “print_hdr.bp” does not work and the terminal shows errors that I do not understand. I don't even know how to declare a variable, although in the first function I don't have this problem. I attach the two functions and report the error on the terminal: "BlendProgramCompile: executing gcc -fPIC -O2 -shared -o /home/paz/.bcast5lib/dlfcn/bp/print_hdr.bp.so /home/paz/.bcast5lib/dlfcn/bp/print_hdr.bp.c -lm /home/paz/.bcast5lib/dlfcn/bp/print_hdr.bp: In function ‘bpProc’: /home/paz/.bcast5lib/dlfcn/bp/print_hdr.bp:11:8: error: ‘R’ undeclared (first use in this function) 11 | printf(R); |^ /home/paz/.bcast5lib/dlfcn/bp/print_hdr.bp:11:8: note: each undeclared identifier is reported only once for each function it appears in virtual int BlendProgram::process_buffer(VFrame**, int64_t, double): Blend Program: compilation of program .bcast5lib/dlfcn/bp/print_hdr.bp failed see console printout for diagnostics" I tried with: printf(R(0)); printf(R(i)); printf(R); Always with a similar error. print_hdr.bp Description: Binary data solid_red.bp Description: Binary data -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Some tests on blending
On Mon, 31 Mar 2025, Andrea paz wrote: > I re-tested and most of the color-related plugins do not have > clipping. Unfortunately (at least for me) some of the most important > plugins have it: Perhaps you can easily get around these restrictions with the following hack. Create a blend program like this (an example, adapt it to your needs): BLEND_PROGRAM_INIT COLORSPACE_RGB PARALLEL_SAFE BLEND_PROGRAM_PROC float mult; mult = KEY_A-0.5; if (mult >= 0) mult = 1+mult*10; else mult = 1/(1-mult*10); R(0) = R(0)*mult; G(0) = G(0)*mult; B(0) = B(0)*mult; BLEND_PROGRAM_END First attach this blend program to your track above the other plugin which you want to make not to clip. Switch clipping off in the blend program dialog. This blend program will use the alpha slider (which can have the value between 0.0 and 1.0) in the following manner: 0.5 (exactly in the middle): no RGB change 0.6: R,G,B are multiplied by 2 0.7: multiplied by 3 ... 1.0: multiplied by 6 0.4: multiplied by 1/2 (i.e. divided by 2) 0.3: multiplied by 1/3 ... 0.0: multiplied by 1/6 (divided by 6) If you set it, for example, to 0.4 here, your R,G,B values will be divided by 2, so that the color values up to 2.0 will be scaled down into the clip range. If you can have values up to, let's say, 5.0, then set the alpha slider to 0.1 to scale down by 5, etc. Then attach the plugin you need to work unclipped, your histogram or whatever. Pay attention that all the color values your plugin gets now, are scaled down uniformly. Then attach the same blend program once more, under your needed plugin. This time set the alpha slider to 0.6 (if it is 0.4 in the upper une), or to 0.9 (if the upper one is 0.1), i.e. displace it from the middle in the opposite direction. The unclipped values coming from your working plugin will be scaled back by the same amount. Relax and have fun, Andrea:) ___ Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email s...@nmr.nioch.nsc.ru ___ -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Some tests on blending
чт, 3 апр. 2025 г., 22:03 Andrea paz via Cin : > I tried again to test Color Space plugin and noticed some peculiarities: > If I set Input: BT709 and Output BT709, and also BT2020 -> BT2020; > then the result is not clipped. Any other combination of Input/Output > leads to a clipped result instead. How can this be explained? Perhaps > the input is not clipped (apart from BT601 which is always clipped), > but every transformation is always clipped. 709 -> 709 and 2020 -> > 2020 does not perform transformations and thus remains unclipped. > This argument can perhaps also be carried over to the “YUV Color > Space” tool: my understanding this is not a tool per se, more like switch for ffmpeg (libswscale) colour conversions ... happens on both input (if ffmpeg selected) and output As I noted there is some CMS/floating point/swscale rework in upcoming ffmpeg 8.0 , so if things will not break in many other ways we might try to convince swscale to not clip on import at least. if we leave the source color space unchanged then we can > keep the pipeline without clipping (if it was already unclipped to > begin with), if we convert to any other color space then clipping will > occur. > -- > Cin mailing list > Cin@lists.cinelerra-gg.org > https://lists.cinelerra-gg.org/mailman/listinfo/cin > -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Some tests on blending
I tried again to test Color Space plugin and noticed some peculiarities: If I set Input: BT709 and Output BT709, and also BT2020 -> BT2020; then the result is not clipped. Any other combination of Input/Output leads to a clipped result instead. How can this be explained? Perhaps the input is not clipped (apart from BT601 which is always clipped), but every transformation is always clipped. 709 -> 709 and 2020 -> 2020 does not perform transformations and thus remains unclipped. This argument can perhaps also be carried over to the “YUV Color Space” tool: if we leave the source color space unchanged then we can keep the pipeline without clipping (if it was already unclipped to begin with), if we convert to any other color space then clipping will occur. -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Some tests on blending
> (Andrea, please verify correctness in case I made a mistake). Thank you. All OK, thank you Phyllis. -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Some tests on blending
Checked into source GIT, the tone mapping SYSLIB blend program plugin addition from Andrea. Checked into manual GIT, the attached tex file changes for HDR/clipping stuff exactly as provided by Andrea. Appended Examples.txt to add Example 6 tone mapping description exactly as provided by Andrea. (Andrea, please verify correctness in case I made a mistake). Thank you. On Wed, Apr 2, 2025 at 2:32 AM Andrea paz wrote: > I have included some small adds in the manual that deal with HDR. See > if they fit. There would also be to change the Blend Algebra examples > file written by Georgy. > > [Part to append to the file > https://cinelerra-gg.org/download/testing/BlendPluginExamples/Examples.txt > ]: > > > Example 6. > -- > > To tonemapping an HDR media and report its values within the range (0, > 1.0): > > BLEND_PROGRAM_INIT > > COLORSPACE_RGB > PARALLEL_SAFE > > BLEND_PROGRAM_PROC > > float mult; > > mult = KEY_A-0.5; > if (mult >= 0) mult = 1+mult*10; > else mult = 1/(1-mult*10); > > R(0) = R(0)*mult; > G(0) = G(0)*mult; > B(0) = B(0)*mult; > > BLEND_PROGRAM_END > > > First attach this blend program to your track above the other plugin > which you want to make not to clip. Switch clipping off in the blend > program dialog. This blend program will use the alpha slider (which > can have the value between 0.0 and 1.0) in the following manner: > > 0.5 (exactly in the middle): no RGB change > 0.6: R,G,B are multiplied by 2 > 0.7: multiplied by 3 > ... > 1.0: multiplied by 6 > 0.4: multiplied by 1/2 (i.e. divided by 2) > 0.3: multiplied by 1/3 > ... > 0.0: multiplied by 1/6 (divided by 6) > > If you set it, for example, to 0.4 here, your R,G,B values will be > divided by 2, so that the color values up to 2.0 will be scaled down > into the clip range. If you can have values up to, let's say, 5.0, > then set the alpha slider to 0.1 to scale down by 5, etc. > > Then attach the plugin you need to work unclipped, your histogram or > whatever. Pay attention that all the color values your plugin gets > now, are scaled down uniformly. > > Then attach the same blend program once more, under your needed > plugin. This time set the alpha slider to 0.6 (if it is 0.4 in the > upper one), or to 0.9 (if the upper one is 0.1), i.e. displace it from > the middle in the opposite direction. The unclipped values coming from > your working plugin will be scaled back by the same amount. > -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Some tests on blending
ср, 2 апр. 2025 г., 12:46 Andrew Randrianasulu :
>
>
> пн, 31 мар. 2025 г., 16:34 Andrea paz via Cin >:
>
>> Obviously it was my fault: I had not removed the clip in Blend Program
>> I re-tested and most of the color-related plugins do not have
>> clipping. Unfortunately (at least for me) some of the most important
>> plugins have it:
>>
>> Blur
>>
>
> Try to look for switch(color) in plugins/blur/blur.C
>
> and replace for testing 1.0 for rgba/rgb float cases with FLT_MAX ? Like
> in our earlier work
>
> case BC_RGBA_FLOAT:
> BLUR(float, 1.0, 4);
>break;
>
> If it does not break plugin we probably can go for each noted plugin and
> try to find where they clip
>
may be like attached patch? Only blur and titler converted, do not want to
break vectoroscope etc
>
> Color 3 Way
>> Color Space
>> Foreground
>> Histogram
>> Histogram Bezier
>> Title
>> Videoscope
>>
>> I remember an attempt by Andrew with Adam to try to engage him on the
>> Histogram clipping, but Adam was not really interested:
>> https://github.com/heroineworshiper/hvirtual/issues/8
>>
>> @Phyllis
>> Do you think it's good to indicate in the manual the plugins that do
>> the clipping?
>> --
>> Cin mailing list
>> Cin@lists.cinelerra-gg.org
>> https://lists.cinelerra-gg.org/mailman/listinfo/cin
>>
>
From 25bc934759ac2c7953ccbd7f1e45bd52c8d8a5be Mon Sep 17 00:00:00 2001
From: Andrew Randrianasulu
Date: Wed, 2 Apr 2025 12:52:03 +0300
Subject: [PATCH] Experimental: remove clipping from blur/titler plugins?
---
cinelerra-5.1/plugins/blur/blur.C | 6 +++---
cinelerra-5.1/plugins/titler/titler.C | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/cinelerra-5.1/plugins/blur/blur.C b/cinelerra-5.1/plugins/blur/blur.C
index dfbf501c..e904f878 100644
--- a/cinelerra-5.1/plugins/blur/blur.C
+++ b/cinelerra-5.1/plugins/blur/blur.C
@@ -32,7 +32,7 @@
#include
-
+#define MAX_FLT 3.40282347e+38
#define MIN_RADIUS 2
@@ -573,7 +573,7 @@ void BlurEngine::run()
break;
case BC_RGB_FLOAT:
-BLUR(float, 1.0, 3);
+BLUR(float, MAX_FLT, 3);
break;
case BC_RGBA:
@@ -582,7 +582,7 @@ void BlurEngine::run()
break;
case BC_RGBA_FLOAT:
-BLUR(float, 1.0, 4);
+BLUR(float, MAX_FLT, 4);
break;
case BC_RGB161616:
diff --git a/cinelerra-5.1/plugins/titler/titler.C b/cinelerra-5.1/plugins/titler/titler.C
index b4157811..7ebbfaec 100644
--- a/cinelerra-5.1/plugins/titler/titler.C
+++ b/cinelerra-5.1/plugins/titler/titler.C
@@ -2306,9 +2306,9 @@ void TitleTranslateUnit::process_package(LoadPackage *package)
switch( output->get_color_model() ) {
case BC_RGB888: TRANSLATE(unsigned char, 0xff, 3, 0);break;
- case BC_RGB_FLOAT: TRANSLATE(float, 1.0, 3, 0); break;
+ case BC_RGB_FLOAT: TRANSLATE(float, MAX_FLT, 3, 0); break;
case BC_YUV888: TRANSLATE(unsigned char, 0xff, 3, 0x80); break;
- case BC_RGBA_FLOAT: TRANSLATE(float, 1.0, 4, 0); break;
+ case BC_RGBA_FLOAT: TRANSLATE(float, MAX_FLT, 4, 0); break;
case BC_RGBA: TRANSLATE(unsigned char, 0xff, 4, 0);break;
case BC_YUVA: TRANSLATE(unsigned char, 0xff, 4, 0x80); break;
}
--
2.48.1
--
Cin mailing list
Cin@lists.cinelerra-gg.org
https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Some tests on blending
пн, 31 мар. 2025 г., 16:34 Andrea paz via Cin : > Obviously it was my fault: I had not removed the clip in Blend Program > I re-tested and most of the color-related plugins do not have > clipping. Unfortunately (at least for me) some of the most important > plugins have it: > > Blur > Try to look for switch(color) in plugins/blur/blur.C and replace for testing 1.0 for rgba/rgb float cases with FLT_MAX ? Like in our earlier work case BC_RGBA_FLOAT: BLUR(float, 1.0, 4); break; If it does not break plugin we probably can go for each noted plugin and try to find where they clip Color 3 Way > Color Space > Foreground > Histogram > Histogram Bezier > Title > Videoscope > > I remember an attempt by Andrew with Adam to try to engage him on the > Histogram clipping, but Adam was not really interested: > https://github.com/heroineworshiper/hvirtual/issues/8 > > @Phyllis > Do you think it's good to indicate in the manual the plugins that do > the clipping? > -- > Cin mailing list > Cin@lists.cinelerra-gg.org > https://lists.cinelerra-gg.org/mailman/listinfo/cin > -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Some tests on blending
Andrea, upon your approval I will check into source GIT, tone_mapping.bp in cinelerra-5.1/plugins/blendprogram and modify cinelerra-5.1/plugins/blendprogram/Makefile to add that line like so: > BP_OBJS = \ > chromakey.bp.so \ > tone_mapping.bp.so \ > background.bp.so > On Tue, Apr 1, 2025 at 7:04 AM Andrea paz wrote: > Great, thank you. > This function, in my opinion, could be put in “=>Syslib”. So if it is > needed it is already contained in CinGG, if it is not needed it can be > ignored without any other effect. > -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Some tests on blending
Obviously it was my fault: I had not removed the clip in Blend Program I re-tested and most of the color-related plugins do not have clipping. Unfortunately (at least for me) some of the most important plugins have it: Blur Color 3 Way Color Space Foreground Histogram Histogram Bezier Title Videoscope I remember an attempt by Andrew with Adam to try to engage him on the Histogram clipping, but Adam was not really interested: https://github.com/heroineworshiper/hvirtual/issues/8 @Phyllis Do you think it's good to indicate in the manual the plugins that do the clipping? -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Some tests on blending
On Tue, 1 Apr 2025, Andrea paz wrote: > This function, in my opinion, could be put in \u201c=>Syslib\u201d. So if it > is > needed it is already contained in CinGG, if it is not needed it can be > ignored without any other effect. This is exactly that, what I decided to write the blend plugins for: to provoke users themselves to extend the program, to construct their own effects, for more creativity. ___ Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email s...@nmr.nioch.nsc.ru ___ -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Some tests on blending
Great, thank you. This function, in my opinion, could be put in “=>Syslib”. So if it is needed it is already contained in CinGG, if it is not needed it can be ignored without any other effect. tone_mapping.bp Description: Binary data -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Some tests on blending
Andrea, I removed the Overlays.tex changes as you requested -- I should have asked you about that before adding. I will update Plugins.tex in GIT as you provided soon. On Mon, Mar 31, 2025 at 12:23 PM Andrea paz wrote: > I append new plugins.text > > > I wonder if you think parts of it should be included in the manual too > but so far it seems already covered. > > I wouldn't really know what to put in. > > PS: I saw the manual update you mentioned in a previous mail about my > attempts at Gimp-like functions. They are not very important and do > not serve to solve cases where our overlays work differently from > CinCV's. Besides, the tests I did are not representative, as is > evident from the thread. I would remove that commit... > -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Some tests on blending
Andrea, "Yes" I think it is worthwhile to indicate which plugins do the clipping if you want to take on that task. Also, in reading the information in this topic that Georgy has noted, I wonder if you think parts of it should be included in the manual too but so far it seems already covered. If you disagree and can work it in, do that too. Thank you, Phyllis On Mon, Mar 31, 2025 at 7:34 AM Andrea paz wrote: > Obviously it was my fault: I had not removed the clip in Blend Program > I re-tested and most of the color-related plugins do not have > clipping. Unfortunately (at least for me) some of the most important > plugins have it: > > Blur > Color 3 Way > Color Space > Foreground > Histogram > Histogram Bezier > Title > Videoscope > > I remember an attempt by Andrew with Adam to try to engage him on the > Histogram clipping, but Adam was not really interested: > https://github.com/heroineworshiper/hvirtual/issues/8 > > @Phyllis > Do you think it's good to indicate in the manual the plugins that do > the clipping? > -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Some tests on blending
On Mon, 31 Mar 2025, Andrea paz wrote:
> With:
> printf ("%g\n", R(0));
> gives me a very long series of \u201c1's\u201d; perhaps a result for each
> pixel
> of the 1920x1080 frame?
Yes, it is what I meant. The function is called repeatedly for each pixel of
the whole frame. Moreover, if 'parallelize' is switched on in the blend
program dialog, and there is 'PARALLEL_SAFE' in the function, then the order
of printed lines is unpredictable.
> With:
> if (PIX_X == 0 && PIX_Y == 0) printf ("%g\n", R(0));
> It gives me a simple 1 for all plugins, with very few exceptions
> when the frame is replaced by other colors for which the different
> value is shown (always under 1).
It is clipping.
> I can't interpret the results: I always get 1, even for Choma Key
> (Avid) and for Blender Algebra itself. I have tried all the internal
To be completely sure, you can do the following.
Deactivate (or detach) the other plugin which was placed between the two
BlendPrograms.
In the first BlendProgram (with R(0)=2.0;) add the line just after the
assignment of 2.0:
if (PIX_X == 0 && PIX_Y == 0) printf ("It was set: %g\n", R(0));
So you will see what was assigned to R(0) (with the first program) as well
as what was read back (with the second one).
Recheck that both functions have COLORSPACE_RGB (not YUV, not HSV).
Recheck that your project is RGBA_FLOAT (not 8 bit) and that clipping is
switched off in the dialogs of both BlendPrograms. So BlendPrograms
themselves should not introduce any color transformations.
Then test once again what values come out.
Actually it might be that some base function clips in between, such as
read_frame().
___
Georgy Salnikov
NMR Group
Novosibirsk Institute of Organic Chemistry
Lavrentjeva, 9, 630090 Novosibirsk, Russia
Phone +7-383-3307864
Email s...@nmr.nioch.nsc.ru
___
--
Cin mailing list
Cin@lists.cinelerra-gg.org
https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Some tests on blending
On Sun, 30 Mar 2025, Andrea paz via Cin wrote:
>11 | printf(R);
printf ("%g\n", R(0));
This should do but will dump out a long scribble. Better the following:
if (PIX_X == 0 && PIX_Y == 0) printf ("%g\n", R(0));
This will print the value of R in the upper left corner of the frame, once
for each frame. You can also specify other coords for PIX_X and PIX_Y
instead of zeros.
___
Georgy Salnikov
NMR Group
Novosibirsk Institute of Organic Chemistry
Lavrentjeva, 9, 630090 Novosibirsk, Russia
Phone +7-383-3307864
Email s...@nmr.nioch.nsc.ru
___
--
Cin mailing list
Cin@lists.cinelerra-gg.org
https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Some tests on blending
Interesting video at 25:00. Really noisy equipment. It almost looked like the short few seconds video on the Sony screen was Herman Hermits singing "Henry the 8th". On Sat, Mar 29, 2025 at 5:35 PM Andrew Randrianasulu < randrianas...@gmail.com> wrote: > > > вс, 30 мар. 2025 г., 00:32 Phyllis Smith : > >> About the following commentary by Andrew -- Cinelerra in any version is >> still a worthwhile tool even if the only people who use it are us. As long >> as my desktop/laptop that were set up to automatically get files to the >> webserver, I hope to keep working as a moderator. I like it! >> > > > ;) > > > And here is little (just 250kg) reminder about what kind of problem > digital editing initially aimed to simplify/solve: > > https://m.youtube.com/watch?v=PSYNL5FXAPg > > at around 25:00 ;) Imagine spending years alongside those machines! > >> >> Problem is - I tried to ignite some interest in cingg but may be I am >>> wrong person to do that, or developers want different codebase (more modern >>> c++, etc). >>> >>> But we do not have thousands of users who can somewhat cooperate and buy >>> year or so of professional developer time (HaikuOS gains like $50k in >>> donations yearly, but they whole OS .. without /proc fs curiously ). >>> >>> So we stick in circle where devs consider our program irrelevant/too >>> complex/too alien and users lack feature/bug resolution so they just >>> install whatever others install - DVR, blender . >>> >>> In some sense I think we are much more OG opensource/libre/community >>> software, not piggybacking on big corporate codedrop/development, but few >>> cares about that ... >>> >>> -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Some tests on blending
About the following commentary by Andrew -- Cinelerra in any version is still a worthwhile tool even if the only people who use it are us. As long as my desktop/laptop that were set up to automatically get files to the webserver, I hope to keep working as a moderator. I like it! Problem is - I tried to ignite some interest in cingg but may be I am wrong > person to do that, or developers want different codebase (more modern c++, > etc). > > But we do not have thousands of users who can somewhat cooperate and buy > year or so of professional developer time (HaikuOS gains like $50k in > donations yearly, but they whole OS .. without /proc fs curiously ). > > So we stick in circle where devs consider our program irrelevant/too > complex/too alien and users lack feature/bug resolution so they just > install whatever others install - DVR, blender . > > In some sense I think we are much more OG opensource/libre/community > software, not piggybacking on big corporate codedrop/development, but few > cares about that ... > > -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Some tests on blending
On Sat, 29 Mar 2025, Andrew Randrianasulu wrote: > I wonder if limitation more about displaying results here relative to > processing algo? We can make histogram 2x longer, but what if generated > result STILL out of new range? I wonder how other software solves it With BlendProgram one can directly test whether some particular effect clips colors or not. Set project colorspace to RGB(A)-Float. Attach a blend program (just to this single track) which fills all pixels with some solid color with the value out of bounds (for example, R=2.0, G,B=0.0, A=1.0). I think, A=1 is important as it could be taken as an additional multiplier. Don't forget to switch off clipping also in the BlendProgram dialog. Then attach the effect in question. Then attach the second blend program which prints in console the value of R and changes nothing. You will clearly see how the color R=2.0 was modified by the plugin in the middle between the two BlendPrograms. ___ Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email s...@nmr.nioch.nsc.ru ___ -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Some tests on blending
сб, 29 мар. 2025 г., 13:35 Andrea paz : > Well, we have the three main color correction plugins that clip the > final result: Histogram-Bezier, Color 3 way and the Videoscopes (I > don't know about Blue Banana and the various Contrast, Hue, etc.). > This is a big limitation. But Adam told me that Cinelerra is not made > for color correction! > with big enough hammer ... I wonder if limitation more about displaying results here relative to processing algo? We can make histogram 2x longer, but what if generated result STILL out of new range? I wonder how other software solves it Meanwhile, ffmpeg git gained color management support, but I am not sure how useful it might be for us: https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/dddf536d3d575a8f7cf7eb85bdd2b2d20fc36369 and related commits. Problem is - I tried to ignite some interest in cingg but may be I am wrong person to do that, or developers want different codebase (more modern c++, etc). But we do not have thousands of users who can somewhat cooperate and buy year or so of professional developer time (HaikuOS gains like $50k in donations yearly, but they whole OS .. without /proc fs curiously ). So we stick in circle where devs consider our program irrelevant/too complex/too alien and users lack feature/bug resolution so they just install whatever others install - DVR, blender . In some sense I think we are much more OG opensource/libre/community software, not piggybacking on big corporate codedrop/development, but few cares about that ... > Always arguing pointlessly, moreover, these are topics that have been > addressed many times in the past, I would like CinGG to be usable by > hardware not adapted with 8-bit color models, but to be fully > consistent with the RGBA-FLOAT color model (with adapted hardware). > That way they would all have a chance to use it to the fullest. But > even here Einar told me, many years ago, that it was not possible to > do it unless we rewrote almost everything from scratch, and besides, > the performance would be poor. > > However, I apologize for bringing up these topics again. My initial > purpose was just wanting to retry IgorV's tutorial with Blend Algebra. > -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Some tests on blending
> I wonder how other software solves it I can't answer that. I think the best possible is DaVinci resolve's Color Management, but they are unattainable levels for anyone. You can see their manual from p. 215 to p. 250: https://documents.blackmagicdesign.com/UserManuals/DaVinci_Resolve_19_Reference_Manual.pdf > In some sense I think we are much more OG opensource/libre/community > software, not piggybacking on big corporate codedrop/development, but few > cares about that ... I, too, think that Stalmann's Free software is dead and that Open Source managed and supported by big companies is now predominant (Linux Foundation). Just look at the success (I think deserved) of the Rust language, which is replacing other languages, however with the side effect of eliminating all GPL licenses in favor of MIT and Apache licenses (they have now remade the GNU core utils in Rust). Praise to CinGG (and you few contributors) who still follow the beautiful idea of GG and Phyllis! -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Some tests on blending
Well, we have the three main color correction plugins that clip the final result: Histogram-Bezier, Color 3 way and the Videoscopes (I don't know about Blue Banana and the various Contrast, Hue, etc.). This is a big limitation. But Adam told me that Cinelerra is not made for color correction! Always arguing pointlessly, moreover, these are topics that have been addressed many times in the past, I would like CinGG to be usable by hardware not adapted with 8-bit color models, but to be fully consistent with the RGBA-FLOAT color model (with adapted hardware). That way they would all have a chance to use it to the fullest. But even here Einar told me, many years ago, that it was not possible to do it unless we rewrote almost everything from scratch, and besides, the performance would be poor. However, I apologize for bringing up these topics again. My initial purpose was just wanting to retry IgorV's tutorial with Blend Algebra. -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Some tests on blending
On Fri, 28 Mar 2025, Andrew Randrianasulu wrote: > > No, I didn't. I knew that Blend Algebra uses float and RGB by default, Not exactly so. Blend Algebra uses float always, doing the conversions if the color model is not float already. Also it uses alpha always, imitating it if the color model itself does not have it. And between RGB, YUV, HSV it uses by default that mode which is declared in the function (or the project's color model if the function declares nothing). The user can override the function's color model in the plugin dialog. He cannot override float and alpha usage, but it is possible to inquire inside the function which native color space is used in the project and if it has alpha channel or not (outside the function). > > and it just seemed interesting to me to see the differences this makes > > from patchbay (I chose YUV media on purpose, for the test, because > > they are the most common). I would actually like to see all parts of > > CinGG unified to the internal float engine and RGB color space, but I > > know that is impossible, as each tool/plugin goes its own way. > If I understand correctly most non-ffmpeg plugins should technically work > in all modes, due to their history. But clipping probably occur in some of > them even in rgba-float mode as you discovered earlier? Many plugins work in all modes just because the particular color model does not matter (like plugins that transform only geometry and do not transform colors). Other plugins also work in all modes because they do the necessary color space conversions (like Chromakeys). I'd expect, there are also a few color model dependent ones. In RGBA-Float some plugins can clip internally, to investigate it is a distinct work. But clipping can occur later depending on the output format when rendering, or on the display driver, or on the usage of opengl accelerators. For example, unclipped R = -1.0 is displayed as black by the opengl driver and as red by the X11 driver. ___ Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email s...@nmr.nioch.nsc.ru ___ -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Some tests on blending
пт, 28 мар. 2025 г., 12:07 Andrea paz via Cin : > > If you really want to compare RGBA with YUVA under Blend Algebra, then > you > > have either to change COLORSPACE_RGB to COLORSPACE_YUV in the blend > > function, or to remove the 'COLORSPACE' declaration completely, or to > change > > the colorspace parameter in the plugin dialog from the default 'by > function' > > to the explicit 'RGB' or 'YUV' value. Have you done this? > > No, I didn't. I knew that Blend Algebra uses float and RGB by default, > and it just seemed interesting to me to see the differences this makes > from patchbay (I chose YUV media on purpose, for the test, because > they are the most common). I would actually like to see all parts of > CinGG unified to the internal float engine and RGB color space, but I > know that is impossible, as each tool/plugin goes its own way. If I understand correctly most non-ffmpeg plugins should technically work in all modes, due to their history. But clipping probably occur in some of them even in rgba-float mode as you discovered earlier? In some sense rgba/yuv modes are "speed hacks", but 4x difference in cpu/mem usage is not something you can easily dismiss as irrelevant (this is why variants of yuv still around). So I > think it is important to point out each time that with various tools, > various results can be achieved. I guess for programmers this is an > obvious and unnecessary aspect. But not to me. Another impossible > thing I would like to do is to indicate on the manual how each > tool/plugin works, regarding color spaces, color depths, and use of > the internal engine in float, but that is information available only > in very few cases. > In short, I think Blend Algebra is more reliable (consistent) than > patchbay overlays, because of its internal conversions to a single > mode; this is precisely why I would like to try IgorV's tutorial with > Blend Algebra again. > I guess I was just talking nonsense and doing useless tests! :) > well, consistency has cpu cost, while I think yuv modes were left in half-working state in cingg because you only have defined equations for rgba compositing? With assumption that users who use yuv mode will not use overlays (say because it either pre edit/assembly or final pass from yuv compressed source). > PS: @Phyllis; actually “polemica” is an intalian word I used, I don't > know why DeepL translated it into “polemic.” > -- > Cin mailing list > Cin@lists.cinelerra-gg.org > https://lists.cinelerra-gg.org/mailman/listinfo/cin > -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Some tests on blending
> If you really want to compare RGBA with YUVA under Blend Algebra, then you > have either to change COLORSPACE_RGB to COLORSPACE_YUV in the blend > function, or to remove the 'COLORSPACE' declaration completely, or to change > the colorspace parameter in the plugin dialog from the default 'by function' > to the explicit 'RGB' or 'YUV' value. Have you done this? No, I didn't. I knew that Blend Algebra uses float and RGB by default, and it just seemed interesting to me to see the differences this makes from patchbay (I chose YUV media on purpose, for the test, because they are the most common). I would actually like to see all parts of CinGG unified to the internal float engine and RGB color space, but I know that is impossible, as each tool/plugin goes its own way. So I think it is important to point out each time that with various tools, various results can be achieved. I guess for programmers this is an obvious and unnecessary aspect. But not to me. Another impossible thing I would like to do is to indicate on the manual how each tool/plugin works, regarding color spaces, color depths, and use of the internal engine in float, but that is information available only in very few cases. In short, I think Blend Algebra is more reliable (consistent) than patchbay overlays, because of its internal conversions to a single mode; this is precisely why I would like to try IgorV's tutorial with Blend Algebra again. I guess I was just talking nonsense and doing useless tests! :) PS: @Phyllis; actually “polemica” is an intalian word I used, I don't know why DeepL translated it into “polemic.” -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Some tests on blending
On Thu, 27 Mar 2025, Andrea paz via Cin wrote:
> workaround by IgorBeg. I have tried further testing, now that we have
> Blend Algebra that allows us to customize the various Blends.
Regarding Blend Algebra I'd point out to the following details.
In patchbay's overlay modi or in the Overlay plugin the results can differ
depending on the RGBA or YUVA color model. But in Blend Algebra, as long as
you have 'COLORSPACE_RGB' statement in the function code, and the other
default settings, comparing RGBA with YUVA is useless: both are converted by
the plugin's engine to RGBA-Float before calling user's expressions and
therefore should give identical results by definition.
If you really want to compare RGBA with YUVA under Blend Algebra, then you
have either to change COLORSPACE_RGB to COLORSPACE_YUV in the blend
function, or to remove the 'COLORSPACE' declaration completely, or to change
the colorspace parameter in the plugin dialog from the default 'by function'
to the explicit 'RGB' or 'YUV' value. Have you done this?
If your color model is YUV without alpha channel, then you cannot see the
result if it is not placed on Top: the upper track will hide it completely.
By the way, under Blend Algebra you have the possibility to calculate
overlay arithmetic also in the HSV color space ('COLORSPACE_HSV'), can
hardly imagine what should come out:)
___
Georgy Salnikov
NMR Group
Novosibirsk Institute of Organic Chemistry
Lavrentjeva, 9, 630090 Novosibirsk, Russia
Phone +7-383-3307864
Email s...@nmr.nioch.nsc.ru
___
--
Cin mailing list
Cin@lists.cinelerra-gg.org
https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Some tests on blending
Andrea, thank you very much! I will put these out on the web server too with the rest of the testing information at ...download/testing/BlendPluginsExamples (not there yet, will do tomorrow because I want to try them first). That is the beauty of Georgy's 2 new plugins -- any user can have any blend they want now! P.S. I learned a new word today - "polemic". I never even heard the word before and at first I thought it was Italian, but then when I looked it up, I realized I probably never heard it before because it is not something I would do. On Thu, Mar 27, 2025 at 9:51 AM Andrea paz via Cin < cin@lists.cinelerra-gg.org> wrote: > In reference to the email: > https://www.mail-archive.com/cin@lists.cinelerra-gg.org/msg04905.html > and to the whole of the following discussion, which includes a > workaround by IgorBeg. I have tried further testing, now that we have > Blend Algebra that allows us to customize the various Blends. > I do not know whether it is appropriate to reopen an issue that is now > closed and has also led to tensions (you can see the article: > > https://linuxvideoediting.blogspot.com/2022/09/transparent-text-effect-with-Cinelerra-part2.html > . > I warn that it contains polemics). So I will only report the result of > some of my tests; they are probably not even worth reading. > -- > Cin mailing list > Cin@lists.cinelerra-gg.org > https://lists.cinelerra-gg.org/mailman/listinfo/cin > -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Some tests on blending
чт, 27 мар. 2025 г., 18:51 Andrea paz via Cin : > In reference to the email: > https://www.mail-archive.com/cin@lists.cinelerra-gg.org/msg04905.html > and to the whole of the following discussion, which includes a > workaround by IgorBeg. I have tried further testing, now that we have > Blend Algebra that allows us to customize the various Blends. > I do not know whether it is appropriate to reopen an issue that is now > closed and has also led to tensions (you can see the article: > > https://linuxvideoediting.blogspot.com/2022/09/transparent-text-effect-with-Cinelerra-part2.html > . > I warn that it contains polemics). So I will only report the result of > some of my tests; they are probably not even worth reading. > They surely worth reading, thanks for doing them. Hopefully this time question of who have most correct overlay arith will be put to rest definitively ;) Have as much time as you need. -- > Cin mailing list > Cin@lists.cinelerra-gg.org > https://lists.cinelerra-gg.org/mailman/listinfo/cin > -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
