Fwd: Chromakey + blur testcase from IgorV
---------- Forwarded message --------- From: Andrew Randrianasulu <[email protected]> Date: Thu, Feb 22, 2024 at 2:19 AM Subject: Chromakey + blur testcase from IgorV To: Phyllis Smith <[email protected]> oh, it weights 1.4 mb, so not for list ... I think swapping effects relative to cin-cv makes image in compositor more like it was supposed to be but still. even if I disable chromakey - blur behaves strange, like rounding unprocessed (processed as black?) transparency into image ..? ===== https://drive.google.com/file/d/1kqt4bfy53drwQqOvD5RIJ1E7UWeJNF1A/view?usp=s... hopefully uploaded to gdrive for everyone to test/see ....
Igor Vladimirsky also made a good video tutorial on how Chroma key (HSV) plugin works: https://www.youtube.com/watch?v=QATi9J6Q8uw
So, I am only assuming that the Blur plugin works correctly in CV as I do not have an executable that works. Since the HV version (8 and "latest after 8 binary" running on Ubuntu 18) appears to be the same flaw as CinGG, it must be that the CV experts fixed it at some time. CinGG was based on HV initially and then the CV mods were merged in but when there were major differences between .C programs/.h headers, a decision had to be made of which to use. Apparently in the case of Blur, the wrong one was made based on the assumption that HV blur worked in a quick simple case of a single track video. What a disappointment that patches and improvements are not accepted and merged into a base. Anyway, I will see if I can fix CinGG blur based on CV code which varies greatly from the HV code. Hopefully, that will be easier than Chromakey where I have made no progress. I think swapping effects relative to cin-cv makes image in compositor
more like it was supposed to be but still.
even if I disable chromakey - blur behaves strange, like rounding unprocessed (processed as black?) transparency into image ..?
What is the problem with Chroma Key (HSV)? I can't find the original discussion. It seems to me that CinGG has problems when dealing with the alpha channel, so in overlays, Keys, etc. See also here (without taking offense at the jibes he throws toward CinGG users): https://linuxvideoediting.blogspot.com/2022/09/transparent-text-effect-with-... IgorV sees the following problems in CinGG (comparing with CV and HV): 1- Color rendering 2- Overlays 3- Conversion between color models (Adam has made updates, but states that Cin will always have problems with YUV(A) and recommends using only RGBA-FLOAT) 4- Blur
This quote says it all (I believe it was Einar who said this in an email but I could be wrong): * "There will always be more bugs!"* What is the problem with Chroma Key (HSV)? I can't find the original
discussion.
There was not much discussion, but this is the email that mentioned it and has a reference to where it was stated there was a problem, but no description of what it was: https://www.mail-archive.com/[email protected]/msg07215.html
It seems to me that CinGG has problems when dealing with the alpha channel, so in overlays, Keys, etc. See also here (without taking offense at the jibes he throws toward CinGG users):
It is useful to point out bugs in CinGG -- criticism is welcome/helpful and no offense is taken. the following problems in CinGG (comparing with CV and HV):
1- Color rendering 2- Overlays 3- Conversion between color models (Adam has made updates, but states that Cin will always have problems with YUV(A) and recommends using only RGBA-FLOAT) 4- Blur
A most useful feature of CinGG is that if *Blur *does not work the way you expect it to, you can always use one of the 6 other FFmpeg blur plugins instead with various differences: *F_gblur, *F_avgblur, F_boxblur, F_dblur, F_smartblur, F_yaepblur. Same thing with *Chromakey and ChromakeyHSV *- you can use *F_chromakey*, F_chromahold, F_chromanr, F_chromashift. P.S. On the other side, look at the number of "Yes" versus "No" for Features in: https://cinelerra-gg.org/download/differences.pdf
You are right: CinGG is very feature rich and can also use the ffmpeg plugins. Plus I also tested the other native blur plugins (linera blur, radial blur, etc) and they all work normally with Chroma Key (HSV). It is the only Blur plugin that interacts with Chroma Key giving problems. PS: I don't understand the problems with Chroma Key (HSV); for the little I have tested it, it works fine for me (without Blur plugin). What precisely should I be testing?
By my test, using IgorVlad's test case, Blur plugin works as it is (I am using "CinGG-20240131-x86_64-older_distros.AppImage"). Just press the Reset button in the Blur plugin and set the desired value. IgorBeg Andrew Randrianasulu via Cin wrote:
even if I disable chromakey - blur behaves strange, like rounding unprocessed (processed as black?) transparency into image ..?
On Sun, Feb 25, 2024 at 3:47 PM Igor BEGHETTO via Cin < [email protected]> wrote:
By my test, using IgorVlad's test case, Blur plugin works as it is (I am using "CinGG-20240131-x86_64-older_distros.AppImage"). Just press the Reset button in the Blur plugin and set the desired value.
I think you win The Internet today ... because it works!??? But why?? well, this is question for me, I got some clues .... (disabled in gui param "alpha determinated radius" we probably not initialize correctly) So, even if we are not very coherent team - lesson of the day "apes *together* strong!"
IgorBeg
Andrew Randrianasulu via Cin wrote:
even if I disable chromakey - blur behaves strange, like rounding unprocessed (processed as black?) transparency into image ..?
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
IgorBeg, we always count on you when it comes to plugins working right. I agree with Andrew-R, "but why?" is mysterious. By my test, using IgorVlad's test case, Blur plugin works as it is (I am
using "CinGG-20240131-x86_64-older_distros.AppImage"). Just press the Reset button in the Blur plugin and set the desired value.
To me the story was even more odd. When I uploaded IgorV's project, it was completely out of whack. I tried various settings with the same result. When I did the reset the situation improved but the horizontal slider still did not work. Using values other than 0 brought the background to black as well as the masked part (the green flag). Using just the Vertical slider on the other hand worked fine. I also tried the LinearBlur plugin by setting it to horizontal and everything worked fine. After IgorBeghetto's email I reset it again and now everything is fine, even the horizontal slider.
NB: Completely agree with Andrew's conclusion about apes! (quote from "planet of the apes" trilogy?)
вс, 25 февр. 2024 г., 21:46 Andrea paz via Cin <[email protected]>:
NB: Completely agree with Andrew's conclusion about apes! (quote from "planet of the apes" trilogy?)
no, just me paraphrasing some internet meme: Ape (chimp) looking at smartphone, where we see prompt: "enter password" Chimp enters "ape" Smartphone says "weak password!" Chimp after some thinking "apeapeape" Smartphone: "Password accepted" Line of thought: "Apes together strong!" --
Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
As to "why" you have to do a Reset, I think it must have something to do with having been saved the way it was. Because I ran with a blank configuration (CIN_CONFIG=/tmp/bcast1 ./bin/cin), loaded the sample .xml file, deleted the Chromakey plugin on the timeline (because we already agreed it has a problem), clicked on Rest for the Blur plugin, THEN SAVED the xml. Next time I loaded that .xml, there was no need for a Reset in Blur. However, since I am making a minor change for the LUT information in the Manual, I will add a line to the Blur plugin to suggest it things look weird, to start fresh with the Reset button. On Sun, Feb 25, 2024 at 11:41 AM Andrea paz <[email protected]> wrote:
To me the story was even more odd. When I uploaded IgorV's project, it was completely out of whack. I tried various settings with the same result. When I did the reset the situation improved but the horizontal slider still did not work. Using values other than 0 brought the background to black as well as the masked part (the green flag). Using just the Vertical slider on the other hand worked fine. I also tried the LinearBlur plugin by setting it to horizontal and everything worked fine. After IgorBeghetto's email I reset it again and now everything is fine, even the horizontal slider.
But why?? well, this is question for me, I got some clues .... (disabled in gui param "alpha determinated radius" we probably not initialize correctly)
Like pointed out by Andrew and Phyllis it concerns the "Alpha determines radius" checkbox option in the GUI: it was hidden, by the code, in December 2021. For compatibility reasons and for future development it has been left there. The parameter about "Alpha determines radius" is A_KEY. A_KEY can be 0 or 1. When we press the Reset button in the Blur plugin window the values are: Radius=5; Horizontal= Vertical= A= R= G= B= 1; A_KEY= 0. Old projects may have saved that parameter (A_KEY) to 1 so, in the special cases, is needed some workarounds to put it to 0. 1. Open the file project (.xml) in a text editor and change the A_KEY value of the BLUR from 1 to 0. It can be useful to change ALL these value using "Find and replace..." tool. 2. In Cinelerra-GG program, open the project. Click on the cog icon (Preset edit) of the Blur effect bar and the "Keyframe parameters" window is open. There, you can see the A_KEY parameter and change it: select the A_KEY parameter and in the "Edit value" change it from 1 to 0,... and press OK button. If you open the "CGG-CHKEY-BLUR-BUG.xml" test file by Igor_V (Igor_ubuntu) in a text editor you can see the line number #87. <KEYFRAME POSITION=0 DEFAULT=1><BLUR VERTICAL=1 HORIZONTAL=1 RADIUS=89 R=1 G=1 B=1 A=1 *A_KEY=1*></BLUR> Change the A_KEY from 1 to 0 and save as "CGG-CHKEY-BLUR-BUG_test2.xml". Open that Project file in the Cinelerra-GG and we can see that the Blur is working right. If you want to use the #2 point written above it is the same. Thank you! IgorBeg
пн, 26 февр. 2024 г., 12:07 Igor BEGHETTO via Cin < [email protected]>:
But why?? well, this is question for me, I got some clues .... (disabled in gui param "alpha determinated radius" we probably not initialize correctly)
Like pointed out by Andrew and Phyllis it concerns the "Alpha determines radius" checkbox option in the GUI: it was hidden, by the code, in December 2021. For compatibility reasons and for future development it has been left there.
I think IgorV pointed out (to me) that this checkbox only worked with horizontal blur, not with both enabled? For now we can try and modify in plugins/blur/blur.C void BlurMain::save_data(KeyFrame *keyframe) output.tag.set_property("A_KEY", config.a_key); replace config.a_key with 0 here ? so it will be always saved as 0 void BlurMain::read_data(KeyFrame *keyframe) config.a_key = input.tag.get_property("A_KEY", config.a_key); with config.a_key = 0; so it will ignore saved 1 setting. At least this is my theory/idea for now. If we go with this plan we probably should left original lines commented out with "//" and add line saying why reading/writing forced to 0 for this param (due to disabled gui config in blurwindow.C) The parameter about "Alpha determines radius" is A_KEY. A_KEY can be 0 or
1. When we press the Reset button in the Blur plugin window the values are: Radius=5; Horizontal= Vertical= A= R= G= B= 1; A_KEY= 0.
Old projects may have saved that parameter (A_KEY) to 1 so, in the special cases, is needed some workarounds to put it to 0. 1. Open the file project (.xml) in a text editor and change the A_KEY value of the BLUR from 1 to 0. It can be useful to change ALL these value using "Find and replace..." tool. 2. In Cinelerra-GG program, open the project. Click on the cog icon (Preset edit) of the Blur effect bar and the "Keyframe parameters" window is open. There, you can see the A_KEY parameter and change it: select the A_KEY parameter and in the "Edit value" change it from 1 to 0,... and press OK button.
If you open the "CGG-CHKEY-BLUR-BUG.xml" test file by Igor_V (Igor_ubuntu) in a text editor you can see the line number #87. <KEYFRAME POSITION=0 DEFAULT=1><BLUR VERTICAL=1 HORIZONTAL=1 RADIUS=89 R=1 G=1 B=1 A=1 *A_KEY=1*></BLUR> Change the A_KEY from 1 to 0 and save as "CGG-CHKEY-BLUR-BUG_test2.xml". Open that Project file in the Cinelerra-GG and we can see that the Blur is working right. If you want to use the #2 point written above it is the same.
Thank you!
IgorBeg -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
No, I would not change the code. I would left as it is. The reasons are multiple, for me: - if you open an old project, that project works right with A_KEY=1. An user could have written, "it doesn't work", at that time. The test case shows why it doesn't work. - Now, you can change A_KEY value from 0 to 1, if needed, using the "Keyframe parameters" window. If you change the code, that will no longer be possible. IgorBeg 26/02/2024 14:34, Andrew Randrianasulu wrote:
For now we can try and modify in plugins/blur/blur.C
void BlurMain::save_data(KeyFrame *keyframe) output.tag.set_property("A_KEY", config.a_key); replace config.a_key with 0 here ? so it will be always saved as 0 void BlurMain::read_data(KeyFrame *keyframe) config.a_key = input.tag.get_property("A_KEY", config.a_key); with config.a_key = 0; so it will ignore saved 1 setting. At least this is my theory/idea for now. If we go with this plan we probably should left original lines commented out with "//" and add line saying why reading/writing forced to 0 for this param (due to disabled gui config in blurwindow.C)
пн, 26 февр. 2024 г., 17:58 Igor BEGHETTO via Cin < [email protected]>:
No, I would not change the code. I would left as it is. The reasons are multiple, for me: - if you open an old project, that project works right with A_KEY=1. An user could have written, "it doesn't work", at that time. The test case shows why it doesn't work. - Now, you can change A_KEY value from 0 to 1, if needed, using the "Keyframe parameters" window. If you change the code, that will no longer be possible.
Yeahhhh ... So, for now probably documentation update is needed, and if we completely figure it out may be gui checkbox will be re-enabled at some point. IgorV also reported some strangeness with AgingTV gui params (they not as interactive as they should?) but I have't looking at this problem yet. Not even sure if it makes sense to do release this month? On the other hand not even sure if we will able to fix more than one problem in next 30 days ....
IgorBeg
26/02/2024 14:34, Andrew Randrianasulu wrote:
For now we can try and modify in plugins/blur/blur.C
void BlurMain::save_data(KeyFrame *keyframe) output.tag.set_property("A_KEY", config.a_key); replace config.a_key with 0 here ? so it will be always saved as 0 void BlurMain::read_data(KeyFrame *keyframe) config.a_key = input.tag.get_property("A_KEY", config.a_key); with config.a_key = 0; so it will ignore saved 1 setting. At least this is my theory/idea for now. If we go with this plan we probably should left original lines commented out with "//" and add line saying why reading/writing forced to 0 for this param (due to disabled gui config in blurwindow.C) -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
I tried to update the text of Blur plugin in the manual. See if it is okay (to be added at the end): Problems may arise, with old projects or with Cinelerra-CV/Cinelerra-HV projects, regarding the parameter \textit{alpha determines radius}. However, to avoid problems, it was hidden in the GUI's plugin. For compatibility reasons and for future development it has been left in the code. The parameter about \textit{alpha determines radius} is \texttt{A\_KEY}. \texttt{A\_KEY} can be 0 or 1. When we press the \texttt{Reset} button in the Blur plugin window the values are: \texttt{Radius=5}; \texttt{Horizontal= Vertical= A= R= G= B= 1}; \texttt{A\_KEY= 0}. Old projects may have saved that parameter (A\_KEY) to 1 so, in the special cases, is needed some workarounds to put it to 0. \begin{enumerate} \item Open the file project (\texttt{.xml}) in a text editor and change the A\_KEY value of the BLUR from 1 to 0. It can be useful to change ALL these value using \textit{Find and replace...} tool. \item In \CGG{} program, open the project. Click on the cog icon (\textit{Preset edit}) of the Blur effect bar and the \textit{Keyframe parameters} window is open. There, you can see the A\_KEY parameter and change it: select the \texttt{A\_KEY} parameter and in the \texttt{Edit value} change it from 1 to 0,... and press \texttt{OK} button. \end{enumerate}
Not even sure if it makes sense to do release this month? On the other hand not even sure if we will able to fix more than one problem in next 30 days ... I would bring out a new appimage because DeJay needed the appimage with Color 3 Way working...
Not even sure if it makes sense to do release this month? On the other
hand not even sure if we will able to fix more than one problem in next 30 days ...
I would bring out a new appimage because DeJay needed the appimage with Color 3 Way working...
Yes, I was planning on making new appimages because Color 3 Way is used a lot and an error is not good.
I tried to update the text of Blur plugin in the manual. See if it is okay (to be added at the end):
Seems reasonable and I edited it some by changing one option to just use Reset and re-save the project instead of editing the .xml. Editing is open to mistakes -- I just made one and ended up with an empty .xml file which could be disastrous. No, I would not change the code. I would left as it is. The reasons are
multiple, for me:
Agreed. At least *about 10 years ago* it seems that the A_KEY code was commented out in HV (may have been longer but that is as far back as I could easily find). There does not seem to be A_KEY code in cv blur plugin which is a lot different then the HV baseline. This simply does not matter because HV code is the baseline for CinGG with some cv mods merged in and no serious attempt was ever made to specifically ensure CinGG was compatible for a cv project. some strangeness with AgingTV gui params (they not as interactive as they
should?) but I have't looking at this problem yet.
In looking at Aging plugin, I have seen no problem and am not going to waste any more time on it -- already wasted way too much time on Blur when for projects that are less than 10 years old, there was not even a problem. And the code matches that of HV-8 with the exception of the addition of the Reset button which is so valuable.
вт, 27 февр. 2024 г., 00:02 Phyllis Smith via Cin < [email protected]>:
Not even sure if it makes sense to do release this month? On the other
hand not even sure if we will able to fix more than one problem in next 30 days ...
I would bring out a new appimage because DeJay needed the appimage with Color 3 Way working...
Yes, I was planning on making new appimages because Color 3 Way is used a lot and an error is not good.
I tried to update the text of Blur plugin in the manual. See if it is okay (to be added at the end):
Seems reasonable and I edited it some by changing one option to just use Reset and re-save the project instead of editing the .xml. Editing is open to mistakes -- I just made one and ended up with an empty .xml file which could be disastrous.
No, I would not change the code. I would left as it is. The reasons are
multiple, for me:
Agreed. At least *about 10 years ago* it seems that the A_KEY code was commented out in HV (may have been longer but that is as far back as I could easily find). There does not seem to be A_KEY code in cv blur plugin which is a lot different then the HV baseline. This simply does not matter because HV code is the baseline for CinGG with some cv mods merged in and no serious attempt was ever made to specifically ensure CinGG was compatible for a cv project.
some strangeness with AgingTV gui params (they not as interactive as they
should?) but I have't looking at this problem yet.
In looking at Aging plugin, I have seen no problem and am not going to waste any more time on it -- already wasted way too much time on Blur when for projects that are less than 10 years old, there was not even a problem. And the code matches that of HV-8 with the exception of the addition of the Reset button which is so valuable.
... I only wanted to note this somewhere so hopefully *I* will have some added motivation to look at it! Well, at least in very "shake a toy and see if anything comes out" way ...
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
some strangeness with AgingTV gui params (they not as interactive as they
should?) but I have't looking at this problem yet.
... I only wanted to note this somewhere so hopefully *I* will have some added motivation to look at it! Well, at least in very "shake a toy and see if anything comes out" way ...
It would be much appreciated if you have time to look at AgingTV. HV does
not allow for modifying the parameter values nor do the other TV plugins -- DotTV, HolographicTV, and BurningTV. It would also be great if the parameters in these other 3 were made visible and modifiable. You could "shake a lot of toys" that way !!!.
participants (4)
-
Andrea paz -
Andrew Randrianasulu -
Igor BEGHETTO -
Phyllis Smith