ChromakeyHSV menu much improved
Checked into GIT an anonymous contribution for a much improved ChromakeyHSV menu to include: 1) Now there are individual boxes on the left side where you can either keyin a distinct value or use the up/down arrows to change the value. This gives you a much better control than where previously you could only move the slider to jiggle the number you wanted. Also, much easier to see what all the values are at once whereas before you had to click on each individual diamond setting to see just 1 value. 2) You can reset individual parameters to the default. Before you could only reset them all so you would lose a particular value you were already happy with. 3) The menu is more visible over a larger space making it easier to see. 4) Plus some minor code cleanup to eliminate at least 1 duplicate line and to put some "int" on same lines as statement. P.S. Someone indicated that ChromakeyHSV had some kind of bug, but I was wondering if Andrea ever found out exactly what that was? since it looks OK to me.
P.S. Someone indicated that ChromakeyHSV had some kind of bug, but I was wondering if Andrea ever found out exactly what that was? since it looks OK to me.
Great job; thank you! One problem with the plugin can be seen in the following video: https://streamable.com/yyze7y In practice, "Min Saturation" behaves like "Saturation Offset" when in fact it should behave as in the following figure: https://postimg.cc/HjZDcvr2 (Min Sat should form a new smaller wedge [dotted line], instead it creates an arc without more spike, which is the right behavior of Sat Offset). However, I always hope that we will be able to integrate Adam's new plugin, which is a great evolution of ours and works very well.
On Mon, 13 May 2024, Andrea paz via Cin wrote:
However, I always hope that we will be able to integrate Adam's new plugin, which is a great evolution of ours and works very well.
The Adam's plugins Chroma key (HSV) and Color Swatch are here. Apply the patch from attachment and please test. The new Chroma key plugin has the name "Chroma key (Avid)", so in addition to, not replacing the old version. The utility plugin, recommended by Adam in connection with chromakey adjustments, is called "Color Swatch". Remember, any manipulations with alpha masks, including chromakeying, in CinGG require a bottom track with some opaque background, otherwise the transparent holes are displayed as if the same track without transparency be located under it. Although this behavior is sometimes confusing, I am not sure if it is a bug, and not done so by design. More information in BT 662. Have a nice testing Georgy _______________________________________________________________________________ Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email [email protected] _______________________________________________________________________________
The patch works perfectly, as always with your work. The two plugins are also perfect. More details I post them in MantisBT. I can't thank you enough.
Remember, any manipulations with alpha masks, including chromakeying, in CinGG require a bottom track with some opaque background, otherwise the transparent holes are displayed as if the same track without transparency be located under it. Although this behavior is sometimes confusing, I am not sure if it is a bug, and not done so by design.
Thank you also for your insight on transparency. I think it is an important issue that recurs often in new user requests. I think the other NLEs behave more intuitively however I am afraid that you cannot make changes in CinGG without upsetting the program. Maybe add in the manual the warning to use an opaque lower track when working with the alpha channel. I noticed that if in the bottom track you disable the “Don't send to Output” button, then the background color is correctly black, but that is not a useful fact.
On Sun, 9 Jun 2024, Andrea paz wrote:
Remember, any manipulations with alpha masks, including chromakeying, in CinGG require a bottom track with some opaque background, otherwise the transparent holes are displayed as if the same track without transparency be located under it. Although this behavior is sometimes confusing, I am not sure if it is a bug, and not done so by design.
Thank you also for your insight on transparency. I think it is an important issue that recurs often in new user requests. I think the other NLEs behave more intuitively however I am afraid that you cannot make changes in CinGG without upsetting the program. Maybe add in the manual the warning to use an opaque lower track when working with the alpha channel. I noticed that if in the bottom track you disable the \u201cDon't send to Output\u201d button, then the background color is correctly black, but that is not a useful fact.
Andrea, as long as (partly) transparent image sits in a file on disk (or in some program's memory array), there is no problem how to process it. The problem arises when: a) one has to display the image on screen b) it is necessary to convert the image into some format which does not support transparency Different programs behave differently. For example, if some, let's say, PNG with alpha channel, is loaded in Gimp, transparent parts are shown as a greyish checkboard. Cinelerra-HV-9 does the same. Such an approach is very useful while painting, but in a presentation looks quirky. Another image viewer, xv, shows transparent parts as black. If you insert such an image in MS Word, it looses transparency, and transparent parts are shown as white. When you create an image in Gimp, you can configure which color, including complete transparency ('chessboard'), will be used for background. Some other programs do not configure this and always behave in some way. When you save an image into, let's say, JPG, Gimp shows a warning that the image has to be 'flatten', and converts alpha channel into background color (white). Let's imagine, we have created some project in CinGG which uses transparency and did not put a solid track on very bottom. We have left some areas transparent (by mistake or by design) and started Render. I am not a great specialist and do not know if common video formats (mpeg, h264, ...) support transparency. Perhaps not. Then it is a question, what is to be rendered instead of transparency. Chessboard? Black? Or white? I am not sure. Now I can imagine that the current Cin-GG's approach might be done by design: the user has full control on this property by putting that background on the bottom track which he needs (even may be different in various parts of timeline). If the user did not do it, it is his mistake. But the program has to do something, and it makes then virtually so as if the last track be put on the bottom once again without transparency (this has a visual appearance as if any masks on that track stopped to work). Another approach might be to create (in program's memory, invisible to the user) some backgrount track and let user to configure its color. This would be perhaps more intuitive for the user but less flexible (for example, if different backgrounds are needed at different times on the timeline). _______________________________________________________________________________ Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email [email protected] _______________________________________________________________________________
I agree with your explanation; CinGG's way of treating the alpha channel is fine. Sorry, I was unclear because I (stupidly!) did not mention that the white mask on a black background (the “matte”) is convenient only with the “Show Mask” option of the plugin, and not during normal operation. When setting up the mask, we need to see the lower track image to adjust the edge and despill grading; however, although it is not very important, seeing the matte in Show Mask is a small help in highlighting the regularity of the mask we are going to create and in discovering unwanted points of black in the figure to be extracted (or points of white in the black background). However, if a user needs to see the matte they can always turn on “Don't send to Output” on the bottom track when using “show Mask.” PS: in the manual, I wrote “Min Saturation” as the beginning of the saturation range, while I wrote “Saturation Offset” as an additional cutoff from the value of “Min Saturation.” I think I got it totally wrong, also because of the bug that their effect looks the same. Seeing your new plugin, the position of “Saturation Start” corresponds to “Saturation Offset” and not to “Min Saturation” as I had written. Seeing the code, can you confirm my mistake? PPS: Is the new plugin (Avid) a total rewrite of Jerome's or just an enhancement of the same code? I mean, do credits go to both Jerome and Adam or just the latter?
On Sun, 9 Jun 2024, Andrea paz wrote:
The patch works perfectly, as always with your work. The two plugins
Here is another patch to Chroma key (Avid) to be applied after the first one. I noticed that the button 'Reset' at the bottom of the plugin's dialog looks lonely, and added four more buttons to it: Store, Recall, Exchange, Undo. All buttons work globally on the whole parameter set. They work as follows (similarly to a pocket calculator): Store: stores the complete current parameter set in memory. Recall: sets all the parameters to the values, memorized previously by 'Store'. Exchange: swaps current values and Store'd values of the parameters. Undo: restores all the parameters to the undo'ed values. Reset: reset to default values, as earlier. Each time the ChromaKey dialog is opened, the 'Store' values are cleared and reset to default. Therefore, if you press 'Recall' having not pressed 'Store' beforehand, it will do the same as 'Reset'. Each time the dialog is closed, the 'Store' values are forgotten (reset to defaults). As long as the dialog remains opened, 'Store' values remain intact, even if the current timeline position changes. The operations on distinct parameters (turning sliders etc.) do not update the 'Undo' values. The following operations update values for subsequent 'Undo': Global Recall, Exchange, Reset buttons (but not the buttons.which reset individual parameters). Opening the dialog. Moving current position in the timeline. The information and the patch are uploaded to the same BT 662. Now I invite to test these new toys:) _______________________________________________________________________________ Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email [email protected] _______________________________________________________________________________
The second patch also gives no problems. Good idea of Store/Recall, Exchange and Undo. I ran several tests without any problems.
Thank you so much, Georgy_Salnikov, for the new ChromaKey(Avid) plugin! I have not applied the patches and not used the new plugin, yet. As soon as I will do. Good idea to have the new plugin without to touch the others for compatibility with older Projects. And I would like to thank Igor_Vladimirsky for the great explanation on that, in his blog/manual; and to thank the programmer, Adam Williams, who implemented this feature on Cinelerra-HV. And thanks to Andrea_paz, for insiting on some features and the Manual. ;-) IgorBeg
There are now builds for users to test: https://cinelerra-gg.org/download/testing/cin-x86_64_chromakeyavid.AppImage (works on ubuntu 16 + newer O/S) https://github.com/einhander/cin-gg-packages/releases (packages for specific newer O/S) Included in the above builds is the newest ContextManual.pl for using Alt-h Help within CinGG. Refer to BT 0000661 <https://www.cinelerra-gg.org/bugtracker/view.php?id=661> for more info. About "Either we leave both plugins intact, retaining three ChromaKeys (RGB, HSV, and Avid) and probably confusing unfamiliar users which ChromaKey HSV is the right one." I think we have to leave all 3 intact to continue to support old projects; just like we still support 32-bit computers. At one time, we tried to eliminate one of the "Motion" plugins and then ended up putting it back because a user's old project would no longer work correctly. I think Andrea can explain in the manual about which Chromakey to use.
On Sun, 9 Jun 2024, Andrea paz wrote:
alpha channel. I noticed that if in the bottom track you disable the \u201cDon't send to Output\u201d button, then the background color is correctly black, but that is not a useful fact.
If one disables 'send to output' for the bottom track to get black background in the track with alpha channel above it, then alpha masks in that track above bottom (Chromakeyed masks as well as conventional vector masks) cease to work. Perhaps to have correct black background and working masks, one has to fill bottom track with solid black color and 100% opacity, and then perform all the works with masks and transparencies in tracks above it. _______________________________________________________________________________ Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email [email protected] _______________________________________________________________________________
Thank You, Phyllis! 12/05/2024 17:33, Phyllis Smith via Cin wrote:
Checked into GIT an anonymous contribution for a much improved ChromakeyHSV menu to include:
1) Now there are individual boxes on the left side where you can either keyin a distinct value or use the up/down arrows to change the value. This gives you a much better control than where previously you could only move the slider to jiggle the number you wanted. Also, much easier to see what all the values are at once whereas before you had to click on each individual diamond setting to see just 1 value. 2) You can reset individual parameters to the default. Before you could only reset them all so you would lose a particular value you were already happy with. 3) The menu is more visible over a larger space making it easier to see. 4) Plus some minor code cleanup to eliminate at least 1 duplicate line and to put some "int" on same lines as statement.
P.S. Someone indicated that ChromakeyHSV had some kind of bug, but I was wondering if Andrea ever found out exactly what that was? since it looks OK to me.
With the new, beautiful, configuration window, we need to change the image in the manual.
чт, 16 мая 2024 г., 21:43 Andrea paz via Cin <[email protected]>:
With the new, beautiful, configuration window, we need to change the image in the manual.
tnx! sorry, I am distracting myself with details of openpic realization in Powermacs and similar offtop .... --
Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Thank you. The new image of chromakeyhsv menu has been checked into GIT. On Thu, May 16, 2024 at 12:43 PM Andrea paz via Cin < [email protected]> wrote:
With the new, beautiful, configuration window, we need to change the image in the manual. -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
participants (5)
-
Andrea paz -
Andrew Randrianasulu -
Georgy Salnikov -
Igor BEGHETTO -
Phyllis Smith