 |
If in the future, multiple complaints arise about the boundary box/outline it could perhaps be made into a Preference. |
|
|
Yes, there is a lot of this -- "to stick to the archaic Adam ... gui style". Sorry, I wish it was not so but unfortunately when we do get rid of something, it comes back to bite us. For example, BT 313 ("With ogg vorbis I used to succeed better"). The native version was deleted in February 2019 because the ffmpeg version was available and it was difficult to keep fixing it but ffmpeg's version also needs fixes. Another example, BT 334 ("Removed Reel Name, Reel Number, Time Code Start from Asset Info in Resources & Preferences" which was done in July 2017. These are just 2 recent examples and I am sure there are more. The problem with deleting stuff is there is huge aversion by the developer to ever put it back no matter how adamant the chatter. P.S. it would be really nice if a better interface could replace the current one, but that is even more impossible so we are stuck with some archaic looking stuff !!! |
 |
Yes, this useless frame is no longer on the video. The frame appears after a video is loaded and the zoom is not set to Auto. This is your proof that the frame is useless. The fact that the background color of the canvas is now adjustable has apparently not got around yet, the connection still has to be revealed. When playing the video in all other modes, the frame is switched off and faded in again after stopping, which causes an optically irritating flash. Probably one wants to stick to the archaic Adam Williams gui style in this respect as well. The resulting changed zoom in the full-screen display overrides the settings made by the user and remains in this changed setting when switching back. But that's no longer the issue. You, who work with CGG, must like it after all. |
|
|
Checked into GIT the mod to ensure that the boundary line does not lie on the video. I have tested a lot and do not see any occlusions any more. |
|
|
If everyone who has to edit their videos with CGG sees it that way, then there is no alternative.
Composer-default_wo_video.png (52,061 bytes) |
|
|
I think this is the description of the only outstanding issue which we are fixing by adjusting the frame location to never lie on the still image. Just to refresh from Note 2006: " ... In the meantime I put the bright frame up for discussion, which lies on the edges of the picture, thus covering it and preventing exact working in the edge area. Is this frame necessary for the still image ... (? Should the frame, if still necessary at all, not border the still image instead of lying on it?" AND Note 2048: "No matter on which solution one agrees, nothing should be allowed to lie on the video itself. Holy ground, highlander!" We have a mod to ensure that the bright frame no longer lies on the image and the 'Holy ground, highlander' is protected and it will be checked into GIT in a day or 2. It turns out that this frame dates back to the original code in the HV version. At about line 2540 of cwindowgui.C is: // Always draw output rectangle float x1, y1, x2, y2; x1 = 0; x2 = mwindow->edl->session->output_w; y1 = 0; y2 = mwindow->edl->session->output_h; output_to_canvas(mwindow->edl, 0, x1, y1); output_to_canvas(mwindow->edl, 0, x2, y2); get_canvas()->set_inverse(); get_canvas()->set_color(WHITE); get_canvas()->draw_rectangle((int)x1, (int)y1, (int)(x2 - x1), (int)(y2 - y1)); get_canvas()->set_opaque(); } This drawn line is a good idea and makes it real obvious where the project's boundary really is, based on the session format, so it is easy to see what will actually be rendered in the final video. In other words, yes, it is necessary from my point of view and will remain. |
|
|
@PhyllisSmith: "but you only see it when you zoom in." This may be because the majority of CGG users follow you and set the Composer Zoom to Auto. In all other settings, the bounding box is displayed without having to load a video or zebra. (By the way, in that form this would be a bug in auto-zoom, because the frame is not displayed there, isn't it?) Here is a video from the year 2010 which only shows that this boinding box was always there: https://www.youtube.com/watch?v=zag7g6GdHJE
Bb.png (44,145 bytes) |
|
|
@Olaf OK, I had to dig up a PAL file 720x576 and can see the white boundary now. but you only see it when you zoom in. I do not know where it comes from but will attempt to figure it out tomorrow. |
|
|
Well, the fixes that got checked in and the explanation about fractional pixels is still relevant and needed to be done. @Olaf "background color of the canvas used ... is the same as the color of the bounding box, so it is no longer visible in the video." So I have attached a file using purple instead and there is no white boundary. You can see I have it zoomed in as much as I can and have shown just the right most bottom corner. So far no matter which video I load, I can not see a white boundary but there is a surrounding box that may be the exact size of what you are loading. I will try that next but I ran out of time today. More later.
purple_zebra.png (33,584 bytes) |
 |
Okay Olaf, I saw your photomontage, and I understood. In your image seems that you loose (you can not see) a lot of pixels. I confirm that bounding box is on the video and by my test that boundary line is 1 pixel width, I think. Of Course, 1 pixel width is a “big” value if the size of the Compositor window is very little (with Zoom= Auto) because it hides more video information; usually, in my old Notebook the Compositor size is about 530x400 pixels. I can not tell you that it is important for me like for you, but I can agree with you that the boundary line should not cover the video information. In the Compositor I can see the differences on the video if I toggle between play and stop. In the output render I don’t see lack of information. |
|
|
@IgorBeg The whole thing has absolutely nothing to do with the protection areas for obsolete tube televisions. Please have a look at my photomontage again (https://www.cinelerra-gg.org/bugtracker/file_download.php?file_id=350&type=bug). The bounding box is *on the video*, so it covers a part of the video in an inadmissible way. Even if this part seems to be small at a glimpse, you will see on closer inspection that the work in this area is not insignificantly complicated. Usually, instead of the bounding box, the composer punches out the entire area of the video format, in this example 720x576. The color of the canvas is independent and can be determined by the user. No matter on which solution one agrees, nothing should be allowed to lie on the video itself. Holy ground, highlander! Something else are camera and projector, which bring their own frame to show size changes above the actual video area. |
|
|
About #0002006 Olaf: “In the meantime I put the bright frame up for discussion, which lies on the edges of the picture, thus covering it and preventing exact working in the edge area.” If I understand correctly Olaf’s request, I think that He would like to hide the boundary, of white colour, around the video/image (Project format’s boundary) in Compositor and showed it only when the “Show safe regions (F10)” tool is enabled. So You can see the three boundary: the boundary of the Project format and the two boundary of the safe regions. And using the “Composer BG color”, in Preferences, to set a different background color as a “boundary” for the video frame. Olaf, can you confirm or less, please? |
|
|
Because of the time difference, I'm going to cut this short. Besides the matter of course, I had already expressly agreed to answer any questions that arose. The reference to and use of my photomontage in the video (0000237:0002400) can give the impression that the user has caused the problem himself. The background color of the canvas used by PhyllisSmith in the video is the same as the color of the bounding box, so it is no longer visible in the video. So geht das nicht. Topic missed. EOD. |
|
|
I don't understand the connection to the 720x576 (576/25p, DVD PAL) video I showed, @PhyllisSmith 0000237:0002400. |
|
|
GIT checkin fixes the background switching to black when using the OpenGL driver. Another improvement was checked in that fixes the "flash" that occurred in a couple of different places when you restart playing after having stopped. And now for the elephant in the room! The boundary problem is due to a "fractional pixel" which is a result of odd dimensions (odd dimensions meaning in this case, not divisible by 2). For example, when media that is 1303 x 1017 (an example is the webp video in note 2391) is loaded - i.e. not even numbers. the session takes on those dimensions. So, using the OpenGL driver, this fractional pixel appears as a boundary on the bottom in the Compositor. CinGG does not like these odd dimensions and in fact when you load the above video, you get the error message of: "/root/Downloads/0000237...of the compositor.webp's rersolution is 1303x1017. Images with odd dimensions may not decode properly." In the case of using the X11 driver, this oddity results in a fractional pixel border on all 4 sides as opposed to just the bottom as in the OpenGL driver. You should make a note of the fact that if you create a New project or try to change Format dimensions in that menu to odd numbers, the program changes them to even. There is a very good reason for this to avoid these types of problems. Here is the way to get past the OpenGL bottom boundary problem. Bring up the camera in the Compositor and change the Y coordinate to 0.500 to compensate for the fractional pixel that resulted from odd dimensions. In the case of using the X11 video driver, add 0.50 to both the Y and X coordinate. A demo illustrating that if you use even numbered dimensions format (zebra.jpg), it works as expected is at: https://streamable.com/at6rz The first part of the demo shows background color is working as expected. The second half shows the ERROR MESSAGE when odd dimensions are loaded warning of potential problems and you see the boundary. It also shows how you can work with this. |
|
|
Short update -- a fix for the confirmed playback OpenGL problem was generated yesterday and I am still testing. I now see the boundary problem and hope that too can be addressed. |
|
|
A screenshot for clarification. (Here you can also see that the frame is frayed in several places, which makes editing unnecessarily difficult.) If you have any questions, please ask, unfortunately I can't read thoughts. Thank you both for your cooperation! 0000237: Adjustable background color of the compositor.webp (493,698 bytes) |
|
|
OK !! now I have something very specific to address. I was using the X11 Video Driver instead of X11-OpenGL so now I see the problem and we can try to figure it out. Quote from Note 2006: "you can see for yourself what's lacking. ... In the meantime I put the bright frame up for discussion, which lies on the edges of the picture, thus covering it and preventing exact working in the edge area. Is this frame necessary for the still image (without switched on tools like camera, projector or cutting)? Should the frame, if still necessary at all, not border the still image instead of lying on it?" I STILL DO NOT UNDERSTAND the above so that is why I have nothing to show GG for him to work on. |
 |
I confirm the bug. |
|
|
Probably I am the only one who uses this function, otherwise there would have been complaints in the meantime. If you are bored you can try the following: You set the "Composer BG Color" to 006a00ae, load a video and watch the result. Then you play the video and watch the result. If the background of the canvas is identical in both cases (color: 006a00ae) then this request is considered done. If, however, the background switches to "black" when playing and is only "purple" when standing, a check of the previous work would be advisable. In both cases I ask for a short feedback. |
|
|
<blockquote> There is still more work to do to verify all 90 some places where vframe is being used, so do not hesitate to report missed spots or bugs as it will move things along a lot faster to an acceptable conclusion. </blockquote> So, the month is over, the next release is just around the corner and I don't see any progress. (Even today I can't see why the monochrome background color of the canvas (previously black!) has to be redrawn in more than 90 different places instead of calling one function.) |
|
|
The 3 week, i.e. 20 days, was used for development as explained in https://www.mail-archive.com/[email protected]/msg00449.html On Tue, 27 Aug 2019 21:33:19 a fix for "the buttons are shifted, one is almost covered" was checked in: "fix render progress booby, add batchrender warn for zero length, click to play layout fix, dav1d meson build fixes" I was wrong because I thought that the button that was almost covered was due to the mods made while working on the background color for the Compositor (I am frequently wrong!). End result was that since it did not involve background color, it did not involve the frame issue. OK to withdraw the question, but I am still going to look into it anyway. |
|
|
Hm…* As for the frame question, nobody's interested but me. I withdraw the question. -- * the general development was resumed after 20 days, according to git. av1, mask and ffmpeg. not the background. |
|
|
Today gg is working on "the buttons are shifted, one is almost covered" since Sam informed us that the "Click to Play" button is obscured and I totally missed this and my eyes could not see which button was covered (bad eyes and I did not look in the right places). Hopefully that will better illustrate the detected problem with the frame/image area. |
|
|
One question, is the development complete or is it still going on? |
|
|
Good work so far in the short time! There is apparently still time to final completion, you can see for yourself what's lacking. In the meantime I put the bright frame up for discussion, which lies on the edges of the picture, thus covering it and preventing exact working in the edge area. Is this frame necessary for the still image (without switched on tools like camera, projector or cutting)? Should the frame, if still necessary at all, not border the still image instead of lying on it? |
|
|
The latest GIT checkin includes changing the Compositor Canvas background color also. There is still more work to do to verify all 90 some places where vframe is being used, so do not hesitate to report missed spots or bugs as it will move things along a lot faster to an acceptable conclusion. The Canvas, as always, does not get rendered (at least not in my cases). |
|
|
Thx PhyllisSmith! Here's the corrected description of the feature request that didn't seem to do justice to the summary of the request before, see above, changes and priority highlighted with asterisks: Compositor background *complete with the so-called Canvas* is black and the color cannot be adjusted. This is not helpful if you want to crop videos with black borders, for example. In general, *a clear colour separation of window area (Canvas) and video is only an advantage*. Setting the background *- especially the canvas -* is one of the basic features, even Kdenlive can do it. I apologize for my linguistic inadequacies and the additional work that may result from them. |
|
|
The black area of the Compositor that exceeds the project dimensions is the Canvas -- it is part of the Pixmap -- and is not rendered. A error similar to what IgorB demo-ed is being fixed, but of course there could be more. |
|
|
Learning question: What do you call the (black) area of the Compositor that exceeds the project dimensions? In addition, the buttons are shifted, one is almost covered. babel.png (300,641 bytes) |
|
|
I only did a few quickly tests with Cin-Ub16-20190730. IMHO for the monthly builds I would use the 20190724 version because it is more tested. Further tests are required for the latest invasive mod. Sorry. Take a look please: https://streamable.com/pxqcx |
|
|
A mod has been checked into GIT to include this feature. I hope it covers what is expected, but am not sure. A Ubuntu 16 build is at: https://www.cinelerra-gg.org/download/testing/cinelerra-5.1-ub16-x86_64-static.txz A demo is provided of how to use it at: https://streamable.com/no6oz Testing is appreciated because the monthly builds will be coming up on Wednesday AND because there were about 90 places in the code that are affected by "clear vframe". |
 |
I would wish for my own alignment lines. PP has such a feature that is very handy when you want to align objects like text or even your own images that I want to show. https://streamable.com/l460f |
|
|
1) Any suggestions of where to pick this color? Settings->Preferences, Appearance by "Highlighting Inversion Color" and then you always have that? A good choice, at this point it fits and the setting can be changed at any time like anything else that is adjustable there. It would also be advantageous if the selected color is immediately visible, even without restarting. --> I agree with Olaf. 2) Or does it have to be Session based? With very few exceptions, I see no reason for this, so no, see also answer above. --> same here. 3) Will you want the Color Picker involved? I want to be able to determine a color that is clearly different from the video image, so that it can be captured by the eye in size and position at any time without tools such as superimposed frames. If the Color Picker can help and the user is no longer dependent on external programs such as kcolorchooser then yes. (Sorry Igor, very few users can remember the RGB colour code.) --> I would prefer a Color Picker 4) Should there be another tool added to the Compositor window? I'm not sure I understand the question correctly. Does this mean something like what is described under no. 0000238? Something like that in Kdenlive: https://streamable.com/a338p or like my photomontage: I find the solution via the FFmpeg "law of thirds" plugin too cumbersome.
Overlay-lines_03.jpg (136,889 bytes) |
|
|
Hi Leute! I'm happy for the project that the request has found a hearing. 1) Any suggestions of where to pick this color? Settings->Preferences, Appearance by "Highlighting Inversion Color" and then you always have that? A good choice, at this point it fits and the setting can be changed at any time like anything else that is adjustable there. It would also be advantageous if the selected color is immediately visible, even without restarting. 2) Or does it have to be Session based? With very few exceptions, I see no reason for this, so no, see also answer above. 3) Will you want the Color Picker involved? I want to be able to determine a color that is clearly different from the video image, so that it can be captured by the eye in size and position at any time without tools such as superimposed frames. If the Color Picker can help and the user is no longer dependent on external programs such as kcolorchooser then yes. (Sorry Igor, very few users can remember the RGB colour code.) 4) Should there be another tool added to the Compositor window? I'm not sure I understand the question correctly. Does this mean something like what is described under no. 0000238? |
|
|
Waiting for Olaf… (and the others) IMHO I prefer this option (like 0000247) were in Preferences>Appearance: a new option, for example “Background color for Compositor” and you always have that, until you change again. Default is #000000 (black), of course. And I would not use color picker but only “rrggbb” code like it is in "Highlighting Inversion Color". |
|
|
Any suggestions of where to pick this color? - Settings->Preferences, Appearance by "Highlighting Inversion Color" and then you always have that? - Or does it have to be Session based? - Will you want the Color Picker involved? - Should there be another tool added to the Compositor window? |
- Anonymous
