 |
Resolved and closing. I think we are done here. The final changes will all be included in the May 31 final build. |
 |
@PhyllisSmith (about @DeJay) Fast reply, sorry. I read and saw the pdf. More info are needed. For example, I would like to see HistogramRGB and WaveformRGB in Videoscope tool: they give me more information than Waveform graph. And a screencast would be useful. I am not an expert in this sector (Colourist). Color3Way and Histogram (and Histogram Bezier) are different tools. I think, you can not compare the two tools. Histogram changes more parameters with an only touch: Contrast, Saturation, and Luminance. Sometimes it is better to change the values of the three channels (Red, Green, Blue) separately than change only the Value channel. The Value parameter in Histogram do not change only the luminance. Maybe that an User think it change only the Luminance. |
|
|
@IgorBeg If you have any extra time could you look at this Videoscope related problem and help me to re-create it? GG and I are unable to detect the problem. Description is at: https://www.cinelerra-gg.org/forum/help-video/new-videoscope/#post-1090 But here it is also. It seems to be a problem with the Histogram plugin. he Vectorwheel has allowed me to identify a problem with my colour correction, which turns out to be a glitch in the Histograms. "Using either Histogram to set black and white points prior to setting saturation, I find excess blue showing on the scope and the red/yellow shows decreased levels i. e. the colour balance is skewed towards blue. Resetting Histogram centres it again. My attempts to rebalance it have failed. It is not a scope fault as if I use Colour3Way it does not happen." |
 |
