 |
Closing while working on manual updates to merge into the LaTex version later. |
|
|
Leaving this resolved and not closed because I really, really have to remind myself to fix the manual for camera / projector usage. |
|
|
A good resolution that will hopefully solve all problems. |
 |
I agree with Sam. Really, really well done. PERFECT. It will also help new users, I think. |
 |
I just tested it, it works fantastic. You have found the best solution. I think Igor will be just as happy with that. You can always see all the boundaries. Thanks for the effort. |
|
|
In the Camera view a yellow outline box has been added and checked into GIT. Hopefully this will provide good information for both points of view on usage. New ubuntu16 build at: https://www.cinelerra-gg.org/download/testing/cinelerra-5.1-ub16-x86_64-static.txz And you can see even more with a white box, if everything is off in the compositor and then you enable zoom view (F2) and zoom some until a white box appears. Then use your Camera and Projector. Attached is a png picture of that.
grab_20190413-113450.png (37,996 bytes) |
|
|
The best example is yesterday's video. I downloaded your video with 120 FPS. I inserted it into the video track. With many zoom and moving the camera view actions and adding a smaller video afterwards, I can't tell if the first video with the white smoke is the original size or if I changed the camera view. Only by inserting a second video that was full size I was able to see that the first video was smaller and in addition that it moved the camera view a few millimeters to the right. With many zoom actions and moving the camera view, it is very important to recognize at first glance that the camera view is not correctly adjusted. Currently I have no visual feedback about where the camera edges are. I have to find out for myself by always inserting the image with the maximum size. This problem would be solved if the green frame would also show the actual position of the camera view. https://streamable.com/3n1ll |
|
|
Before I reported the new bug, it worked 80% right. The only thing that didn't work properly was the proportional reduction by the projector. The green frame behaved correctly before this change, the only thing that should be corrected was the recalculation of the green frame in size. For example: Red frame shrinks by 50%, this also reduces the camera view by 50% and adjusts the relative position size to the red frame in the same ratio. This was the only problem that should be fixed, but now the supposed bug was fixed and a bigger mistake was produced. Again the green frame does not represent the projector boundary, the green frame represents the camera boundary. Only the red frame represents the projector boundary. Therefore, the green frame cannot keep the same size and position as the red frame. The red frame indicates in which direction and size I have changed the project view. However, the green frame does not currently show me in which direction and size I have changed the camera view. But this visual information is exactly what the green frame is supposed to give me. In which direction and size did I change the camera view? Unfortunately, I can't get this information from anywhere at the moment, because the green frame is used to display the projector view visually. I always have to insert an image to find out in which direction I changed the camera view. Without an inserted image it is currently pure speculation how the camera view was changed. If the improvement suggestion, with both frames at the same time, is too difficult to implement, I would appreciate it if the condition is restored as it was before. With 20% bug are rather justifiable, but 100% is then still too far away and that is the current state. |
|
|
STILL WORKING THIS ISSUE, but there is some commentary below anyway. IgorB: there is a new ubuntu16 build with issue 190 and 184 in at: https://www.cinelerra-gg.org/download/testing/cinelerra-5.1-ub16-x86_64-static.txz The green (camera) box shows what is in the buffer is probably the main reason for leaving it as is. I.e, that is what the track buffer actually looks like. There are other reasons: 1) the code is finicky so that what looks like a simple change, impacts something else leading to the initial bug here 2) appears to be original intent from the Secrets of Cinelerra manual 3) a test involving the green box, leads to a jittery rendition when moving 4) the simplest method works out in the code to be the best method My understanding on this is so poor, that I can not come up with a good reason for GG to change it yet. But I am continuing to ascertain usage because I need to so I can create better documentation for the manual. |
|
|
Now I understand your concerns, maybe GG can solve it the way I suggested or offer another way to always identify the projector boundary. |
|
|
As said previous, it is fundamental to know the boundaries of the Projector because out of those limits nothing is showed (rendered). Then when you are in Camera mode you must to see where are the boundaries of the Projector. Your last two images, "Projectorview.jpg" and "Cameraview.jpg", resolve the question very good, Sam. If it is not possible, I think that it is more important to see the boundary of the Projector, with green colour, when an user use the Camera. If you look at your picture "camera_frame_04.jpg" and you delete the red frame you understand what I want to say, I hope. |
|
|
Sorry about so many uploads. My Gimp always exported the wrong image. Now it should be right.
Camerview.jpg (43,155 bytes) |
|
|
During the photomontage I noticed the following. It could always show both frames. When you press the camera view, the camera layer is above the red frame. Conversely, when I am in the projector view, the red frame moves above the green frame. Here is the photomontage. With this improvement you always see both frames, no matter in which view you are, only with the difference that the corresponding frame always slides one layer up. This has the advantage that you can always see how the other frame relates to the selected frame. If the green frame is congruent with the red frame, then I only see the green frame in the camera view and vice versa the red frame when I am in the projector view. Thus, one gets a better understanding for the behavior of the camera view and the projector view.
Projectorview.jpg (43,234 bytes) |
|
|
For better illustration. Picture one shows how I reduced the size of the red frame, i.e. the projector view was reduced. I switch to camera view. Picture Two shows the green frame having the same dimensions as the red frame. Picture three shows the video image in the same dimensions as the camera view. In picture four I enlarge the camera view, the green frame is now larger than the red frame and is outside the red frame. The red frame limits the video image. The video image is cut off and has moved in the direction of the camera view, i.e. the green frame.
camera_frame_01.jpg (36,326 bytes)
camera_frame_02.jpg (41,125 bytes)
camera_frame_03.jpg (57,265 bytes)
camera_frame_04.jpg (42,352 bytes) |
|
|
It is not consistent to the projector view. I can move the projector view, red frame, freely. I can resize the projector view and the resize will be displayed in the compositor. If I reduce the projector view by 50% and drag this smaller red frame into the lower smaller corner, I see it. The red frame moves. If I do the same with the green frame, nothing happens! Why do I need a green frame that shows me the edges of the camera view, but doesn't move with the camera view? That doesn't make sense for me. At the moment, the green frame does not serve any purpose at all. It doesn't move with the camera image, but remains frozen in the same place. But why does the red frame behave differently? The manual description is like this because it wasn't correct and intuitive from the beginning. A user, I think it was Olaf, noticed this mistake and rightly complained that it would be better for the frame to show the actual camera or projector boundary than just an imaginary frame. The error was corrected after a user request and now it's undone. This was not intended with my ticket, only the green frame was not adjusted proportionally to the red frame. Currently the green frame is reduced in proportion to the red frame, thats fine, but remains frozen. The green frame must remain freely movable, as it was before, then it would be correct IMHO. |
|
|
For me, It now works as it was before (from Cin5.1-20180531 to Cin5.1-20181231, tested). For the green frame in Camera controls, I think that, the initial idea of the developers was to indicate the limits of the Projector. Then with the green frame you know you are in Camera control mode but it shows the limits (borders) of the Projector. Maybe I am wrong. From the Manual: Compositing camera controls. Select the camera button to enable camera editing mode. In this mode, the guide box shows where the camera position is in relation to past and future camera positions but not where it is in relation to the source video. Dragging the camera box in the compositor window does not move the box but instead moves the location of the video inside the box." |
|
|
Unfortunately, it doesn't work the way I thought it would. The green frame doesn't change the position at all. Even if I reduce the camera view, the green frame remains in its original size without changing. The video image is reduced in this process, but not the green frame. Even if I change the camera position, the camera image moves with it, but not the green camera frame. The green frame should move with the camera image, because the green frame represents the camera view. Before this change it worked correctly, except for the proportional adjustment of the green frame by the red frame. |
|
|
Mods have been made and checked in. A ubuntu 16 static tar will be available later today. I "think" it works the way we expect now but there were quite a few tweaks done so I hope we did not miss anything. Let us know if some new problem. |
|
|
I confirm what Sam wrote. In CIn-20181231 version it was right, or better, like reported by Sam In "Steps to reproduce". |
|
|
Projector-camera-view_01.jpg (114,134 bytes)
Projector-camera-view_02.jpg (64,611 bytes)
Projector-camera-view_03.jpg (71,092 bytes) |
- Anonymous
