View Issue Details

IDProjectCategoryView StatusLast Update
0000185Cinelerra-GG[All Projects] Bugpublic2019-06-02 01:22
ReporterSam Assigned Togoodguy  
Status closedResolutionfixed 
Product Version2019-03 
Target VersionFixed in Version2019-04 
Summary0000185: Projector Camera view
DescriptionThe Projector camera view doesn't fit yet.
As soon as I reduce the red frame, the green frame would have to be reduced proportionally, but it doesn't. I shrink the whole view area (red frame -> projector) of the visible area, so the area of the camera view should shrink as well. I can't have a larger view area of the camera than the area of the projector (unless I enlarge it later in a second step). If I would now switch from projector view to camera view, then it would have to have the same size, 50% smaller projector area = 50% smaller camera area. Then the view of the red and green frame would be correct. The green frame can be enlarged in the second step, but only after the size has been adjusted proportionally to the red frame. The green frame may also be larger than the red frame, but this would mean a zoom inside the red frame.
Steps To Reproduce1. Click on the projector view (Compositor F6) to see the red frame.
2. Reduce the red frame to 50% of the composite size. The video image has been reduced in the same ratio. see image 1.
3. Switch to camera view F5.
4. The green frame still has the same size as the compositor window. It has not been adjusted proportionally to the projector view.
5. I think the green frame should be the same size as the red projector view.
TagsNo tags attached.




2019-06-02 01:22

manager   ~0001633

Closing while working on manual updates to merge into the LaTex version later.


2019-05-03 17:14

manager   ~0001484

Leaving this resolved and not closed because I really, really have to remind myself to fix the manual for camera / projector usage.


2019-04-13 21:40

manager   ~0001371

A good resolution that will hopefully solve all problems.


2019-04-13 19:20

reporter   ~0001370

I agree with Sam. Really, really well done. PERFECT.
It will also help new users, I think.


2019-04-13 17:47

administrator   ~0001369

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.


2019-04-13 17:39

manager   ~0001368

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:

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)
grab_20190413-113450.png (37,996 bytes)


2019-04-12 09:16

administrator   ~0001354

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.


2019-04-12 07:49

administrator   ~0001353

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.


2019-04-12 02:11

manager   ~0001352

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:

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.


2019-04-11 19:16

administrator   ~0001348

Now I understand your concerns, maybe GG can solve it the way I suggested or offer another way to always identify the projector boundary.


2019-04-11 19:07

reporter   ~0001347

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.


2019-04-11 15:18

administrator   ~0001344

Sorry about so many uploads. My Gimp always exported the wrong image. Now it should be right.

Camerview.jpg (43,155 bytes)
Camerview.jpg (43,155 bytes)


2019-04-11 15:13

administrator   ~0001343

Last edited: 2019-04-11 15:14

View 2 revisions

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)
Projectorview.jpg (43,234 bytes)


2019-04-11 14:37

administrator   ~0001342

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_01.jpg (36,326 bytes)
camera_frame_02.jpg (41,125 bytes)
camera_frame_02.jpg (41,125 bytes)
camera_frame_03.jpg (57,265 bytes)
camera_frame_03.jpg (57,265 bytes)
camera_frame_04.jpg (42,352 bytes)
camera_frame_04.jpg (42,352 bytes)


2019-04-11 13:58

administrator   ~0001341

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.


2019-04-11 12:40

reporter   ~0001340

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.


2019-04-11 10:20

administrator   ~0001339

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.


2019-04-10 23:29

manager   ~0001336

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.


2019-04-08 08:45

reporter   ~0001319

I confirm what Sam wrote.
In CIn-20181231 version it was right, or better, like reported by Sam In "Steps to reproduce".


2019-04-04 17:52


Issue History

Date Modified Username Field Change
2019-04-04 17:52 Sam New Issue
2019-04-04 17:52 Sam File Added: Projector-camera-view_01.jpg
2019-04-04 17:52 Sam File Added: Projector-camera-view_02.jpg
2019-04-04 17:52 Sam File Added: Projector-camera-view_03.jpg
2019-04-08 08:45 IgorBeg Note Added: 0001319
2019-04-10 23:29 PhyllisSmith Assigned To => PhyllisSmith
2019-04-10 23:29 PhyllisSmith Status new => feedback
2019-04-10 23:29 PhyllisSmith Note Added: 0001336
2019-04-11 10:20 Sam Note Added: 0001339
2019-04-11 10:20 Sam Status feedback => assigned
2019-04-11 12:40 IgorBeg Note Added: 0001340
2019-04-11 13:58 Sam Note Added: 0001341
2019-04-11 14:37 Sam File Added: camera_frame_01.jpg
2019-04-11 14:37 Sam File Added: camera_frame_02.jpg
2019-04-11 14:37 Sam File Added: camera_frame_03.jpg
2019-04-11 14:37 Sam File Added: camera_frame_04.jpg
2019-04-11 14:37 Sam Note Added: 0001342
2019-04-11 15:13 Sam File Added: Camerview.jpg
2019-04-11 15:13 Sam File Added: Projectorview.jpg
2019-04-11 15:13 Sam Note Added: 0001343
2019-04-11 15:14 Sam File Deleted: Camerview.jpg
2019-04-11 15:14 Sam Note Edited: 0001343 View Revisions
2019-04-11 15:15 Sam File Added: Camerview.jpg
2019-04-11 15:17 Sam File Deleted: Camerview.jpg
2019-04-11 15:18 Sam File Added: Camerview.jpg
2019-04-11 15:18 Sam Note Added: 0001344
2019-04-11 19:07 IgorBeg Note Added: 0001347
2019-04-11 19:16 Sam Note Added: 0001348
2019-04-12 02:11 PhyllisSmith Note Added: 0001352
2019-04-12 07:49 Sam Note Added: 0001353
2019-04-12 09:16 Sam Note Added: 0001354
2019-04-13 17:39 PhyllisSmith File Added: grab_20190413-113450.png
2019-04-13 17:39 PhyllisSmith Note Added: 0001368
2019-04-13 17:47 Sam Note Added: 0001369
2019-04-13 19:20 IgorBeg Note Added: 0001370
2019-04-13 21:40 PhyllisSmith Assigned To PhyllisSmith => goodguy
2019-04-13 21:40 PhyllisSmith Status assigned => resolved
2019-04-13 21:40 PhyllisSmith Resolution open => fixed
2019-04-13 21:40 PhyllisSmith Fixed in Version => 2019-04
2019-04-13 21:40 PhyllisSmith Note Added: 0001371
2019-05-03 17:14 PhyllisSmith Note Added: 0001484
2019-06-02 01:22 PhyllisSmith Status resolved => closed
2019-06-02 01:22 PhyllisSmith Note Added: 0001633