 |
@Andrea_Paz I have finally applied your Manual changes for ChromaKey Avid/Hsv as you attached in the note above as avid_hsv.tar.gz. I did have some issues which I will email you about. And I did make just a few punctuation/grammatical changes before adding to GIT. |
 |
I would like to be clear, if possible. I don't have any of my projects that use the Chromakey(HSV) effect. And I couldn't test on those since they don'use that specific effect. I am sure that sge did an excellent job on the ChromaKey(Avid) effect. Mine are just "projections" on the other users. |
|
|
@Andrea_Paz @IgorBeg 1 vote for / 1 vote against. For now we can leave both in for a couple of months and see if other users want to voice an opinion. As Andrea suggested, there is now an AppImage at: https://cinelerra-gg.org/download/testing/cin-x86_64_replaced_chromakeyhsv.AppImage that includes patch cgg-avid3 and cgg-avid4 by @sge. And with both in, you can test that AppImage at: https://cinelerra-gg.org/download/testing/cin-x86_64_chromakeyavid.AppImage |
 |
As soon as the new (Avid) plugin, when having replaced the old (HSV) one, accepts the old parameters from the old projects out of the box, while giving visually the same or slightly better results even without altering these old parameter values (this is the question to @Andrea_Paz whether it is so), then there is one more reason to replace the obsoleted plugin with the newer one. Let us imagine several scenario. Some users who already used the old (HSV) plugin earlier, may be won't ever think to switch to the better one because they will continue to use the familiar old plugin just out of habit. Some users who never used either plugin perhaps can take the old plugin just by chance, or just because its name contains the well known letters (HSV), and won't guess that another plugin with strange name (Avid) might be better. The experienced users which have already completed projects with old (HSV) plugin, perhaps will not see any incompatibilities at all, not having to reedit these finished projects. For new projects they will just evaluate the improvements. The users with unfinished projects used the old (HSV) plugin, before having upgraded the CinGG package, will also notice nothing. When a user with an unfinished project with old (HSV) plugin upgrades CinGG and gets the new plugin version, he can either leave the plugin settings as they were automatically converted from the old plugin parameters (provided that the results look similarly, a question to @Andrea_Paz), or they can consider to try tuning some of them to make yet better. In this way, replacing plugins might be an additional motivation for some users to switch: for existing projects they will not have to replace each instance or keyframe of the plugin and manually set a lot of parameters, simple reopening project with uprgaded CinGG will be sufficient. |
|
|
@Andrea_Paz I am sorry, Andrea. I think I explained my point of view in the https://www.cinelerra-gg.org/bugtracker/view.php?id=662#c5673 post (on @ALL). I put myself in the shoes of another User who spent a lot of time on his own Project (or more). Maybe I wrong to think so. It would be better to post the question in the Mailing Lists to find out what other Users think about. |
 |
