View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000275||Cinelerra-GG||[All Projects] Feature||public||2019-07-25 20:38||2019-10-02 11:45|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Target Version||Fixed in Version|
|Summary||0000275: Cropping tool in the Compositor does not Crop as expected.|
It looks like the crop tool in the Compositor applies the crop to every track and indeed to the current project (???) and so can not crop a single track.
Sam had created a short video showing how to crop by working with the projector and camera automation:
|Tags||No tags attached.|
You have given many good reasons which support your approach. My concern was a) that it should be easier for both of you, and b) that the built-in features would work as expected when released.
The singled out crop tool as an example is now worse than it was before because it obviously does not work properly in several places now. It is by definition in alpha state and this is not communicated - the video artist does not know it, he may rely on it and then experience a disappointment. The new prospective "customer" probably wonders if you don't see this for yourselves and deduces from it the invisible overall condition under the bonnet. With Git, obviously unfinished areas can be held back, but to whom do I tell this?
The Arch user frankly doesn't matter to me in this respect, I use Debian because Arch requires a lot more detailed knowledge and effort compared to Debian, and therefore time that I would miss elsewhere. Whoever uses Arch can handle all development tools, it is a distribution for advanced users. But you yourself say that the vast majority of users are not computer savvy, and the one Arch user thinks CGG is a low usage package.
Heroine is a very bad example. For developers of branches it may be a treasure chest of techniques, for users like me their product is simply useless. Heroine's Cinelerra was removed from Debian and Debian-Multimedia a long time ago because it is not usable in practice. HV lives from an unstable self-propagated reputation (which was even adopted uncritically by the German Wikipedia and which CGG doesn't mention a word) - in all those years one or the other movie should have been cut with it or a TV documentary or music videos or commercials or praiseworthy mentions in the hobby area should be found. Even the use of the name can trigger negative associations, which are transferred to branches/forks. Nevertheless, the effort to see the new version is often only in a reasonable "git pull", which you have certainly already automated?
It would have been easy to address the additions in the early development stage
What is important is that it works out for you and GG and that you can handle it. Points 1-8 speak for themselves.
I read your advice for future releases not based on the date. But WHAT WOULD ARCH DO? - which most people consider to be a good working system. Advice from an Arch person: "For packages with low usage, a reasonable exposure is enough" which for Cinelerra we attempt to do by informing people on updates via Mantis BT and email and by providing a tar build for testing. Arch specifically keeps a list of ISO releases made by the Arch Linux release engineering team usually MONTHLY.
Quote: "A release should be made after tasks have been completed"
Quote: "and should not contain any open construction sites"
Quote: "It should not be more than four releases a year to avoid pressure to quickly plug holes"
Quote: "If you want to have an update in between, you can build it yourself from the Git"
Reasons why we do Monthly builds:
If you are looking for software, this is the general procedure: After selection based on your own search or recommendations, the software is downloaded and installed. The aptitude test now takes place in the next few minutes. If there are obvious weaknesses, the test is aborted and the software is considered unfit. This user usually doesn't study the bug tracker or the mailing lists, but directly switches to another software.
I can only advise against having the dates for future releases dictated by the date. A release should be made after tasks have been completed and should not contain any open construction sites. It should not be more than four releases a year to avoid pressure to quickly plug holes with the hot needle at the end of the month. If you want to have an update in between, you can build it yourself from the Git.
Yes, there is room for improvement and additional features BUT we got "stuck" with trying to figure out how to do Percentage versus Pixels at this time.
Are you satisfied with that? I played a little more with it. Neither <i>Resize</i> nor <i>Shrink</i> behave as I would expect. The selected areas usually don't match the results.
It Seems good to me. Thanks!
New source code compiled, no more error messages at reformat. But <i>shrink</i> behaves unusual. The selected and displayed dimension does not match the blank.
@PhyllisSmith, the golden ratio (previously referred to as "golden mean").
This grid of four lines (golden sections) is the most common form of the golden ratio in image processing (please do not confuse with the rule of thirds).
Minor update on the GIT checkin and there are builds for MINT 19 and Ubuntu 16 if anyone wants to see them:
Thanks for pointing this error out "Playback3D::copy_from_sync: w=314 not supported because it is not divisible by 4." It has now been fixed AND fixed in 7 other places in the code. It caused an error only if using the OpenGL driver so now using GLx4 operation, we don't have to worry about that any more.
On Pierre's suggestion and Olaf's png -- Wow, that is quite a list so will look at feasibility as it does sound good.
But show me a picture of "golden mean" guidelines because I do not understand. Do you mean reticle lines that cross like projector and camera? Or do you mean guidelines like the Safe Region? I did look up the meaning of "golden ratio" but I can not picture what that would look like.
BTW: the Resize and Shrink options are applicable to all video tracks EXCEPT the disarmed ones. This is nice. As mentioned previously, however, Reformat option applies to all tracks even if disarmed because it changes the Format for the session.
… and I would like guide lines (golden mean), if that doesn't cause too much trouble.
I like that.
crop-aspect.png (89,137 bytes)
crop-aspect.png (89,137 bytes)
Thanks for the improvement of the Crop tool, it has become really flexible and complete.
Playback3D::copy_from_sync: w=314 not supported because it is not divisible by 4.
I created a random crop with dimensions:
Due to this error, the frame is no longer displayed in the composer, I only see black.
PS: +1 for Pierre's suggestion.
Your new crop process in the composer seems very promising to me.
Would it be possible to have an option that would allow, when selecting the cropped image, to automatically have the same frame ration (ex. 16/9) as the one already used in the composer. This is to ensure that the selected image, when enlarged, perfectly fills the frame of the composer's image.
Suggestion: Perhaps by pressing the CTRL key (or another key) when selecting the image, the selection frame automatically becomes the same ratio (ex. 16/9) as that of the composer.
Not Done Yet, but here is part of the Compositor Crop tool new implementation. A demo is at:
Feedback welcome. Yet to come is Reset button, Percent in addition to Pixel, a reference to the newer Crop Plugin for the more traditional Crop usage, and probably disallow negative values for X1, Y1, W, H.
Phyllis/GG, thanks for the build and for the Crop &Position tool.
I didn't know there were an Info text associated with each plugins. Thanks! I learn a new thing every time. Thanks Andrew!
The Crop & Position tool has has the Cinfinity and Cinfinity2 Resource window icon updated to reflect the theme. A ubuntu 16 build is at: https://www.cinelerra-gg.org/download/testing/cinelerra-5.1-ub16-x86_64-static.txz
A Crop & Position plugin as an alternative to cropping in the Compositor. It may be possible to work some of this capability into the Crop Tool of the Compositor also so that there is more than 1 way to do this.
#+BEGIN_QUOTE Phyllis Smith, 20 Oct 2018
The translation was then changed by me (de.po):
The shown solution with camera and projector worked for the forum, but is not a replacement for the cropping tool, because the aspect ratio cannot be changed with it. (Sam certainly knows that.)
The "easiest" solution would be to add a switch to the crop dialog that determines whether only the active layers are cropped or the whole project.
|2019-07-25 20:38||PhyllisSmith||New Issue|
|2019-07-26 08:53||Olaf||Note Added: 0001984|
|2019-09-05 00:53||PhyllisSmith||Note Added: 0002071|
|2019-09-06 14:16||PhyllisSmith||Note Added: 0002081|
|2019-09-07 07:20||IgorBeg||Note Added: 0002082|
|2019-09-22 01:18||PhyllisSmith||Note Added: 0002164|
|2019-09-22 01:18||PhyllisSmith||Assigned To||=> goodguy|
|2019-09-22 01:18||PhyllisSmith||Status||new => assigned|
|2019-09-22 01:18||PhyllisSmith||Status||assigned => feedback|
|2019-09-22 01:46||Pierre||Note Added: 0002165|
|2019-09-22 07:33||Andrea_Paz||Note Added: 0002167|
|2019-09-22 09:59||Olaf||File Added: crop-aspect.png|
|2019-09-22 09:59||Olaf||Note Added: 0002168|
|2019-09-22 10:13||Olaf||Note Added: 0002169|
|2019-09-23 01:43||PhyllisSmith||Note Added: 0002172|
|2019-09-23 01:43||PhyllisSmith||Status||feedback => assigned|
|2019-09-23 01:46||PhyllisSmith||Note Edited: 0002172||View Revisions|
|2019-09-23 11:07||Olaf||Note Added: 0002173|
|2019-09-23 14:22||Olaf||Note Added: 0002174|
|2019-09-25 12:57||IgorBeg||Note Added: 0002180|
|2019-09-28 12:09||Olaf||Note Added: 0002188|
|2019-09-28 17:34||PhyllisSmith||Note Added: 0002190|
|2019-09-29 13:19||Olaf||Note Added: 0002191|
|2019-10-01 23:44||PhyllisSmith||Note Added: 0002203|
|2019-10-02 11:45||Olaf||Note Added: 0002206|