Fix plugins.tex Plugins.tar.gz (96,477 bytes) |
|
|
@Andrea_Paz Sorry for all of the confusion. For us here it makes sense because we look at the program code. It was clearer when there was only "Refresh on Stop" but there are definite advantages to "Refresh on Release". Do you want me to fix the Plugins.tex wording or were you planning on doing that? I promise that there will be no more changes and the latest changes were last minute trying to figure out whether or not gg could combine the 2 (but no, could not). Thank you for your patience -- we all need a lot of that these days. GG has moved on to Audio work as requested by AVLinux + others. |
|
|
@IgorBeg 1. Refresh on Stop= Refresh on Release= disabled When Play button is pressed or Dragging the pointer (with LMB) in the timeline Bar the Videoscope is always update. OK 2. Refresh on Stop= enabled; Refresh on Release= disabled. When Play button is pressed the Videoscope is update on stop. Dragging the pointer (with LMB) in the timeline Bar the Videoscope is always update. [I don't like this! But it is not important.] OK 3. Refresh on Stop= disabled; Refresh on Release= enabled. When Play button is pressed the Videoscope is never update. To update the Videoscope you have to click on the Compositor canvas, for example. Dragging the pointer (with LMB) in the timeline Bar the Videoscope is only update on release. OK |
|
|
@Andrea_Paz To summarize the 3 cases: 1. Refresh on Stop= Refresh on Release= disabled When Play button is pressed or Dragging the pointer (with LMB) in the timeline Bar the Videoscope is always update. 2. Refresh on Stop= enabled; Refresh on Release= disabled. When Play button is pressed the Videoscope is update on stop. Dragging the pointer (with LMB) in the timeline Bar the Videoscope is always update. 3. Refresh on Stop= disabled; Refresh on Release= enabled. When Play button is pressed the Videoscope is never update. To update the Videoscope you have to click on the Compositor canvas, for example. Dragging the pointer (with LMB) in the timeline Bar the Videoscope is only update on release. Can you test it and confirm or less, please? |
|
|
I could be wrong, but I think the dragging worked in the May 6 release, and no longer in the May 7 release (I wrote the changes in the manual based on tests). The transport buttons, however, as you say, always work. But with dragging it happens that, if I keep Refresh on Stop enabled, the scopes are updated in realtime which should be the behavior of Refresh on Stop disabled. See the video. In any case I'm fine with this, but we have to change the manual where I wrote that dragging works too, leaving only the Transport buttons. https://streamable.com/ecjx0g |
|
|
@Andrea_Paz As Pierre already mentioned, although it would have been convenient to allow for both, the code just was impossible to work with. "Refresh on Release" updates when you actually "release" (let up on) the mouse. The "Refresh on Stop" does not have a similar action of letting up on the mouse but is rather a "press" of a button, like the space bar on the timeline when playing. They are 2 different actions in the program code. It is easy to visualize how you would like it to work, but the code is not at the artificial intelligence stage yet. I would like to close this BT if Andrea agrees that there is no bug in the current implementation. |
 |
Here, with the release of Thu 6 May 2020 18:38:17". "Refresh on Stop" works. Obviously one excludes the other; either "Refresh on Stop" or "Refresh on Release" applies. |
|
|
With the (last) release "Thu, 7 May 2020" no longer works "Refresh on Stop": whether it is active or not it always works in realtime. "Refresh on Release" continues to work well. |
|
|
@Andrea_Paz Thanks for the final revision of Videoscopes for the manual. I made a small revision to the wording based on GG's final addition and checked it into GIT. |
|
|
@Phyllis What you and GG have done works very well and represents a great improvement in the usability of the videoscope. As it is now configured under "Refresh on Release", if you have the screen space, it is quite possible to leave the videoscope visible for easy viewing when needed, without slowing down the scrolling of the images. The size of the box in the "Configuration" menu is now quite adequate. Nice work! |
|
|
@Pierre The size of the "Settings" (French = Configuration) button has been increased so now the German Einstellugen translation fits also. Even though the combination of Refresh on Stop AND Release could not be made to work. the addition of dragging on the timeline in the TimeBar now provides some relief. Also when using Refresh on Release, if you use the TimeBar to change the cursor position in either Drag and Drop mode or Cut and Paste mode, when you release the button, the Videoscope will be updated. If you would like to test: https://cinelerra-gg.org/download/testing/cinelerra-5.1-mint18-x86_64-static.txz I think these 2 additional TimeBar functions on the timeline provide a pretty good combination! |
|
|
Okay, thanks for the information. Efectively under the "Refresh on Release" option, if you choose to activate the normal scrolling of the image (in the viewer or the composer) after having stopped the image, just click directly on this image for the videoscope to be updated. Otherwise, you can choose to proceed with the "Refresh on Stop" option. In any case, thank you for increasing the possibilities of operation. |
|
|
@Pierre GG quote: "The scope GUI button is attached to the menu bar of the composer or viewer. The events, button press/release and mouse motion, are routed via the parent window. Routing from the main window to the composer can be done but requires a lot of extra locking which is not normally part of the GUI design." It might not be impossible to combine the 2 but from a programming point of view would be a bad idea. You can just move the mouse to the compositor window which will update the Videoscope without changing the frame (with Click to Play disabled). Thanks for testing! |
|
|
@PhyllisSmith Yeah, plumbing's a thing of the past. It won't cry anymore and neither will I... "Refresh on Release" works really well. However "Refresh on Stop" is not included in this mode. This means that if I activate the normal scrolling mode, the videoscope doesn't update when I stop. I believe that the "Refresh on Stop" feature should be included in "Refresh on Release" or both options should be selectable separately or together. |
|
|
@Pierre I guess it has been so long while you were working on your plumbing, that I forgot which version you were using. Here is Mint 18. https://cinelerra-gg.org/download/testing/cinelerra-5.1-mint18-x86_64-static.txz @Andrea_Paz Thanks for the manual update/ |
|
|
"Refresh on Release" is OK, for me. I modified the manual. videoscopes.tar.gz (250,006 bytes) |
|
|
@PhyllisSmith Thanks for the tar. However, my secondary computer running Linux 19.3 is old and not very powerful; I have trouble assessing whether the tar works as desired. My main computer is only running LinuxMint 18.3. If you prepare a corresponding tar, I will be happy to test it on it. |
|
|
@Pierre There is a Mint 19.3 static tar at: https://cinelerra-gg.org/download/testing/cinelerra-5.1-mint19-x86_64-static.txz that has an additional setting (as suggested by Sam so as not to interfere with how IgorBeg works). It is called "Refresh on Release". It works on the Compositor and Viewer because they have a "canvas". These 2 Refresh options will never work on the Videoscope plugin that is on the timeline and that plugin will remain as is. GG got this working today. I have yet to change the size of the button for "Settings" so that the French translation will fit. Thanks for pointing that out. I hope you have time to test the Videoscope dragging. |
|
|
DeepL played a trick on me... Obviously it's in the french version and not English |
|
|
The box in the "setting" menu in Scopes is called "Configurations" in English. The size of the box for this menu does not allow to display the whole word; 3 letters are replaced by "."
Teexte incomplet.png (3,205 bytes) |
|
|
@Sam Thank you so much for the info and the video. I guess you are using the same computer for the Resolve and Cinelerra-GG. So it is good to compare the two different programs and their response. @Pierre Thanks for your test and the info. Yes, some plugin can not be used with Proxy without scaler, it's a pity for me; in those case I have to do a different workaround. |
|
|
@IgorBeg I don't always use proxys, but with the mixers and the extra processing load they involve, it's useful. Depending on the type of sources, the difference in gain over the number of frames/seconds varies. Yes, "Proxy without scaler" is a bit faster and the difference on the drag with the videoscope is less shocking. But, I usually use the Titler plugin on all my projects (and sometimes even for subtitles during editing) and it's one of the plugins that gains from using "Proxy with scaler"... |
|
|
@Pierre @Sam Pierre's picture looks very good on the website. Thanks. We have not completely given up on "Refresh on Drag Stop" but it does look quite hopeless. |
|
|
@Sam I then sent you two corrected versions directly by email, the correct version is the last one, named "Multi-screen_3". |
 |
@Pierre Many thanks for sending the picture! I will put it on the website the next days. |
|
|
@IgorBeg Resolve has solved it quite differently. In the color tab you can see that the individual clips inserted in the timeline can be clicked. You jump from footage to footage. Then you do the color correction of each clip. Of course you can also move the playback position within the clip, more or less everything is shown in real time. When dragging the playback position I hardly notice any delay in the playback of the footage, the only thing that is sometimes updated with a time delay is the histogram. You can see it very well in the video. https://streamable.com/ih2xcd |
|
|
@Pierre Thanks Pierre for your reply and the info. I understand you would like to have the Videoscope window always open. With my computers I always have to find a balance and disable those functions that I don't need at the time; so I disable "Draw media" in Patchbay to save cpu consumes, or disable "Play track" on some track for the credit track, for example, where I am not working on. And, of course, using Proxy (without scaler). In your "Affichage.png" I can see you are using Proxy with scaler. How does your project behave with Proxy without scaler? (If you think to do a test, create a Backup, please, otherwise if something goes wrong you could point your finger at me and say: it is your fault, IgorBeg!) =) |
|
|
@Sam I made you a multi-screen picture which is actually a fake multi-camera edit with mixers. I didn't have any usable images of my own that didn't create any copyright issues or visible participants once displayed on the site... So I used "Big Buck Bunny". If you use it you will have to identify the source (https://peach.blender.org/about/). I hope this is correct. Multi-screen.png (4,474,096 bytes) |
|
|
@Pierre Yeah, that would be nice. Thanks a lot. |
|
|
@Sam Instead, I'll prepare another picture for you with the same layout, but where you won't be able to recognize faces. It was an event in front of an audience, but... publishing this image on a site without the permission of the people (especially the seated spectators) visible... I hesitate. |
|
|
@Pierre may I use this picture on the website? I want to add the multi-monitor to the feature list and this image is great for that. |
|
|
@IgorBeg Of course when I'm doing ColorCorrection&ColorGrading, it's very useful to be able to follow the content of the drag with the Videoscope in real time, even if it slows down the number of frames per second. But, as I have a lot of screen space, I like to leave the Composer's Videoscope visible (in "Refresh on stop drag" mode) to be able to take an occasional look at the state of the Image even while editing. The problem is that it slows down the image scrolling a lot when I quickly drag the pointer (especially in multi-screen with mixers). My current workstation is of a rather average power; old i7, 32 GB ram and nvidia GTX-750ti card. Sam's solution would be the right one; an additional "Refresh on stop drag" option. @PhyllisSmith I understand I believe the problem; every time frames are discarded, it's like a stop. Okay, well, if it's not possible, it's not possible. |
|
|
@ Pierre Your idea sounds good BUT a key feature used in CinGG is collapsing of the mouse motions. In my non-technical terms his means that as you drag along with multiple mouse motions, it eliminates a lot of them as you keep moving since it makes no sense to move 1 pixel along if the mouse is headed for 10 pixels down the line. So GG says the code already works as well as it possibly can. It is always a goal to save time but collapsing the mouse motions is the best that can be implemented. |
|
|
@Pierre Can you tell me which is your workflow, please? I think that when you are editing (insert clip, trim, ripple, rolling, and so on) you are not using Videoscope. When you are doing ColorCorrection&ColorGrading you have to see the Videoscope tool with Histogram, Waveform, Vectorscope (or one of them). Videoscope should work in realtime; with Cinelerra-GG and my computers this is not possible. With Videoscope displayed you can see your color grading effects dragging the pointer, forward and backward, in the Timeline and watching the behaviour of your work in the Videoscope which is "constantly" (slowly) updated. I don't think that refreshing on releasing the LMB would help, because you would not be able to see the changes; You would see the changes on Videoscope only on Stop, as when you are Playback. I think, it would not be useful. (I think my reasoning is logical, but I don't know your workflow) @Sam I know you use Resolve. Could you tell me how Resolve works in this situation, please? (I never used it) Thanks! |
|
|
@IgorBeg Since you need the existing mouse functionality, it doesn't make sense to link it directly to the "Refresh on Stop" option. In the dropdown menu we could add another option like "Refresh on stop drag" No idea which term would make the most sense here. But this way Pierre can activate his desired feature and you can leave it deactivated, as long as GG can technically implement the desired feature of Pierre. |
|
|
@Pierre @Sam @All Quote: "Would it be possible for the Videoscope to wait for me to release the cursor in the stop position before reading it?" No, for me it is wrong, sorry. When I do ColorCorrection&ColorGrading I don't use Playback due to cpu consumes, but I drag the pointer in the timeline and look at the Videoscope tool to see the zone where to do ColorCorrection&ColorGrading (and now I will use "Refresh on Stop" option, of course). If developers decide your suggestion I will have to use FrameForward and FrameReverse, or enable and then disable everytime "Refresh on Stop". No good. I don't know which workflow you use to do ColorCorrection&ColorGrading with Cinelerra-GG, and maybe you have a powerful machine. More. When I click and drag on one of the graphs to move the pointer in a precise coordinate an yellow hint with the values is shown. When I release the LMB (Left Mouse Button) that hint is hide,... and I must to write the values on a piece of paper. In the old versions a texts with the values was shown in the top-left and staya stay in place and remained there. Is it possible to restore something like this? Thanks. PS: Thanks, for the "Refresh on Stop" and "VectorWheel Grid" text, more descriptive. |
|
|
@Pierre Quote: "Would it be possible for the Videoscope to wait for me to release the cursor in the stop position before reading it?" For the "Refresh on Stop" mode, a very good idea. +1 |
|
|
"Refresh on Stop" works very well and allows to leave the Videoscope (of the viewer or composer) visible, without decreasing the frame rate. However, if I drag directly the viewer or composer's cursor, to quickly advance the scrolling in one direction or the other, the Videoscope tries to display as it goes along... which greatly reduces the ability to display the images. Would it be possible for the Videoscope to wait for me to release the cursor in the stop position before reading it? |
|
|
OK, final answer. Changed to "Refresh on Stop" and change "Graticules" to "VectorWheel Grids". @Andrea_Paz So Andrea, I think it is safe to update the manual. |
 |
ChromaticWheel is what I would call it, because VectorWheel is redundant, since we are already in a vectorscope. Adobe calls this as ColorWheel, https://www.premiumbeat.com/blog/vectorscope-premiere-pro/ And that's how I've always found it, like Color Wheel or Chromatic Wheel. https://www.managementboek.nl/code/inkijkexemplaar/9780321929662/color-correction-handbook-engels-alexis-van-hurkman.pdf |
|
|
"Refresh on Stop" I like that. It makes more sense. Instead of naming this part of the submenu "Graticule", you could also use "VectorWheel grids". Then it is easier to establish a logical connection to the VectorWheel. If it would be technically feasible to hide this area or make it gray, i.e. not selectable when the vector wheel is not activated, would of course be a nicer way. |
|
|
@IgorBeg Thank you for the suggestion of "Refresh on Stop" so gg does not have to change the logic and I can make that mod myself real quick. I thought about the Graticule section in the Settings just like you did, but I instantly came to the conclusion that it was a good place to put it because it really is a "Setting" and once someone sets it, they probably will never change it. I do not think that if, for example, I set it to IQ because I am always very particular about skin tones, I am never going to go back and set it to Hue instead. About "Maybe, it would be useful (if technically possible) to hide those options (Graticule section in Settings menu) when VectorWheel option is not selected." -- I will bring this up to GG and see how easily that would be done. @RafaMar Your opinion is always welcome as is everyone's. Actually the more opinions we get, the easier it is to make a decision! but of course that leads to not everyone getting what they want. |
|
|
Sorry for meddling, I'm following the matter from the stands. I agree with @IgorBeg, the icons save space and internationalize an application. It is not always possible to use them, but whenever it is possible and logical, it is good to make use of them. And the wonderful thing about the icons is that when you rest your mouse on them they can raise a banner with the name of the tool or function, and even a help. Adobe and Autodesk use these banners a lot to show help and hotkeys, this makes learning an app a lot easier and attracts new users. |
|
|
The name for "Realtime" or "Refresh only". My suggestion to no change the logic of the program: - Refresh on Stop - Update on Stop The "Graticule" section in Settings menu works only for Scope's VectorWheel option. So, I think that in two months a new user come here and will say "it doesn't work" because he have not selected the VectorWheel option. Maybe, it would be useful (if technically possible) to hide those options (Graticule section in Settings menu) when VectorWheel option is not selected. I think that Settings in main window can not be compared with a tool window. Settings menu should only be one. I have never seen two Settings menu in other programs. It confuses the user, like using the same icon for different purposes. About to not use icons in this case, no problem. But icons are fundamental. An icon, if well designed, is international, requires no translation and saves space. For example, take a look at https://www.cinelerra-gg.org/bugtracker/view.php?id=411 for the texts "Size" and "Line Pitch". |
 |
I also do not like icons. Every program has it's own set (apart from the stnadrad ones), and I never can remember which icon means what. In CinGG I always set the audo- and video effect display in the resources window to text only, more of them fit and much easier. |
|
|
@Sam @IgorBeg GG does NOT want to change the logic of the program as that is a lot of extra work. So we have to agree on a replacement for "Refresh only" that saves the logic. Does "Refresh on Play" preserve the implemented logic? I can not tell. It seems to be that it should be "Refresh when Stop" or "Refresh Update". But if "Refresh on Play" is meaningful for the current logic, we will gladly switch to that. I have a hard time with icons. For example, look at GIMP. I end up having to mouse over every single one of the icons to find the one I want and by the time I am done, I have to go back and do it again because I can not see the tips all at the same time to figure out which one to use. Words are exact and there is no guessing involved. |
|
|
@IgorBeg First of all, I understand your reasoning. Nevertheless, I have some arguments that give a different perspective on these points. The bundling of different settings under one menu is often used. As an example I would like to bring in the Settings menu of the main window. In the picture below you can see that several completely different aspects are combined under one menu and that they even affect completely different windows. The vectorsope is part of this window, even if settings only affect the vectorscope, it is part of the overall functionality of this window, so I don't see it as wrong to combine the settings under one Settings menu of this window. A separate overlay menu as we had before was also good, as long as the space for three drop down menus allows it. If the space doesn't allow it and thus destroys the aesthetics of this window, the compromise with a settings menu is in my humble opinion acceptable. Nevertheless, I don't have anything against these three menu variants, as you can also see in my photo montage. For me both variants are acceptable. With the icons I see it completely different, the reasons are as follows. - Icons should only be used if they are really needed often. Otherwise they are unnecessary elements of a user interface. The visual representation of a window should help to focus on the essential. Not so often used settings are combined under one Settings menu to allow focus on the essential. These two icons do not add any value to this window to focus on the essential, so in my humble opinion they are superfluous. Let's be honest, each of us will set these two settings once, as we need them for ourselves, after that we will never or very rarely use these icons again. So why add these icons to the user interface? Most people will probably activate Smooth and maybe even the Realtime "Refresh on Play" function. None of us will be turning these options on and off all the time. If they were very often used icons, I would support your argument. - Your argument with the translations is correct, but menus are good for bundling not so often used settings, so this menu is an acceptable compromise. - I don't think your icons are suitable for every theme. The icons would need to be adapted. These arguments only reflect my humble opinion and should only be a little food for thought. I like your idea with "Refresh on Play".
Main_window_056.jpg (64,477 bytes) |
|
|
Yes, I agree with you, @PhyllisSmith and GG, about "Realtime word: to computer people it seems strange to me and GG". I liked the word "Realtime" because it is a single word. Unfortunately it doesn't reflect the beahaviour of its function. Another name is needed, I think. Sorry. I think that the new Settings pulldown menu is wrong, sorry. I repeat myself, the None, All, Hue, IQ options regard ONLY the Vectorscope. So it was right as before. You could insert Smooth and RealtimeOrRefresh in Scopes pulldown menu, if you want. That would make more sense, I think. Overlay pulldown menu was right, and intuitive! It was only for Vectorscope. My suggestions about another word instead of Realtime (the function must be negate or not, according to the word): - Refresh on Play - One Touch - One Time - Runtime About the icons: The icons are good because you can avoid translating to other languages. Other languages need a longer name: see German, Spanish, ...and Italian languages. PS: PhyllisSmith quote: I say "temporarily" because GG may change it when I am not looking!! You are great GG! =) |
|
|
@MatN thanks for the video (#0003318). I had always associated false colors with the shooting phase and not Color Correction. PS: It seems to me too that the operating is the reverse: when "realtime" is active, the vectorscope is actually blocked. You could call it: "no monitoring" or somethin' |
|
|
Or even "Stop & Go" I'm just kidding. ;-) |
|
|
If you don't like the name Realtime, what do you think of the name: Stop & Refresh It reflects the current implementation. After pressing the Stop button the scopes are refreshed. I don't know, maybe somebody can think of a better name for it. |
|
|
@IgorBeg OK about: "I don't like the name "Refresh only". I prefer the one suggested by Sam." Per your preference it is now temporarily "Realtime" (but to computer people it seems strange to me and GG). I say "temporarily" because GG may change it when I am not looking!! |
|
|
@PhyllisSmith & GG Many thanks for the quick adoption of the suggestions. I think it looks so much better and cleaner! I like the naming of this section of the menu. I noticed a small mistake. Realtime should be for the constant real-time update of the videoscopes. Currently when I activate this option, the exact opposite happens, it is always updated only when the playback is stopped. This option should be negated, i.e. if Realtime is activated, then the Videoscopes should be refreshed constantly. If Realtime is not activated, then the videoscopes should only be refreshed when playback stops, then it is also correct from the concept and logic. Like I said before, really great work. It's really fun to work with. Thanks :-) |
|
|
I have to agree with @IgorBeg that the term "refresh only" is not immediately self-explanatory. Maybe we can call this feature "Realtime refresh" or "Refresh realtime". So you @PhyllisSmith and GG certainly have a better feeling for the English language and term finding than I non-native speakers. Only the term "Refresh only" is not quite appropriate for me. |
|
|
GG started working on this in the morning and so was already aiming at Scopes_051.jpg for its clean look and the possibility of expansion. If I ask him to change it again, he will kill me. But I have saved IgorBeg's buttons in case they become an alternative. I forgot to mention earlier that the "refresh only"/"realtime" ONLY works in the Viewer and Compositor and not as a plugin or with the recording menu. |
|
|
What bothers me about the current overlay menu is that it does not have the same height as the Scope menu. The overlay menu is a few millimeters lower and therefore not flush and therefore looks a bit unsightly. If it had the same height, then I wouldn't mind if it stayed as it is. I'm not a fan of always adding new icons, because they bring back a bit of restlessness into the layout, but it's just my subjective feeling. Furthermore, the icons don't fit in different themes and would have to be modified, which again causes additional work. My suggestion with the Settings menu would be just as space-saving and modular. This setting menu is easier to expand in the future and you don't have to create new icons again. Maybe it could be arranged as shown in my picture.
Scopes_055.jpg (118,807 bytes)
Scopes_054.jpg (117,601 bytes) |
|
|
About the scope I can only say, EXCELLENT WORK. Although it is true that I have not yet worked with him. |
|
|
Like @Sam and @Andrea_Paz said, the new "Refresh only" function is great! I don't like the name "Refresh only". I prefer the one suggested by Sam. I saw the Sam's picture (Scopes_051.jpg and Scopes_052.jpg). I think that the options in the Overlay menu should not coexist with the Smooth and Refresh options: the Overlay options are only for the Vectorscope. Maybe that Smooth and Refresh could be inserted in the Scope menu, more coherent but I don't like it. An alternative could be to add two new buttons to save space. I added a picture and its two icons, if you want. The icon size is 24x24 px because I took them from the old ones.
Scopes_Smooth-Realtime_btns.png (43,569 bytes)
scope_smooth.png (658 bytes)
scope_playing.png (374 bytes) |
|
|
I forgot to add that I used it with the f_lut3d effect, and gave as file name the downloaded .cube file from that URL, link in the text. |
|
|
On a side note, this URL https://www.youtube.com/watch?v=X5jpEsvu3oA shows the use of a LUT table to convert luminance to false color. This has the advantage that you can see the effects of e.g. the colorwheel on each part of the picture , rather than seeing in the scope if it gets too high or low, and then you find in the picture where is is. |
|
|
Here for comparison the current layout. I think that my suggestion from the previous post is much tidier and visually more appealing.
Scopes_053.jpg (99,573 bytes) |
|
|
Thank you very much for this great news. It turned out really well. What I also noticed is that regardless of the videoscope, the performance of the timeline has improved. Also in the resources window the loading of media has become much faster! Absolutely great programming work from GG. Back to the videoscope window. I have a small request. The videoscope window has become really good, but unfortunately the design is not so good. It doesn't correspond to our efforts to make Cinelerra more visually appealing. I would remove the buttons Smooth, Refresh only and Overlay. Instead of using three buttons that are not optimally placed, I would use a single drop-down menu called Settings. It has the advantage that three buttons are removed and displayed in one place. This Seetings menu can be extended more easily in the future and is more modular. It also looks more tidy and visually more modern than the current version. The current layout looks very arbitrary and does not do justice to the great features.
Scopes_051.jpg (117,712 bytes)
Scopes_052.jpg (116,955 bytes) |
|
|
Videoscope has become a really nice tool, thank you. Phyllis, let me know when it's considered in the final version, so I'll update images and text in the manual. |
|
|
"Refresh only" button has been added (Realtime). This was the only place where it fit for screen resizing. And I have to wait to line up Overlay button with Scopes until gg finishes. |
|
|
Mmmy Gooood! "All" instead of "Sandy" or "Goniametron". A bit of fantasy, please?! I would understand the name "Hall" instead "All". Also "HS". HS stands for [H]ue[S]at. Okay, You are the Captain Kirk. Thanks. |
|
|
@IgorBeg @Andrea_Paz Checked into GIT, the final graticules for the VectorWheel, named All (the abbreviation acronym for Goniametron), Hue, and IQ. I have to align the Overlay and Scopes buttons yet. And I have to discuss Realtime with GG again as I did not get a good feeling the first time. |
|
|
What do you think about rename Sandy to Goniametron? |
|
|
Ahahahahah. You are funny @PhyllisSmith! :) Cobayashi Maru is the test that Captain James T. Kirk have to do in Star Trek movie. (T stands for Tiberius) :-) |
|
|
@IgorBeg Seriously? R2D2? - give me some suggestions, please. (And now I have to look up CobayashiMaru because I have no idea what that even represents). |
|
|
Good idea @Sam the Realtime button and its function. I like it. Thanks for the feedback @Andrea_Paz. @PhyllisSmith I don't like the name Complete for Sandy, sorry. Can you assign another name like R2D2 or C3PO (by StarWars)? Or CobayashiMaru? ;-) PS: Remember to align Overlay button with Scope button, please. Point n.3 of https://www.cinelerra-gg.org/bugtracker/view.php?id=71#c3194 |
|
|
@Andrea_Paz Thank you. I was just trying to figure out which ones were the latest, so now I got it. There will be Sandy.png (Complete is its name), Hue-new.png (Hue is its name) and grid-02.png (IQ is its name). These names help to define what is in the graticule. @Sam I will have to check with GG to see if Realtime is a feasible addition. It is a very good idea to resolve the issue. |
|
|
@IgorBeg No, please don't take the radius off at 22°; it's the best guide for the skintones and I brought the other graticule to match yours. @Phyllis I enclose pictures of Hue-new.png and grid-02.png (aka IQ-Hue-dots.png). I hope they are the final ones. grid-final.tar.gz (275,344 bytes) |
|
|
Really, @Olaf? I thought we were done with these kind of posts? Anyway, you have a good time too. @PhyllisSmith @IgorBeg @Andrea_Paz @Olaf The videoscopes are used for color correction. The color correction is not done with moving footage, but you always stop at certain points and then you do the color correction. I don't know if it can be done in any other way, but that would be new to me. But I would have the suggestion to add an option that the videoscopes don't record new data when playing the video and only when the video stops, the new data of the new position is read in again. This would have the advantage that the frame rate does not go down and you have a smooth playback. If you prefer a permanent update for the videoscopes, you can enable this option "Realtime".
Cinelerra_Scopes_030.jpg (69,750 bytes) |
|
|
@Andrea_Paz Thank you so much for all your tests and your time. About "ColorizedGreyscale... gives me different results." my mistake. My settings for that was on BT601. I think that the R, G, B, Yellow, Cyan, Magenta are right in Sandy and Hue-new. For the Skin Tone I could delete the line at 22° and we can leave the lines at 6° and 38°. I don't know, sorry. @PhyllisSmith Okay. I was hoping for a good samaritan. ;-) |
|
|
@IgorBeg I think the colorwheel used in Cinelerra is standard to Cinelerra past and present and will not be changing. Sandy looks very good and should be reasonable for just about everyone. Since any user can create their own graticule, they can adopt to their own requirements. With my total lack of knowledge and the fact that colorization is a whole expert field all by itself, with the options of none, Hue, IQ, and Sandy (to be renamed) and any user generated alternative, it is about as far as we can go for Cinelerra. (P.S. I believe the off-topic bug from above was due to frustration and because I was not at the computer and missed the email). |
|
|
@Olaf "When the videoscope is turned on, the frame rate drops to 7 fps." - Performance is decreased when "smooth" is enabled because smoothing with software costs performance. - With Vectorscope enabled, what had been done with pixmaps so could use the graphics board, is now being done via software in order to improve the looks. So again costs performance. - With the new ease of enabling/disabling the videoscope from the compositor, I would have to suggest that you turn it off when playing. However, on a silly note, the slowness gives your brain more time to see if the color meets with your expectations! |
|
|
@ IgorBeg Uhm, with the masked image I get your result. I was only based on the other image because It was less confused. So our measurements are congruent, that gives me relief. There remains the problem of other offset colors. I'm convincing myself it's due to unsuitable test charts. For example, pal75-100% gives me results like yours. Whereas ColorizedGreyscale... gives me different results. Enough, I'm adapting my graticule to Sandy. I can't go any further.
PDITarget-my-test.png (125,391 bytes)
colorized-R000.png (126,573 bytes) |
 |
