Enabling this second Size, position and rotate filter makes the image being terribly unsharp. I also attached two exported frames to show the problem.
There is also one thing more here. I’m not able to set the parameters of the second filter to be neutral. Despite it’s 100% and despite selecting size mode fit/fill/distort I’m not able to set it to not to change image size.
It’s also depended on the input photo. As sometimes there is no change of image size (or very minor, not noticable, taking into consideration what I’ve written earlier) but still image become terribly soft.
The photo file is not mine as it comes from unsplash.
I also noticed one thing more. If input image is 16:9 format exactly (which means the format of my project). Then the second size, position and rotate is not causing any softness. However if there is even a small difference in format, this softness is visible. It might be somehow related to the fact, that then there is always smaller or bigger rescaling and setting the zoom to 100% is not in practice 100% but there is still some zooming. In the given example project this difference from 16:9 format is significant, however in my previous attempts it was just few pixels, enough still to make this softness.
Thus perhaps I should rather name this bug as: “When format of image is different than project format, it’s not possible to set Size, Position & Rotate filter to be neutral (and keep 100% image size”.
Sorry for bad naming, but I needed to make some more experiments to discover this.
If the original image does not have exactly the same ratio as the project it will be distorted by any ‘Size, Position & Rotation’ filter that is placed behind it.
I can confirm this behaviour on Xubuntu 18.04 (haven’t checked Arch yet since that doesn’t seem necessary).
In this the case the original image is 4424px wide so an SPR smaller than that will not, or should not, result in significant blur or softness. It is the order in which the SPR filters are interacting. I don’t know why, but if you move the lower SPR above the first, then the problem goes away. Attached is an mlt, without sharpening, and the image appears to be identical in quality to when viewed in an image editor.
The key takeaway seems to be this: the last SPR needs to be the one where you are resizing up to approximately the full size of the image (in this case 250%), and the first SPR is the one set to 100% (it’s actually 99.9 based on rounding).
Of course, that changed the location of the image slightly so you will need to readjust some values for perfect image placement but that is the solution.
Yeah that’s obvious but here in the case I list as bug this quality degradation is much more than expected from normal rescaling. Why using only one Size… filter doesn’t cause the image to be terribly soft, and using two makes terrible quality loss…
Moreover even if the image has the same ratio, there will be quality loss due to rescalling. The issue is not that this loss exist but that it’s much higher than expected.
Mettez d’abord un Crop: Source et ensuite un SPR. Vous n’aurez pas besoin de mettre un second SPR. Ensuite, mettez tous les filtres nécessaires à la correction de l’image.
First put a Crop: Source and then an SPR. You will not need to put a second SPR.
Then put in all the filters needed to correct the image.
That might be the solution if we are working on the single image. In practice we don’t need then even two filters, as everything can be converted to one. However the issue is if we want to spread the same pattern (=the same filters) through many images, ex. 30. Then this first Size… filter is for preparing the image for next processing which is the same for all 30 images. Here your solution with changing the order will not work. It will not neither work when doing some crop. And neither when doing scrolling. (please note that my example is simplified, in “real life” I’m doing much more here)
I’m wondering what it might be the reason of this problem. When trying to guess I would say:
Size, Position and Rotate filter takes some parameters from output of the previous filter (which is expected) but some parameters it might take from the image (png or jpg file) and not from the output (as it should be) and that might cause this strange behaviour… Either the second possible reason, when setting 100% zoom (which should mean no scaling at all), scaling is still done and that causes this quality degradation). But it’s just guessing…
Edit: When thinking more, I have doubts if always we can convert two SPR filters into one when having crop: rectangle between them and using one SPR filter for y scrolling (or x). Probably not.
Yeah I know that in case of single image you can easily do that. But please read my case exactly. When doing this on 30 images, it’s not so easy to combine filters and it requires a lot of work and having two is much easier.
I understand what you are saying, but there are definitely circumstances where a bottom SPR is used for dragging an image or text (for positioning purposes) after many other filters have been applied below a top level SPR.
With respect to images, there is something going on here and I do think it is a bug.
Je comprends ce que vous dites, mais il y a certainement des circonstances où un SPR inférieur est utilisé pour faire glisser une image ou un texte (à des fins de positionnement) après que de nombreux autres filtres ont été appliqués sous un SPR de niveau supérieur.
En ce qui concerne les images, il y a définitivement quelque chose qui se passe ici et je pense que c’est un bug.
I’m wondering if as some kind of simple workaround extending 360:Transform filter to have y scrolling would be an option? There is already x scrolling within this filter. This would also enrich possibilities given by this filter. Do you think I could add this as suggestion?
Je ne saurais pas vous expliquer pourquoi, cela dépasse mes compétences, mais chez moi si je commence par un Crop Source (pour les clips dont le ratio est différent de celui du projet) je peux ensuite mettre 1 ou 2 filtres SPR sans déformation de l’image.
I can’t explain why, it’s beyond my skills, but in my case if I start with a Crop Source (for clips with a different ratio than the project) I can then put 1 or 2 SPR filters without distorting the image.
@shotcut, Could you explain me then why SPR with 100% zoom (thus neutral, not changing anything with scaling) and used only for y scrolling, causes such quality degradation? Shouldn’t be like that if zoom==100% then no scalling is done? And why when setting 100% as zoom, sometimes it’s not possible to set position and size as 0:0 1920:1080? but there is one or two more or less as values?
With more than one of that filter, that is a side effect of a bug fix for a bug fix. For more details you need to see the git log and read the source. If you want to fix it then you need find someone else, and it will probably need to be a new, separate filter to not change behavior of existing projects.
You can file a separate bug for the UI unexpectedly changing parameter values, but please provide steps.
Another option is to make some kind of filter making x and y scrolling without any resizing (something similar to NoSync or 360:Transform/Yaw but without “image loop”).
However if you admit that it’s a bug, even difficult to solve, not sure why you moved this to "how to"section… instead of keeping this as “bug”… (even opened if it’s too tricky/risky to do that).
Some time ago I even looked a bit into source code, but the cost of entering seems to be too high for me. There is no technical documentation and commenting is very very limited. Thus it’s rather the code itself which is documentation but then it means a new guy need spend a lot of time for learning how it works. For you it’s probably quite “normal thing” as you involved since ages but for a new guy it’s not so easy…
Concerning UI changing parameters values, I will prepare a separate bug when having a bit of time.
I’m also a Developer from “back in the day” when programs were written like this. I have done lots of systems in the same way. So I concur with the viewpoint but not in any negative way as i feel like a fantastic effort has been done getting the system this far.
I don’t know if there are any ‘tests’ or TDD in the code. But in rendering-software typically there does come a point where if the complexity rises, TDD becomes essential.
That way, you can run tests retrospectively and minimise the chances of breaking old code with new bug fixes.
In the big companies that I have worked with, they paid Contractors bucket-loads of cash to come in and add TDD to Legacy systems. The results were good so it can work.
My opinion is that SC needs a new Render-Engine for next year with an option for Users to donate to it’s coding via low-cost contributions. This is how most of the other successful OpenSource products work.
Size, Position & Rotate effects are all best done on the GPU, in my opinion though this might not be how it’s done in the current implementation.
I think in the following way sharing your approach. Up to some point the software can be developed in spontaneous way. However when the project is growing, it’s time to discuss what and how should be modified. In this case it would mean (at least in my humble opinion), how to invite new people to this project to have bigger team and how to reduce number of bugs (including TDD mentioned by you). Moreover I’m also wondering about performance during editing. Some operations are surprisingly slow like moving one clip from one track to another in bigger project but doing copy-paste being the equivalent of moving is almost immediate. Please don’t try this as negative approach but rather as some kind of help even if it’s probably much easier to talk than to do sth. However this become somehow off-topic and I think for this a new thread should be created, if there is interest.