@IgorBeg (old projects) I don't know what to say. Georgy's work is so complete and perfect that every parameter of the old (hsv) is carried over into the new (Avid). So there is no need to get your hands on it and there can be no compatibility problems. Then, I always recommend working on it because you get far better results (if only for the evolved Spill Suppression). I thought the pictures I reported showed that. Perhaps if Phyllis can make an additional appimage with patches 3 and 4 (replacing the current test appimage), someone with old projects can confirm if there is a need to work on it or it can be left without intervention. Honestly, I am sorry to lose patches 3 and 4, because they are precisely to avoid problems with old projects. |
|
|
@sge No I did't mean to change the name of the button from "Reset" to "Default". For me it it right how it is; only the position on the window is not in the usual place, and you explained why. When the "Default" button is present in the GUI, the "Clear" button on the right side of the slider "follows" the values of the "Reset" button. If there isn't the "Default" button, and the "Reset" button state for the sliders is different by zero then the "Clear" button will follow that value. Other plugins work so (see Whirl plugin, if I remember correctly). |
|
|
@IgorBeg Actually 'Reset' does not set parameters to zero. It assigns them some builtin default values. Do you mean, the button must be called 'Default' instead of 'Reset'? |
|
|
@ALL Thanks Andrea_Paz for testing and compare HSV vs Avid. I have never used Chromakey(HSV) in my projects, I have used and use only Cromakey. But, I think, that an User who has worked several hours on a project, or more than one, using ChromaKey(HSV) would not be happy to have to review everything, especially if several months have passed; more, if the user has applied that plugin on many clips and with keyframes. Could it be a problem to keep all the three plugins, from the point of view of the memory occupied by the program or the file size? If not, it is better to keep all the three plugins, for me. @sge About "Actually I wanted firstly to leave Reset at the left corner where it originally was, and put the other buttons after it. But then I realized: all the other reset buttons - which reset individual parameters - are placed at the right window border. Therefore it is more logical to put the button which invokes a global reset also there, to the right side." I understand you but in some Plugins there are two buttons in the bottom of the plugin's window: Reset and Default buttons. You see the the Reset button on the left side and the Default button on the right side of the window: Reset button change all the values to zero (or move the sliders to the left); Default button change all the values to the "default" state , the state where that plugin may do a first good result for the user (more or less). However, It doesn't matter. It is only a my idea of the GUI Layout. |
|
|
No problem if you decide to keep the 3 plugins. I made the comparisons just to reassure IgorBeg that there are no compatibility issues with the old projects. @IgorBeg What do you think IgorBeg? Better to be sure that you don't have any problems and just keep them all? |
|
|
@Andrea_Paz Since you have done a lot of comparison testing and replacement with the old HSV and the new AVID, it sounds like you are quite certain that Avid should just replace Hsv. But what about In the email IgorBeg stated "Good idea to have the new plugin without to touch the others for compatibility with older Projects."? I am somewhat conflicted as to what the best decision is. |
|
|
It seems to me that with patch_4 you get the best result, without the "holes" inside the figure. However, retouching is always advisable.
image1.jpg (161,426 bytes) |
|
|
@Andrea_Paz This fourth patch (to be applied after all the preceding three) is tiny. Chroma key (HSV) when built with this patch differs in the following. The parameters which have identical names in the old and new ChromaKey incarnations, work as before. For the other 4 parameters (Saturation Start, Saturation Line, Spill Saturation, Spill Angle) the plugin searches not only for their actual tag names, but also for that names which were used in its predecessor, the old plugin. Either the new, or the old tags will be found and used to set parameter values. To my mind, the visual appearance when that parameters are transferred under old tag names from the old project, looks somehow worse, than if these 4 parameters just get default values. It is due to different interpretation of these parameters in the old and new algorithms. Nevertheless you can try both (with or without cgg-avid4.diff.gz) and choose which one yields better picture. cgg-avid4.diff.gz (539 bytes) |
|
|
@sge Everything works fine, thank you. The old project is loaded without warning and the result on the Compositor is the same as with the old plugin. Looking at the two images I had posted earlier, we are in the situation of the hsv.jpg image. So it is convenient to open the plugin and make some adjustments to get to the avid.jpg image. |
|
|
@Andrea_Paz Here is the third patch. 1) It gets rid of the old obsoleted Chroma key (HSV). 2) It renames Chroma key (Avid) so that it is called now Chroma key (HSV), in place of the obsoleted one. This patch is to be applied as follows. 1) You should have already applied the first two patches, cgg-avid.diff.gz and cgg-avid2.diff.gz. 2) Apply additionally the third patch, cgg-avid3.diff.gz. 3) Now you can remove the redundant source directory plugins/chromakeyavid and the redundant binary bin/plugins/video/chromakeyavid.plugin. 4) configure; make; make install After build, projects using the old version of Chroma key (HSV) will load successfully, most of the the parameters accepted, their values loaded. That parameters which have different names in the new plugin get their default values. CinGG should neither crash nor hang due to this plugin substitution. Please test. cgg-avid3.diff.gz (19,414 bytes) |
|
|
I have compiled CinGG without (hsv). I imported a project made with appimage (so without (Avid)); the project loads but a warning appears that it cannot find the Chroma Key (HSV). the result is that the top track is not shown in the Compositor window, even though it is in the timeline. Deleting the effect from the timeline causes the track to reappear in Compositor. You can then proceed to put in (Avid) and redo the extraction from the beginning. By not ruining the project but just forcing you to redo the extraction, I remain with the idea of doing a complete replacement of the two plugins. |
|
|
I wrote the parts of the new plugins and modified the old one (hsv). I also updated the images. (Avid) should be put before(hsv) because it also contains theory. In addition, out of curiosity, I add the results of a very complicated chroma key (the veil transparencies), done with (hsv) and with (avid). The difference is incredible... Later I will try to compile CinGG without (hsv). @Phyllis There is a sentence that links to an explanation video; you can omit it for now because I haven't completed the video yet.
hsv.jpg (35,881 bytes)
avid.jpg (37,376 bytes)
avid_hsv.tar.gz (888,065 bytes) |
|
|
@PhyllisSmith @Andrea_Paz I meant the other edition to replace the (HSV). 1) We remove (rename) the old (HSV) source directory. 2) We rename the new (Avid) source directory so that it will be called (HSV). 3) We make the necessary changes in the (Avid) sources so that the new plugin will be recognized by CinGG under the name (HSV), not (Avid), and that the new plugin will recognize XML tags in project files related to HSV. I can do this, it is not difficult. But better after testing is complete, for the case if one wants to compare both plugins in the same project, for example. |
|
|
@Andrea_Paz About "If you tell me how to compile CinGG without (HSV) I can give it a try and see the result." To test: Edit cinelerra-5.1/plugin_defs and delete the "chromakeyhsv" line. Edit cinelerra-5.1/plugins/Makefile and delete the "chromakayhsv" line. Then rebuild. |
|
|
@PhyllisSmith @Andrea_Paz About evtl replacing Chroma key (HSV) with Chroma key (Avid), by removing the former followed by renaming the latter, it is not so disastrous as two removed incarnations of Motion plugin several years ago. If we do this, the old projects will still load. Most of ChromaKey parameters will be interpreted by the new plugin, and several new parameters will be set to default values. It would be even not too difficult to make the new plugin to read also that obsoleted parameters and set the values to the new parameters with similar names. There is even a simple possibility to convert the XML project file with help of sed, like: cat oldproject.xml | sed -e 's/"SATURATION"/"SATURATION_START"/g' | sed -e 's/"MIN_SATURATION"/"SATURATION_LINE"/g' > newproject.xml Nevertheless I think, the user will still have to make some adjustments to chromakeys as the old and the new algorithms behave differently in some aspects. About Color Swatch I think, it was good Adam's idea to make it a separate plugin, it is much more flexible than a builtin subroutine available in one particular effect only and inaccessible to others. @IgorBeg Actually I wanted firstly to leave Reset at the left corner where it originally was, and put the other buttons after it. But then I realized: all the other reset buttons - which reset individual parameters - are placed at the right window border. Therefore it is more logical to put the button which invokes a global reset also there, to the right side. Also in pocket calculators the button 'STO', or 'M', is usually somewhere on the left side, the button 'RCL' to the right of it, and the Clear button, 'C', is usually the rightmost one. About Color Swatch, I only ported the effect from Adam's implementation, and left his GUI intact. I think, this plugin has straightforward design, it is its advantage, and there is hardly any reason to make its GUI heavier. |
|
|
I think (Avid) should completely replace (HSV) they are the same as plugins but one is clearly better. I think the word incompatibility (used by Adam) is inappropriate; I don't think a project created with only (HSV) won't load in a CinGG with only (Avid), if anything you have to re-extract the key, but this is always advisable because the efficiency of (Avid) is superior to (HSV). If you tell me how to compile CinGG without (HSV) I can give it a try and see the result. OffTopic: In the original Spectramatte plugin, Color Swatch is not a plugin, but just a feature built into the plugin, I think its interface depends on that. Adam put it as a TODO, but he doesn't think it's easy. |
|
|
@PhyllisSmith Thank you for the AppImage! I tested it, very quickly on my UbuntuStudio_16.04. @sge If I can,... int the Chromakey(Avid) would it be possible to move the Reset button on the left side of the window (first one from left to right), for consistency with other plugins? Just a suggestion. @ALL I agree with Phyllis, it is better to keep all three plugins for compatibility. In the Manual we could write two words about. The Chromakey plugin is the simplest and easiest to use. OffTopic (Color Swatch plugin): I quickly tested "Color Swatch" plugin: I don't like the GUI. Maybe I will do a photomontage for an idea. For me a plugin should always have a Reset button (and, some time, a Default button,...depends), a TextBox near the slider, and a Clear button for that parameter. In the "Color Swatch" there are two radio buttons, so a different layout is needed, I think. |
|
|
@sge @Andrea_Paz @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 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. |
|
|
When testing is finished, we'll have to make a decision. To my feelings, the new plugin Chroma key (Avid) actually obsoletes the older Chroma key (HSV), it does the same job just better. 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. Or we rename the Avid plugin into Chroma key (HSV) in place of the older version, as Adam did, and break compatibility with projects which used the old version. |
|
|
@sge @Andrea_Paz (and as always, Adam!) Thank you! I have compiled both and just dragged them to the timeline with no obvious problems seen. Later I will create a test AppImage for the website for others to check and will check them into GIT. Once I check them in, Andrey automatically rebuilds the newer O/S versions so that too will be available for others to check. Oh, and there is nothing worse than a "lonely" button (wink, wink). |
|
|
Here I created the second patch for Chrome key (Avid), it has 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. The buttons 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. The buttons look at first glance intuitive, nevertheless one has to comment some technical details. All buttons work globally on the whole parameter set. 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. I invite to test these new toys:) cgg-avid2.diff.gz (3,910 bytes) |
|
|
Thanks, Georgy. I installed the patch without any problems and Chroma Key(Avid) and ColorSwatch work perfectly. Now “Min Saturation” works well and has changed its name to “Saturation Start” (while “Saturation Offset” is now called “Saturation Line”). The “DeSpill” section has also changed profoundly allowing more varied and less intrusive changes. Color Swatch only serves to make the Foreground color as a HSV color wheel; it is useful for testing because it allows you to emphasize the shape of the Key color mask and the relative operation of the various parameters. For example, it is easy now to see the problem with “Min Saturation,” comparing it to the behavior of “Saturation Start.” Ultimately you can achieve significantly better results than with the plugin (HSV). |
|
|
cgg-avid.diff.gz (17,506 bytes) |
- Anonymous