@Sam, one question, if you know it's not a commercial project, why are you communicating like a spokesperson for a commercial project? You don't have to sell me anything, I've been watching Cinelerra since it was an audio editor. Maybe it's not the speed of development, as you think, but the fact that it's not the filmmakers or editors and their projects that are in the foreground? Okay, I'm off again, wish you a good time. |
|
|
I am not the Administrator of the MantisBT but... This is "Improve Videoscope plugin" ticket! @RafaMar I didn't undestand because you (RafaMar) written here for a bug. Did you found a urgent bug? You can open a specific ticket on that and writing (as you have done) in mailing list. @Olaf @Sam Here we are for improve the Videoscope, if possible. Thanks. |
|
|
@Olaf I agree on certain points that they can be done better. Constructive criticism is certainly beneficial to the project and suggestions and tips are good to implement. We can do many things better and are working on making it better. We are in the process of setting up a donation page. If so many such donations come in at all, then we can of course use them for programmers and call for certain tasks. It is not a commercial project, but a voluntary community of developers, supporters, artists and users and for this reason this project may be developing too slowly for some users. I'm not satisfied with G***gle either, I share this point of view with you. It is only a compromise solution, we are just tracking to find bugs on the website and also to better estimate the download traffic. But the goal is to free ourselves from monopolists in the medium term and to rely entirely on open standards. There are some solutions, but it takes time to implement all this. |
|
|
I have just updated CGG to the latest version. When the videoscope is turned on, the frame rate drops to 7 fps. Worse than before. |
|
|
@Sam, it's not that simple and you know it. It's the sum of the inconveniences, not only the individual bug. Sure, you can still try to keep the users engaged, but I have occasionally wondered why obvious bugs are not detected and fixed. And then there are the bugs that have already been reported but not yet fixed. Where is the emergency fix, are these people less valuable to the project? (Ein Großteil der Implementierungen ist doch mit der heißen Nadel gestrickt, wenn es halbwegs funktioniert läuft der Entwickler weg und spielt lieber an was anderem weiter.) In the end, the user doesn't even know anymore if it's a bug or if that's what is wanted. He sees what he gets and turns to another program, which is now less time consuming than writing a bug report. Besides, one saves oneself the enforced tracking by third parties like G**gle. You might want to reconsider accepting the donations offered in the forum and offer them as a bounty for solving certain tasks. |
|
|
For me this work on vectorscope/waveform is a first step towards improving color management in Cinelerra. And I have a hunch that reliable results on grids (vectorscope/waveform) will also require a complete and accurate management of LUTs and different color spaces. Are there different color bar tests calibrated for the different color spaces that Cinelerra projects choose and configure? |
|
|
Thanks @Andrea_Paz for the link. With your "skin-test.jpg" I see Hue around 32°. I added a screenshot. Could you make a test with my project test, please? Leave the mask enabled: "Play track" in Video_2= enabled. Insert the xml (project file) in the same folder where you putted "PDITarget.jpg" In the TAR.GZ file you find the xml. There I see Hue around 22°. My setup: - Settings->Appearance-> YUV color space: BT709; YUV color range: jpeg - Settings-> Playback_A-> Video_Out-> Video_Driver: X11 (use direct x11 render if possible= checked) - Format-> Video-> Color model: RGBA-8bit
Vectorscope_AndreaSkinTest.png (99,398 bytes)
Vectorscope_IgorSkinTest.png (101,050 bytes)
Cin_Vectorscope_TestSkinWithTarget.xml.tar.gz (3,083 bytes) |
|
|
Thanks @MatN. I am not an expert on that, unfortunately. Every Color Spaces change what you see in the Color Wheel. The saturation coordinates may be different, for example. But I don't have a master instrument to say this or that and test it. Andrea_Paz and me, have created grids consistent with the color representation that Cin sees. By my test, the grid is consistent, now. But it is out of standard. I think that it is useful for color grading but I would like to know all your opinions, hoping that among all of you an expert user on that come out and tell us: "okay guys, out standard but you can work with it, perfectly". |
|
|
@Olaf Sam "I believe @RafaMar that you're the first one who ever noticed this bug." It's happened to me before, a relatively long time ago. But at the time, sayings like this were commonplace: > Everyone has the opportunity to report bugs, and as you can see from Rafas Report, the bug has been fixed. This possibility was open to all other people who found the bug. We even offer three ways to make it as easy as possible for comfortable people, we have the forum, the mailing list and even the bug tracker. "But unfortunately with such a complex program like Cinelerra such a bug can creep in." And this is still the harmless variant. Usually users blame themselves - "because it is such a complex program" - and prefer to keep it quiet. > Yes, I'm sure some people have that mentality. Maybe they blame themselves, but there are also people for whom an product must work properly, and when it doesn't, they complain about it and report the bug. Rafa is the proof of that. By the way, Premiere Pro and DaVinci Resolve are much more complex video editing software than Cinelerra and I experience problems with them every day. Premiere Pro and Resolve, which I use because of my customers, have crashed more often than Cinelerra. Even non-free and paid software is not free of bugs. Bugs can only be fixed if they are reported. |
|
|
@IgorBeg I found the skin-test here: https://kenrockwell.com/hdtv/shopping.htm I don't think it's official, although it gives me confidence. Do you confirm that you see the line at 22° (while I see it "moved", as in the picture I posted)? I tried the images you indicated and the result is the same: what is indicated to you at 22° to me is shown moved to the left. The same goes for the coloryzed test you used for the six zones: to me the colors are shifted with respect to your measurements. In short, in my system I see moved what you see right. I would be curious to know if others confirm your results because it would mean that there is something wrong with my system. (monitor? Graphic Card? Other?). |
|
|
> @Sam "I believe @RafaMar that you're the first one who ever noticed this bug." It's happened to me before, a relatively long time ago. But at the time, sayings like this were commonplace: > "But unfortunately with such a complex program like Cinelerra such a bug can creep in." And this is still the harmless variant. Usually users blame themselves - "because it is such a complex program" - and prefer to keep it quiet. |
|
|
@IgorBeg, Sorry, I am not familiar enough with color issues to say that one wheel is better than the other. I do wonder if different colorspaces affect the scope. In Settings, Preferences, Appareance you can select YUV color spaces. Is this still relevant when the format is set to RGB? Do the different color spaces BT601, BT709, BT2020 have an effect on how the vectorscope/colorwheel is used? For instance, is maximum saturation on BT601 the same as on BT2020? Is the vectorscope still relevant for non-PAL/NTSC output? |
|
|
@Sam and @Pierre, Thanks for the compliments (it is only a grid). @Pierre "Why this difference compared to standard vectorscope grids? Could it be to compensate for a non-conformity of the color processing under Cinelerra?" The Color Wheel of Cin not use the same sheme of the other NLEs, then the grid must to be different, unfortunately (by my test). About your ReadWaveformVector.pdf, I read a similar PDF before drawing my grid and after some good considerations with @Andrea_Paz and its grids. Thanks. |
|
|
@IgorBeg I am not familiar with the precise use of the Vectorscope, but I notice that your grid does not conform to the grids I usually see elsewhere. On your grid the color reference targets are uniformly and symmetrically distributed on the 75% circle, secondly the whole grid seems to be displaced about 8° clockwise. Why this difference compared to standard vectorscope grids? Could it be to compensate for a non-conformity of the color processing under Cinelerra? I don't know enough about the whole issue of color management and the research I did led me to a lot of text that deals with the NTSC era and explains the use of the standard grid, but do these old usage rules also apply in HD or UHD? Your grid is beautiful, but I am unable to know if it is in accordance with what we should expect from vectorscope. See: http://blog.ieba.com/wp-content/uploads/2010/06/ReadWaveformVector.pdf |
|
|
@PhyllisSmith Now it's working fine again, I'll confirm it. I believe @RafaMar that you're the first one who ever noticed this bug. I have been working with Cinelerra for years now, also productively, and I have never noticed this error before. If others were affected, it would have been reported a long time before and we usually fix such bugs within a few hours or a day at most. @Pierre I agree with your assessment. Delivering the option "Replace current project" as default setting is not the best choice in my opinion either. I have been annoyed about it so often. I would suggest we open a new ticket, better it would be if "Create new resource only" is default. |
|
|
Just one comment... I won't dwell on it because we're supposed to be discussing Videoscopes... I never use the "Replace current project" option and I don't understand why it exists, let alone why it appears by default after a new installation... I always create new resources, even when I open an existing project. Feeding the timeline from the resource window seems to me the most normal procedure. I also think that this "Replace current project" option is dangerous, especially if it is offered by default. |
|
|
@RafaMar @Sam Well, inquiring minds just had to know where the 2 lines came from that caused this devastating error. The lines were added to Cinelerra-GG in March 2016 and came from Cinelerra-CV. We did not track down the history of why it was included in CV. However, we did look to see if those lines were in HV and they were not. Cinelerra-GG originated from HV and the CV mods were merged in in March 2016. Although we feel bad that this extremely devastating error has existed for so long, we can take some comfort in the fact that no one has reported it for all these years. And now back to Videoscopes! |
|
|
@RafaMar @Sam Thanks to both of you for reporting and expressing our consternation. An EMERGENCY fix has been checked into GIT. GG is creating a test static build for Mint 19.3 right now. Unfortunately, this bug has been around and UNDECTECTED at least as far back as February 2018. That is as far as I went back to see. I am pretty sure if anyone had experienced this error during all of that time, because it is so devastating, they would have immediately notified us so hopefully no one else lost work. In the outlined scenario as RafaMar stated, the problem occurs as soon as you press z as you can see in the attached where on the window manager top line of the timeline you will see "Cinelerra test2.mov" -- ordinarily this is either just Cinelerra or is the name of the "Save as" xml file but should not be the name of the media (test2.mov). I myself, would have never thought to check that line, but GG immediately looked at it when debugging the problem. Only when the "s" was done, did this become a huge problem. https://www.cinelerra-gg.org/download/testing/cinelerra-5.1-mint19-x86_64-static.txz
emergency.png (23,340 bytes) |
|
|
@PhyllisSmith is very easy to reproduce. 1. Open a project of your choice, load a video or audio clip with the option "Replace current project" (please backup this file, otherwise you will lose it forever) 2. press z once to go back (if you press twice it is not valid, only once) 3. Now press s, your clip has been corrupted forever, now it is an xml with the wrong extension. It seems very serious to me. Overwrite, this is normal. It even jumps a warning, which is the right thing to do. Sorry, but I am scared, by my readers, with this situation ... it happened to me after a crash, after recovering the backup ... when I pressed s and the wizard did not open ... I looked at the window bar and I've been frozen. This is the second time something like this has happened to me. As clueless as I am, it is not convenient for me to use Cinelerra if this is not fixed. Thanks for the interest. |
|
|
@RafaMar Thank you for reporting this error. I can confirm the bug. Your annoyance is understandable, nobody wants something like this and of course the developers don't like it either. The developers are always trying to avoid such things. But unfortunately with such a complex program like Cinelerra such a bug can creep in. Sorry for the inconvenience. |
|
|
@RafaMar Sorry to hear about the problem -- the goal is to never lose your video -- otherwise it is not usable. I agree with you 100%. Cinelerra does not operate directly on the video media for this very reason. The xml file consists of the edits to that media file and only contains reference to the original media. There is one way to destroy the original media and that is to render over the media using the same file name and it asks "are you sure?" I have not had a chance to look at your demo file but if there is a bug that causes loss of data, we will get it fixed ASAP. |
|
|
Today Cinelerra has converted a video into an xml, fortunately, the video that has been lost forever, was not important ... it is the second time this has happened to me in Cinelerra ... I cannot risk that I can go through an important video. This is a Russian roulette. I take a break from Cinelerra until this is fixed. I can't recommend an editor who does these things, if some reader of mine had this happen and lost an important video for him, forever, I would feel very bad. I'm very sorry @IgorBerg, today I was frozen, I felt panic. For a programmer this may even be funny. But I love videos and I don't want to lose them like this. https://streamable.com/cco2ph |
|
|
Thanks @Andrea_Paz and @PhyllisSmith ! Andrea, about your "skin-test.jpg" I don't know. Can you tell me where did you find it, please? (I guess on a site). It is a specific target for skin? I tested the "skin line" (at 22°, and the area from 6° and 38°) with different test charts and they confirmed the "Skin Colour Analysis" theory. But I really don't know. For example, I downloaded a test chart in the following site (I am afraid I can not put here the test chart for copyright): https://www.ppgba.com/image-competition/monitor-calibration-test-images/ A test of mine (Vectorscope_Sandy_skinTest1.ogv) on https://streamable.com/tc9qrt @PhyllisSmith I think my Sandy is Okay but I am not an expert for that. I used my brain (and inside there is only one neuron). ;-p If possible, I would like to know others opinions about Vectorscope wheel and the skin line, for example by @Sam, @Olaf, @Pierre, @MatN, @RafaMar. Thanks. |
|
|
That's awesome, Igor! |
|
|
@IgorBeg Excellent - is it OK to check it in now? |
|
|
Beautiful grid, my compliments. About the I-Line, I used the attached skin-test and the result is shown in the screenshot. Probably the test used is not suitable.
skin-test.jpg (108,937 bytes)
test-skin.jpg (44,584 bytes) |
|
|
I added my final (I hope) PNG for (no standard) vectorscope. After a few of research (reading) I have changed the skin zone in the PNG. Skin zone goes from 6 degree to 38 degree. Center at 22 degree. Red color at 0 degree (North). You can see the sector area on North-West of the ColorWheel. The degree information from "Skin Colour Analysis" http://homepages.inf.ed.ac.uk/rbf/CVonline/LOCAL_COPIES/GONG1/cvOnline-skinColourAnalysis.html You can find different source about the skin but I have tested it with some reference image for skin. It seems to me good. Tell me if it (font, character, lines, colours, ...) is good for you. Try it with your test, please. Any feedback is welcome. PS: I called the PNG, Sandy but you can change it as it is better for Cin. =) Cin version: Thu, 16 Apr 2020 00:12:20 +0200 (16:12 -0600)
Sandy.png (180,104 bytes) |
|
|
@Andrea_Paz got it, it is perfect. So this will be Hue. @IgorBeg vscope-cin1.png Why is it "only for testing, right now". It is very nice. Well anyway, let us know when it is ready for production. |
|
|
That's it! grid-letter.tar.gz (46,019 bytes) |
|
|
@Andrea_Paz I prefer color letters on your newly designed Hue.png . This color stuff is confusing to me and GG is not an expert on it either so it would be better to get someone else who knows more about it to respond. But I think that you (Andrea) understands it better than most. |
|
|
I redesigned the Hue.png grid to fit the nice IgorBeg grid (no standard). Tell me if you prefer color letters or if it's okay without letters. I tried to make the grid based on various HD-BT709 tests. But the result is always variable, both in saturation and also, slightly, in hue. I think it depends on the monitor and how it is calibrated; the color space it uses and the type of color test, and maybe even the setting of "YUV Color Space" and "YUV Color Range" in CinGG. Can you ask GG (or anyone who knows anything about it) if he knows anything about this and can you give me some directions? It would be nice to have grids for HD-Rec709 and maybe UHD-Rec2020 as well, as they are increasingly used nowadays. Hue-new.tar.gz (155,840 bytes) |
|
|
I added a new grid (no standard). It is calibrated with the F_Pal75bars (and F_Pal100bar, of course) on Cin Color Wheel. Only for testing, right now. You can see screencasts about: - File: 01_Vectorscope_Pal75bars_calibration.ogv https://streamable.com/scm4vg - 02_Vectorscope_ColorizedGrayscale_test.ogv https://streamable.com/45uimb Circle at saturation 75% for broadcasting and DVD_Video for that I know. I hope that other users and Developers can help on that. Thanks. Special thanks to Andrea_paz to post a long discussion.
vscope-cin1.png (114,411 bytes) |
|
|
From a discussion with IgorBeg, interesting things came out to deepen the knowledge of vectorscope and how to build a new reticule: *Referring to Premiere's vectorscope and remembering that we are talking about Saturation (radius in vectorscope).* Premiere's vectorscope has two hypothetical circles that pass through for those boxes (with the cross inside). [see figure] So let's say that you have the inner circle, which covers the inner squares, and the outer circle covering the outer frames. You'll notice it's the inner circle that the outer circle does not cover the boxes exactly because they use a representation of their own (I guess it depends on the perception of the human eye, the blue and yellow are less sensitive than the green, for example). However, consider a curve that touches them. 1) Press the dropdown menu with scale on 100%: - the inner panels indicate 75% color saturation, while the outer ones 100% color saturation. This serves even to see if a signal exceeds 100% going towards 110%. 2) Press the dropdown menu with scale on 75%: - don't use the inside boxes, forget about them. - The outer frames now represent 75% of the color saturation, while the visible outer circle represents 100% of saturation of color. It's kind of like a saturation zoom, nothing else. *Let's talk about Cinelerra.GG's Vectorscope:* Non owns this different scale so the programmer did a sly one. He considers the outer ring 110%. It's like Premiere is Compared to Premiere of point 1 (DropDown menu scale=100%). In addition, the representation of the color wheel actually looks like copy a perfect circle. I guess it doesn't take into account perception of the human eye that is not linear. So the color wheel of cinelerra, to me, is Linear. My considerations: In order to build a grid suitable for CinGG, we have to make it custom, and therefore not std. The ones made so far are std, so they are not good (and also the color wheel is slightly rotated compared to the ones used, but this is not important).
premiere.jpg (94,103 bytes) |
|
|
I don't understand what could be the cause of the "displacement". Using the IgorBeg test you can see that Rosso and Cyan are shifted about 3-4°; Yellow and Blue about 18° and Green and Magenta about 26°. A possible solution could be not to use standard grids, but to build a custom grid based on measurements made inside CinGG, with various color tests. The colour wheel would remain the same, because it is congruent with the measurements made by the Vectorscope. The six zones and the lines I and Q would change according to the measurements and would no longer coincide with the std. I can't say if that would work, because I don't know the cause of the shift. |
|
|
1. About Andrea's grid I meant that it is a standard grid (#0003182). Unfortunately, like MatN said, it was out of centre. 2. Very good the yellow hint with the values inside the graph. If possible to add a text field on the top of each graph, or where you want (on the bottom?), with the last sample (reading), more or less as it was before; so we can see the values without remember them when the pointer is out of the graph. (If no possible to add a text for each graph, at least a text box with the last reading, would be useful). 3. Aesthetic: New layout very good. Scopes and Overlay buttons are not vertically aligned. Could you see that, please? 4. IMPORTANT! I think that the grids do not "speak" the same language of the color wheel. Other NLEs do not show the color wheel but only the grid; may be that colors on the grid follow a different scheme (modus operandi). I don't know. If you use Cin color wheel without the grid, the information (Hue, Sat) are right. Take a look a ugly animated GIF about Premiere_Vectorscope vs Cin_Vectorscope with the same ColorizedGrayscale video pattern: Vectorscope_Premiere-vs-Cin_2index.gif https://streamable.com/uyl9uy Cin version: Thu, 16 Apr 2020 00:12:20 +0200 (16:12 -0600) |
|
|
@Andrea_Paz Thank you very much for the contributed graticules. It is a nice, complete variety. Checked in the last of the mods with some of the layout changes as recommended by Sam where it would work and for resizing. |
|
|
This version should solve the decentralization. I apologize, I thought I'd already solved it. vector-01.svg (22,323 bytes)
grid-01-HD-2.png (206,416 bytes) |
|
|
I would place the Scope button one line further up. The smooth button looks totally out of place in the current layout. The Smooth Button is not a detached function, but an addition to the different scopes and therefore does not need a separate line. I have attached a picture to it, here you can see at a glance that the Smooth option is an extension of the different scopes. It looks better this way. I would place the overlay button one line lower, it is only an option for the vectorscope and not a superior function for all other videoscopes.
Videoscopes-suggestion.jpg (144,662 bytes) |
|
|
@PhyllisSmith Quote: "Yes, it looks better BUT this means that it is slower so is the performance hit worth the aesthetics? " Aesthetics is Cinelerra's biggest problem. In many comments people complain that Cinelerra just looks ugly, from the user interface to pixeled controls. The other NLEs don't have these problems, because the user interfaces are adapted to today's time and user expectations. The users have these expectations and we will be judged by them. I like to compare it with the iPhone and other smartphones, the iPhone is in some points often less powerful than other competitors, but still a lot of people want an iPhone for aesthetic reasons and because they have learned to appreciate the easy handling. To answer your question, if it is worth sacrificing a little bit of performance in favor of aesthetics, the answer is clearly yes! It looks so much better! Thanks a lot. |
|
|
Checked in changes to GIT. - switched from pixmap to overlay for "smooth, non-pixelated" VectorWheel. Yes, it looks better BUT this means that it is slower so is the performance hit worth the aesthetics? - when you click on a graph, previously the value, hue, saturation numbers were in the top line and not always noticeable but now you get a tooltip when you click the LMB. - a couple of cleanup and 1 bug fix. We are still working on graticules for the overlays and Andrea has submitted 1 improved + another different one + another different one but we have to work out naming and some other stuff yet. And I am confused that IgorBeg says Andrea's is correctly centered but the "grad" is not whereas MatN says the opposite. I guess that that is why we need choices (!). |
|
|
@MatN I do not know if the center is off or not but it seems to match what I see elsewhere. Andrea has sent me a revision that I have to get to gg yet. But the first pixelated picture is not very clear and we need a better one. The overlays are only for the vectorwheel. The innovative use of overlays is so that any user can add any of his favorite overlays by simply adding the right size png file to {cinelerra_path}/bin/plugins/scopes. (Of course, an upgrade will delete it and it will have to be copied over again). This way the user can custom build their own overlay for specific project types or even make use for their own use some grids that can not be included in Cinelerra because of licensing. |
|
|
It seems to me using the test pattern from IgorBeg, that Andrea's grid has its center off, slightly to the right. The first, pixilated picture has the center OK. Another question: Are the overlays only for the vectorwheel or also the vectorscope? If only the wheel, why not use a single drop-down list which contains vectorscope, vectorwheel, vectorwheel with grid, vectorwheel with grad ? Instead of a second "overlay" box? |
|
|
@All A very good job, guys! By my tests, unfortunately, the vectorscope instrument is uncalibrated, for me: the color wheel do not match with video test patterns used as a technical reference. The Andrea_paz grid is right (great work Andrea!). I do not remember where I downloaded the test pattern and if there may be copyrights to share it, I dont’ know. (I hope not, otherwise I am an outlaw) You can download the test pattern from www.visi1.org/temp/ColorizedGrayscale_v-1080p-30fps_a-1tickPerSecond.mov If you put it in the timeline there are 7 important steps in the video, and you can see on top-right corner of the video: R000, Y060, G120, C180, B240, M300, R360. These should match with the Andrea_paz’s grid and, of course, with the color wheel. If someone can confirm or less it would be useful. Thanks! |
|
|
Just checked in latest changes into GIT to include Andrea's latest grid. |
|
|
@Sam The second one does look better. It is a good thing to have lots of "creative flow"! We are having technical difficulties still getting it to fit when the window is at a minimum size so we will have to work on seeing what can be done tomorrow again. |
|
|
Thanks, @PhyllisSmith Sorry, with all the suggestions, today I seem to be in creative flow. Here is one last version of how it would probably look best if it were technically feasible.
Vectorscope-v2.jpg (40,657 bytes) |
|
|
@Andrea_Paz I "think" gg will change the code to "store the chosen grid in order to find it in the next openings." Your HD png is very good. We are going to check it into GIT later. Also, after this checkin, we might be finished with the Videoscope so if you could update the Manual, that would be appreciated. It would need to be referenced in the Compositor and Viewer section too that it is available there but documented in the Plugins chapter. @Sam Will attempt to implement your Vectorscope.jpg suggestion. |
|
|
I have corrected the image, I noticed that it would probably be better this way.
Vectorscope.jpg (40,889 bytes) |
|
|
I have to agree with Andrea, this resolution is too small and much too pixelated. With a resolution of 300 dpi and 1600x1600 it would probably look much better. For the layer I would appreciate it if the smooth effect could be applied there as well to make the raw pixels disappear. You can see every single pixel in the overlapping image, there is no subpixel rendering and antialasing. About the problem with the vectorscope. I have created a picture for this. The problem could be solved by setting the drop down menu "Scopes" one line higher. This allows the vectorscope to be left-aligned. The captions 10 to 110 could also be displayed with the new overlay technique within the vectorscopes. This fixes this very major design flaw. |
|
|
The 512x512 images are too pixelated! Better to use a resolution of 300 dpi which makes the image about 1600x1600. It goes from 50 KB to 200 KB; is this acceptable? One request: is to be able to store the chosen grid in order to find it in the next openings.
grid-01-HD.png (202,767 bytes) |
|
|
Made a modification to put the name "Overlay" on the VectorWheel drop down menu as Sam suggested. Will check in this change later but will wait for a better looking overlay than the one we used originally. However, the reason Vectorscope is not moved over (i.e. right-aligned) when it is alone is because there is information of Hue and Saturation values provided on the line to the right side of the "Scopes" pulldown -- these show up when you click on one of the 3 displays. Also, concerning being able to see Waveform and Waveform Parade simultaneously, it would make the window so long. You can now do this easily enought by using the Compositor Videoscope and at the same time drag the Videoscope plugin to the timeline for the video track and just bring up the one display there. Now you can see them at the same time - at least for that track. |
|
|
@Andrea_Paz WORKS GREAT! 1 - take down the vectorscope in the compositor 2 - copy your grid-01.png to {your cinelerra path}/bin/plugins/scopes/grip-01.png 3 - bring up the videoscope in the compositor and use the funny looking pulldown on the left side of the Vectorscope and you will see grid-01 VOILA! |
|
|
I created my own version of the grid; but I can't test it because just putting it in {path}/scopes doesn't load it. How to do that? I also created a higher resolution png, but it is about 1200x1200 instead of 512x512. I also have the svg, if anyone wants to make it better.
grid-01.png (57,582 bytes) |
|
|
Thanks for the feedback. Andrea, I am sure yours will be an improvement over what we had and we would love to have it -- put in the lines that you personally would like as opposed to everything which you might not want to see. Sam, gg went for a 512x512 png which will almost always be good enough. Decoding SVG files is really hard so is better to be avoided. Will check on the other minor flaws to use a suggested or find another solution. |
|
|
Thanks a lot for a great job. Videoscopes have become really good. Is it possible to include SVG files, except PNG only? This would make the images scalable to any size. I noticed a few minor bugs. See attached picture. 1. I would give the drop down menu a name. Without a name it looks strange. 2. Vectorscope is right-aligned when activated alone. I would center it.
Cinelerra: Scopes_007.png (166,362 bytes)
Cinelerra: Scopes_008.png (180,909 bytes) |
|
|
The videoscopes have become magnificent. Thank you very much. I'm trying to make my own grid for vectorscope, but I hope that someone better and more precise than me will get better results |
|
|
GIT checkin for improvements has been done. The I-line skin tone was added. New innovation -- besides the standard Vectorscope, there is now a VectorWheel choice in the pulldown menu. And when this choice is in effect, there is a down arrow to the left of its slider bar to choose an overlay. Now this overlay is fuzzy and "your assignment, should you choose to accept it" (quote from Mission Impossible!) is to create any overlay you like as a png, keep it to use for yourself by putting it in {cinelerra_path}/plugins/scopes, or provide it for inclusion for GPL usage in Cinelerra for everyone. |
|
|
@IgorBeg, https://www.cinelerra-gg.org/bugtracker/view.php?id=403 |
|
|
Your suggestion Olaf with the slightly different arrangement of the icons makes more sense. +1 |
|
|
One mm should already suffice, @IgorBeg. ;-) In addition, a modified order could be considered at times.
scope.png (16,822 bytes) |
|
|
Thanks @Olaf. For what I can see all that icons are 24x24px also scope.png (I have not found your svg). I think that it is a due to the Y coordinate somewhere to draw the icons on the canvas. Maybe it is need to move the icons 2px down. Only GG and you know where to put the hands. ;-) |
|
|
@IgorBeg, I am talking about scope.svg, which I created in August 2018. It has a document size of 24x24px, but the actual icon inside is smaller. By the way, I can't reproduce the effect (SUV, Unflat, Cakewalk, Neophyte) you showed me ("icons_over_whiteLine_Cin20200331.png"). They just look ugly and scale even worse because, as I said, it wasn't made for that. |
|
|
@Olaf Which icon are you talking about? I see that scope.png is 24x24 like others: InPoint, OutPoint,... (mmh,... but I think you are talking about other icon) |
|
|
@IgorBeg, the icon is 2 pixels too high (20 instead of 18 pixels) It was never intended for Composer/Viewer at any time, but was designed exclusively for the plugin. |
|
|
Only for info about @MatN problem. On my UbuntuStudio_16.04_64_LTS I make a build with: ./configure --with-single-user --without-shuttle-usb --without-vaapi --without-vdpau --disable-dav1d I don't know. May be something of that? |
|
|
@MatN I have an Intel laptop to test yet. We never build debuggable there. The tests as an ordinary user on an AMD laptop with Fedora using a non-debuggable cin had neither failure. None of the Mint 19.3 tests failed for us, but GG is upgrading Mint 19.3 right now and is going to run another battery of tests -- he says there is not much in the upgrade list BUT that Mesa is in that list. However, Rafa gets the png title crash running as an ordinary user and using a build that we generated (either 02/29/2020 or 03/25/2020 - not sure which) so there is for sure this generic problem. And he used both English and Spanish test and so did I. |
|
|
I build a debug version as sudo, and with that debug version neither the title problem not the videoscope problem appears. It does not matter if I run it as sudo or normal user. Nasty. If it cannot be reproduced I think there no option but to do a normal release. Maybe it is something in my environment. Have you tested a non-debug version? |
|
|
@MatN This is a possibility ---- "delay the release until these crashes are fixed? Few people are likely to care about the exact date" IF WE could reproduce either bug. But unfortunately after spending a considerable amount of time yesterday, neither of us could. 1 - The Title png potential bug has probably been there for a long time and was undiscovered until Rafa used it and there is obviously a workaround. We are booting Mint 19.3 to test there too now. 2 - The Videoscope bug is the most concerning but so far it does not appear that Andrea, Andrew, Sam, or IgorBeg have found that error. Will test that right now on Mint 19.3 also. It must certainly be related to the latest changes. The bottom line is that it will not make any difference if we do the builds today or if we wait another 6 months because we simply have been unable to create the problem so will not be able to fix it. I hope I am wrong and it crashes on Mint 19.3 this morning. Unfortunately, the dumps in this case have provided no clues. To produce a "perfect" dump, gdb must be installed, Cinelerra must be compiled debuggable, and the crash has to occur while running as "root". |
|
|
@PhyllisSmith "added reset icons by the slider bar as IgorBeg suggested" Thank you! "changed the line up of the button bars in the compositor to match Igor's image (had to cover the dog's ears again during this argument)" GG, I appreciate your effort. Thank you so much. I am sorry Dog, I am guilty. Aesthetic problem on Viewer and Compositor (sorry). SUV theme (I don't know others): the white line above the buttons is covered by some icons. I added screenshot "icons_over_whiteLine_Cin20200331.png"
icons_over_whiteLine_Cin20200331.png (28,191 bytes) |
 |
I agree with MatN: better some delay than whole month of buggy release. |
|
|
@Phyllis, I know you guys are very busy the last day of the month, but I start to wonder if CinGG should be released with two easily reproduced crashes, BT71 (videoscope) and BT397 (title). CinGG has a good reputation, a version with crashes would not be good. Maybe delay the release until these crashes are fixed? Few people are likely to care about the exact date. |
|
|
1. @Andrea, no, setting hw-device to "none" instead of "vaapi" makes no difference. 2. It happens every time, I load the video (don't play it), attach the videoscope effect, open it, close it, crash. 3. It must be a recent change, I have an earlier debug build from 20200313 code, and that does not have the problem. It of course misses the nice scope in the compositor. |
|
|
@MatN Just out of curiosity: disable vaapi, does it make any difference? |
|
|
The mesa error lines have been there for quite some time, they appear when just loading a movie. I never tested whether there are circumstances where they are missing or different. I was testing on kernel 4.15.0-88-generic, I am pretty sure this crash did not appear some versions earlier. |
|
|
Thanks for feedback and additional information as it is very helpful in which way to go. Unfortunately, we ran out of time so the Andrea vectorscope changes did not even get started and we are still trying to ascertain if there is any way we can speed things up to get better fps as Olaf described. Unable to create MatN crash so be on the lookout for this. The "mesa" error message shown in his note, comes out of mesa and not Cinelerra and when gg looked on the web, there was not really any help except to upgrade mesa and then someone said that made no difference. Changes that will get checked into GIT later tonight yet: - added reset icons by the slider bar as IgorBeg suggested - changed the line up of the button bars in the compositor to match Igor's image (had to cover the dog's ears again during this argument) - fixed the Generate Keyframe and Keyframe Spanning minor Segv's @IgorBeg About "Smooth feature changes the HistogramRGB very much. Is it right?" Yes, it is correct and I am sure there is a good explanation but I do not yet know what it is. GG will have to look at the code again to explain it later. |
|
|
@MatN I just downloaded the crash. Will let you know. Earlier today we found a SEGV if you click in the timeline "Generate Keyframes while tweaking" and it tries to update the missing icon in the Compositor. That fix will be checked in tonight. |
|
|
Looks like the "mesa" graphics library is a problem. I think we might have a computer with "mesa" installed so will try that here. Update: well, duh, my laptop and gg's desktop use mesa (not nvidia) and I have tried doing different things with the plugin and then turning it on/off and can not get it to crash. GG looked at the core dump but unfortunately it did not provide a clue. |
|
|
Sorry for testing so late in the month, but I have crashes using the videoscope effect. Machine: Ryzen 2400G, 4 core/8 thread, 32G ram, using built-in GPU, vaapi as preferences - performance. Movie: Big Bucks Bunny 2160p60 , file name as downloaded bbb_sunflower_2160p_60fps_normal.mp4 . The new videoscope in the compositor seems to work fine. The videoscope _effect_ however has two problems: - It's content in only in white. - It crashes when switching visible/non-visible (magnifying glass), I believe mostly when making it non-visible. It happens frequently, but have not yet found a foolproof way to force it. It crashes, but does NOT seem to produce a core dump file. It was built from the latest git as of today around 15:00 UTC, from scratch using bld_prepare and autogen, as per manual. The terminal showed this: =============== Cinelerra Infinity - built: Mar 30 2020 17:40:03 git://git.cinelerra-gg.org/goodguy/cinelerra.git (c) 2006-2019 Heroine Virtual Ltd. by Adam Williams 2007-2020 mods for Cinelerra-GG by W.P.Morrow aka goodguy Cinelerra is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. There is absolutely no warranty for Cinelerra. mesa: for the --simplifycfg-sink-common option: may only occur zero or one times! mesa: for the --global-isel-abort option: may only occur zero or one times! corrupted size vs. prev_size Aborted (core dumped) =================== journalctl -b has this near the end: ================ Mar 30 23:34:16 test-pc systemd-coredump[2362]: Core file was truncated to 2147483648 bytes. Mar 30 23:34:17 test-pc systemd-coredump[2362]: Process 1815 (cin) of user 1000 dumped core. Stack trace of thread 2341: #0 0x00007f6b5128be97 n/a (n/a) 0000001 0x00007f6b512dd90a n/a (n/a) ============= |
|
|
Delete my old buttons request, please. Scope menu very good. Is it possible to add the Clear button near each slider, please?. I added a photomontage (Scopes_withClearBtns.png). Smooth feature changes the HistogramRGB very much. Is it right? It is strange, I think. I added an animated GIF (Scopes_Smooth-withAndWithout.gif) with and without Smooth feature. The frame of the video is always the same. I like Sam (3008 3010) and Andrea_paz (3015) ideas. I hope GG can implement them. Thanks. Off Topic but due to the changes: Take a look at the screenshot "Cin20200229-vs-Cin20200330.png" before and after, please. Can you reposition the buttons as in Cin20200229 version, please?
Scopes_withClearBtns.png (40,486 bytes)
Scopes_Smooth-withAndWithout.gif (47,992 bytes)
Cin20200229-vs-Cin20200330.png (123,920 bytes) |
|
|
Thanks for the improvements! @Phyllis: to answer your questions based on Scopes-100.jpg: 1- The two 90° diameters are not necessary; instead the lines "I" and "Q" that are not shown in the image are. There is only a hint of the "+I" line. However, the "4 partial lines" serve to remember the color wheel below and therefore to "take measurements". 2- Yes it is "I" line; but it's better to make a complete diameter that also shows the opposite end "-I"; also it's better to add the other remarkable line: the "Q" line. 3- the six zones (RGB+CMY) are shown as you say; note that they represent 75% colors but there are variations so the result is not a regular hexagon but is elongated. 4- The shapes around 6 points of 75% serve to better visualize those areas (usually they are even larger than those shown). I think you can do a simple overlay of the grid of lines and points on the vectorscope because the ratios are always the same. You simply have to be able to resize together with the vectorscope. Note that histogram and waveform can be resized independently along X and Y, instead vectorscope (fortunately) always keeps the square geometry, resizing X and Y at the same time to keep the circle always proportioned. Being a simple oversized grid, I think it is easy to visualize it or hide it with a button. the most complicated part is that the color wheel of our vectorscope is quite rotated compared to that of DaVinci Resolve or other vectorscopes. It would be better to make it more standard, then it would be enough to take a grid from some program, customize it and then add it to our vectorscope. Or you can always take the std grid and rotate it to fit our color wheel. I tried to adapt a grid on our color wheel with Inkscape, but the result is very bad. The important lines are: "I" for the skintones (+I) and the blue of the sky (-I); "Q" for the greens of the grass (-Q). The six points are not arranged exactly symmetrically (120°), but derive from calibration with color tests (type F_pal75bars). The result is an elongated hexagon because the radius of the six points is not always the same (i.e. the various colors have slightly different saturation values if all set to 75%). I enclose an image of the vectorscope grid that I consider the most complete (and best) and also the most used color wheel.
vectorscope-02.jpg (24,132 bytes)
verascope6.jpg (102,830 bytes) |
|
|
That's great. The first test was good. The thing with the sliders works much better. Also the smooth option is a blessing, the appearance is so much better. The other changes are also good. Thx :-) |
|
|
Checkin includes a bunch of stuff but as far as Videoscope goes, here are the changes: - checkbox "Smooth" added to get rid of unpleasing black lines of missing data - slider bars in with retaining of values as Andrea suggested. Note the values for the plugin are saved separate from the values of the Compositor/Viewer. - lines as separator in the Scopes pulldown so it is more clear that only 1 per section checkable. - Viewer button spacing fixed - Compositor button bar back to only 1 line - IgorBeg's suggestion in note 2997 for using half of the data in vectorscope not implemented but still may become useful in the future. Also do not want to put the funny icons back unless have to. - because of resizing it is really hard to put the labels over the 3 different areas and I could not convince gg to add that even though it would certainly look better to me - vectorscope changes not implemented until I have a chance to study the information provided by Sam in the last notes (maybe the fuzzy circle lines will be addressed later too) |
|
|
A little note, if you watched this video https://youtu.be/SP2Qj9-rV-w?t=20 it shows that the vectorscope corresponds to the color wheel. Kdenlive has added the possibility to show the color wheel in the background of the vectroscope. Below is a screenshot of this option. I find it very convenient.
Vectorscope-background.jpg (47,649 bytes) |
|
|
@PhyllisSmith 1. It would be advantageous if these four lines were available. There you can see how Resolve has placed these four lines. https://youtu.be/8I9t_z921-c?t=133 It looks the same in Premiere, only the Vectorscope disk is slightly rotated. Here is an additional video on this topic. https://youtu.be/SP2Qj9-rV-w 2. it would be great if you make this optional. That means it can be faded in. In the first video I posted you can see that it is optional. This 45 degree line is called "skin tone indicator". 3. & 4. The second video explains it quite well. https://youtu.be/SP2Qj9-rV-w or this video https://youtu.be/F2Emr5ASLds?t=252 |
|
|
HELP -- Need information about Scopes-100.jpg. I have looked on the web and still do not understand. 1 - ?? the code should add 4 permanent partial lines like shown at every 90 degrees? 2 - ?? is the other line that is at 45 degrees supposed to be drawn in that spot all of the time? is this is what is called the I-line? is this supposed to represent skin tone? 3 - ?? do the 6 zones mean the 6 concentric circle areas? it seems that we already show these? 4 - ?? what do the purple bracket looking things represent? Almost there and will checkin whatever we do have late today. |
|
|
@IgorBeg I like the idea with the separator lines in the menu. +1 |
|
|
@IgorBeg @Olaf I mean the black dividing lines. Depending on how big the window is, sometimes they appear and sometimes they disappear again. I don't mean the green lines, they're fine. @PhyllisSmith Thank you very much for the feedback. That would be great if the subpixel rendering would work. I don't know if anti-aliasing is included that together makes rendering images and controls worlds better, but you'll surely find a solution. |
|
|
@Olag How come I can not see this in the forum? I would like to. RE: The new videoscope built into the compositor I have made a drawing that should show how I imagine th... By Olaf, 9 hours ago |
|
|
Just a short update follows. Some suggestions will have to be implemented after the monthly builds though. @Sam A subpixel solution was tested yesterday but it does not solve the problem (but I did get a big lecture from him on how subpixels work, so all is not lost). He has tried various ideas and is still working on that and is currently the main focus of the effort. BTW -- these black lines are not black lines but denote missing data -- he provides information that gg finds useful -- however, he recognizes how it looks and is trying to acomodate. I have not discussed the rings with him yet. Will fix the Viewer button space problem. @IgorBeg About note 2990 - 1-Compositor ran out of room for buttons but I think I have convinced him to make it only 1 row again by removing the 2 Keyframe related buttons only in the compositor. 2-the clean and more self-explanatory pulldown instead of the buttons really is an improvement. gg does not want to bring the buttons back unless he absolutely has to. The place where the buttons were is now being used to record values when you LMB click on a scope. Your question: " If I make smaller the window to its minimum size it does not occur. Can you confirm or less, please?" I confirm and that is because as mentioned previously, the black lines represent missing data. @Andrea_Paz Slider bars have replaced the dials and are under test. As is updating correctly without having to first move +1 when used in the plugin and in the Compositor. I have mentioned to him to save the slider values between sessions and he acknowledged that that is easy enough to do. Also, have not discussed the 6 line proposal in the vectorscope but have at least printed out the image so he can figure that out later. |
|
|
@Olaf I think that @Sam was speaking of the black line (vertical in Histogram and horizontal in Waveform), not about the grid green line, in correspondence of the scale's numbers. @Sam I see like in your picture (videoscope.png) when I stretch (enlarge) the window. If I make smaller the window to its minimum size it does not occur. Can you confirm or less, please? @All For the Scope Menu, what do you think divide the 6 different scopes with a line? So the User can understand that max only three charts are showed. Scope: -------------------- Histogram Histogram RGB -------------------- <-- Waveform Waveform RGB Waveform ply -------------------- <-- Vectorscope -------------------- And, It would be good to add a title above every chart. (mpfh,... I have to do a photomontage to explain better) |
|
|
@Sam: "1 The histogram shows dividing lines again and again, see the attached picture." This is not a defect, this is a feature. |
|
|
"It would be very handy if like in the first note of Andrea, see his picture, the six zones could be displayed in the vectroscope and the line for the skin tone." +1 My very stupid idea: when you are playing with Vectorscope tool enabled, it could take the half data of the frame to consumes less cpu. Vectorscope would take only the odds data or, better, when the odd frame is displayed the Vectorscope take the odd data and when the even frame is displayed it take the even data. A button (Fast Vectorscope - less quality) in Vectorscope could enable/disable that function. It will be less accurate but faster, I think. I know I explain very bad, sorry. You can try to use the Vectorscope with Proxy (not scaled) and then without. Proxy uses less data because the image is smaller and then Vectorscope is faster. |
|
|
Here is a small article https://en.wikipedia.org/wiki/Subpixel_rendering , what I actually mean with the subpixel. With the term subpixel I mean the subpixel rendering with antialiasing. Here is a picture from the German Wikipedia, which shows the advantages of this technique.
Subpixel_rendering.jpg (74,200 bytes) |
|
|
I noticed a small bug in the viewer. With a layout scale factor of one or even smaller the videoscope button in the viewer is cut off. See attached image.
Videoscope_button_viewer.jpg (96,624 bytes) |
|
|
@PhyllisSmith You wanted to be reminded in case you missed something. It would be very handy if like in the first note of Andrea, see his picture, the six zones could be displayed in the vectroscope and the line for the skin tone. By the way the waveform ply is great. I like it a lot. |
|
|
1 The histogram shows dividing lines again and again, see the attached picture. It's only a little thing, but this error has been going on for ages. It would be nice if these dividing lines are not shown, then it works as it should. 2. In the vectorscope the rings are displayed with dotted lines. Due to the fact that Cinelerra cannot handle subpixels, pixels that are close together are displayed thicker than diagonal pixels. Thus the rings look frazzled in some places. You can also see the problem of the waveform. The waveform in Cinelerra looks much rougher than in other NLEs like Kdenlive for example, which also handles subpixels. There the waveforms are very fine and detailed than in our case. The long term solution would be that Cinelerra also handles subpixels, the short term solution for the rings in the vectorscope would be that the pixels of the dotted line always have one or two pixel distance between the individual pixels, so there is less of this ugly effect. 3. I agree with Igor that sliders would be better than knobs. Knobs are more space-saving but very impractical to use. Also, the knobs don't look very aesthetic. As a designer I would rather use the sliders in Cinelerra. The knobs in Cinelerra probably don't look that good because subpixels don't work here either. 4. I personally find the drop-down menu better than the "ugly" icons that were seen before. Now it looks clearer. I am a friend of clear and simple interfaces. I'm not a friend of Apple's business methods, but in design they have met the ravages of time. Simplicity and clarity have become Apple's design characteristics and people like it. By the way, thanks for the improvements!
Videoscopes.png (167,682 bytes) |
|
|
The videoscopes came out great for me. Thanks. You're spoiling me too much! It's dangerous because I tend to ask for more and more... :-) For the plugin I confirm what IgorBeg said; dials work only when we vary the cursor and, they remain fixed if we continue to vary them, until we move the cursor again. Another unimportant little detail: is it possible to remember the set position of the dials between one opening of the videoscopes and another? So those who prefer the "dot density" to 1, will find it already set every time they open the videoscopes. |
|
|
Now, the "dot density" of the Waveform, WaveformParade is really good for me. And "Waveform ply" very useful. Thanks. Some of things,... only my personal opinion/taste. 1) Compositor: in the Compositor window the "Navigator" tool (from "Rewind" to "Jump to end" buttons) has been moved on the top. I would like as before. It is consistent with the Viewer. You can see that when the Compositor window is narrower. For me the Navigator should be on the bottom. 2) Videoscope: I would like icons instead of Scope pulldown menu because I can see all the options without click on it, even though I understand that it is more clean now. And, I would prefer the Slider instead of the Knob to change "dot density". I will wait for other users' considerations. A great improvement. Thank you. PS: When I insert a Videoscope Plugin in a track and I change "Dot density" with the knob, the waveform is not updated. It works right with Comporitor's Vectorscope. |
|
|
Checked into GIT the following changes BUT we are still working and a couple of dials on the plugin are not hooked up yet. - scopes are now visible immediately without having to move the cursor - funny icons are now pulldown menu - new dials in top bar (these are working in Compositor and Viewer) for modifying something (not sure terminology here) - fixed RGB Parade so not "dot density solid" - choose "Waveform ply" -- this is really cool - probably something else I missed Need clarification on "in vector scope that the Scope circle looks a bit ugly. It's not really a circle, but a stepped circle. Even the lines in the Histogram plugins don't really look straight." The circle is a dotted line; what should it be instead?? Lines in the Histogram plugins are straight; is it an optical illusion?? Please provide feedback and critique. |
|
|
Videoscope issues are being worked yesterday and today to include Andrea's last suggestion to make the scopes relevant. I do not know if all requests will be incorporated but my hope is that they will be so like Masks we can get it all done at once instead of in pieces. Be sure to add anything not already mentioned in the email or the these 2 BTs if you think something else is needed. |
|
|
When you activate the videoscope via button in Compositor, the graphs are empty. We must act on the cursor (for example +1 frame) to make the scopes content appear. Then, if we resize or switch from waveform to RGB Parade, or any other intervention on the plugin window, the graphs empty each time and we still have to act on the cursor to return them. Is it possible to overcome this inconvenience? |
|
|
From Andrea email: Is it possible to make the Videoscope plugin act globally on the compositor window, without the need to apply it to a track/edit? Let me explain: whatever the video tracks are, when I click on the new Videoscope button the plugin window opens showing the scopes of the active track, that is the one shown in the Compositor. So there is no need to put the plugin as last of the track/edit. This is always active, always the last one and it works on the active track and on the Insert Point position, which we can change at will. Basically I ask to make the plugin "global" and not anchored to its track and its position in the stack of plugins. Its activation does not require to find it among the video plugins, but to click on a button, or menu, placed in Program windows. Of course it remains the possibility to use the plugin as it has always been. I don't know if I'm making myself clear. I'm gonna put in a photo montage: https://postimg.cc/0rdKmM9g |
|
|
Also, see the closed duplicate 279 for additional relevant images and details. |
|
|
+1 Yeeeessssss, pleeease?! |
|
|
I would add the I-line in the vectorscope and the six zones of the primary and secondary colors to 75%. See the following image:
Scopes-100.jpg (56,562 bytes) |
- Anonymous
