 |
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 https://www.cinelerra-gg.org/news-updates/august-news-ffmpeg-in-use-with-cinelerra-is-now-version-4-2/ and to make the whole thing look nice with a photo, e.g. of the dialogue mask. As an alternative to the external advertising, which is underlined with pictures, to drag users to the CGG side. What is important is that it works out for you and GG and that you can handle it. Points 1-8 speak for themselves. |
 |
@Olaf The reason that IgorB is "satisfied with that?" is because with the new "Crop & Position" plugin he will be using that -- he uses Proxy on Charlie (a slower computer) and needs the percentage capability. It is unlikely he will use the Crop Tool and he was just checking it out because we had created a Ubuntu 16 build for testing. 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" Sometimes we think a task is completed, but then when users start using it, they say can you make it do this, for example the Masking enhancements. The sooner we put it out there, the sooner we can actually complete the task. If we had to wait 3 months for user feedback the task would be dragged out for a long time and we would not only be working on something else by then, but also more startup time is needed to remember details of the code. Quote: "and should not contain any open construction sites" That is definitely a good goal, but I do not believe that the Crop Tool is strictly in construction. It provides a capability that we personally wanted. It does not crash plus it is no worse than what it was previously. Quote: "It should not be more than four releases a year to avoid pressure to quickly plug holes" Four releases a year implies quarterly which is totally meaningless to me since I am not in the financial, budget, or quarterly taxes frame of mind. Look at Heroine Virtual releases -- you can never tell when a new release is available. Since 2010, it varies from August to November and then even January. So users (and me) waste a lot of time looking to see if a new release is available. The pressure would still exist when the quarterly release was scheduled to occur just the same as monthly. Quote: "If you want to have an update in between, you can build it yourself from the Git" Probably 90% of the users are video artists and not computer savvy. They can not build it themselves. We have automated the build process using Xen and it usually only takes babysitting for 8 hours. If instead we had to do individual builds during a 3 month quarterly period as a user requests a test version (which we encourage because we need the testing!) it would take more of our time. Reasons why we do Monthly builds: 1. it is easier for me - I can keep track of the time easily because of the turning of the calendar. 2. it is easier for the users - they can depend on when the release occurs and don't have to keep looking. 3. it is easier for the programmer - many reasons why this is; one being to compartmentalize the work. 4. it is easier for me to track changes - a lot of code is changed monthly and if something comes up that needs a rework, I can find out the timing quickly of the occurrence. 5. there is no team of developers - this is not a production environment where work is dished out accordingly. 6. there is no management - no one is available to keep track of everything so I have to do what I can. 7. there is no work environment - it is not like going to work every day for 8 hours with strict habits. Sometimes the developer has to do other personal things and do some recreation activities. Despite this, generally computer works occupies anywhere from 2 to 12 hours a day to include weekends and during this time, a lot of code gets changed. The monthly release helps mark changes since a lot. 8. there is no QA team - we need testers as soon as possible when working on a specific task. The testing we do involves the programmer testing what he changed and me testing as a really dumb user who does not have a very good understanding. This usually covers a lot, but video artists have different ways of doing things and we need their feedback quickly. |
|
|
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 Resize nor Shrink behave as I would expect. The selected areas usually don't match the results. In addition, Crop does not accept any further selection after the operation, e.g. from Resize to Reformat, without having to fiddle with the Geometries. In addition, the Undo function does not work directly here either. |
 |
It Seems good to me. Thanks! |
|
|
New source code compiled, no more error messages at reformat. But shrink behaves unusual. The selected and displayed dimension does not match the blank. |
|
|
@PhyllisSmith, the golden ratio (previously referred to as "golden mean"). If Gimp is installed, please open it and load or create an image. Select the "Crop Tool" and set the "Golden sections" in "Tool Options" under the menu item "Composition guides". Now select an area in the image with the mouse. The cutting area is displayed and the guides are located in it. On the basis of the axes of this grid "important" elements can be placed, the image structure is then perceived as harmonious. 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). The Golden Ratio… (an introduction): https://vimeo.com/53956272 https://en.wikipedia.org/wiki/Golden_ratio |
|
|
Minor update on the GIT checkin and there are builds for MINT 19 and Ubuntu 16 if anyone wants to see them: https://www.cinelerra-gg.org/download/testing/cinelerra-5.1-mint19-x86_64-static.txz https://www.cinelerra-gg.org/download/testing/cinelerra-5.1-ub16-x86_64-static.txz P.S. IgorB - cropp.png is now in the correct video subdirectory 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. +1 Playback3D::copy_from_sync: … not supported +1 Aspect (see also rudimentary photomontage from CGG/Darktable as suggestion that goes beyond the CTRL key)
crop-aspect.png (89,137 bytes) |
 |
Thanks for the improvement of the Crop tool, it has become really flexible and complete. Only for the original "reformat" option is an old error that was previously resolved returned: Playback3D::copy_from_sync: w=314 not supported because it is not divisible by 4. I created a random crop with dimensions: X1=821; Y1=90 W= 314; H=478 Due to this error, the frame is no longer displayed in the composer, I only see black. "Resize and shrink work well. 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. Pierre |
|
|
Not Done Yet, but here is part of the Compositor Crop tool new implementation. A demo is at: https://streamable.com/rrdgm A ubuntu16 build is at: https://www.cinelerra-gg.org/download/testing/cinelerra-5.1-ub16-x86_64-static.txz Some changes: - Do It button replaced by Apply button for consistency and it does not sound so weird. You have to always hit apply to have the crop tool take affect. - 3 choices of capabilities: 1) Original method = Reformat (or Reformat Session) which crops and changes the Format for the session. It turns out that because the Format is changed, this is the reason it applies to all tracks of the whole project. 2) Resize (or Resize Projector) 3) Shrink (or Resize Projector and Camera). An important note here is that the original aspect ratio will be maintained here so if your frame is rectangular (as many are) and you "crop" by surrounding the region of interest with a square, you will get more than you surrounded to make a rectangle. OK - this just sounds weird, so try it or look at the steamable. - Keyframable 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 > GG looked at this and it is working as programmed, but does not think it > makes sense to change the format like it does. This is the original HV > code. I personally think it is crazy. Do you have recommendations of what > would seem more correct? Meanwhile, changing the translation would be > better. Not sure what the correct words for this would be. gg/Phyllis #+END_QUOTE Message-ID: <CAOckJE0Ba4wPjCc5AqrOPnwgO49+vuB8KCty+-6ZDHB1Lqx2LQ@mail.gmail.com> The translation was then changed by me (de.po): msgstr: "Crop a layer or output (F7). Changes image format and aspect ratio of the project" "msgid" has not been changed yet. 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. |
- Anonymous
