2x Size, Position & Rotate causes terrible image quaility degradation

Help/How To
1

Hi,

I use Linux and I’ve checked this on two shotcut versions 22.01.30 and 22.10.25. It’s repeatable.

Quite often I prepare videos being some kind of untypical slideshow (png images but I’m trying to add some movements to make them a bit alive, moving, rotating, scaling etc.).

I notice one thing. When I have only one filter Size, Position & Rotate, the image quality is as expected, which means good. However when I add two filters Size, Position & Rotate to one image, it causes terrible image quality degradation (image is terribly soft).

You can ask why adding two filters instead of one.

Let’s imagine the situation I have 30 images. First filter is usually “individual” setting zoom and position quite often different for each image. Sometimes I use also 180 rotation. After that I add usually few filters which are common for all 30 images, ex. increasing contrast, adding saturation, using crop:rectangle etc. If all those filters are the same I just use copy-paste.

And next quite often I want to use some scrolling effect. Usually in x size direction either in y size direction. It’s also common for all images (copy-paste). Usually the image is not rescaled then (100% zoom) but I add only keyframes changing x only position or y only position. And this last step causes terrible image softness. Changing size mode: fit/fill/distort doesn’t seem to have any impact here.

I also noticed one thing related to that. Despite I set position 0:0 and size 1920x1080 and zoom 100% quite often shotcut changes the parameters after saving them (moving to another keyframe point). Thus ex. instead of 0:0 I have -1:0 and instead of 1920x1080 I have ex. 1918x1081 or sth similar. Not sure why shotcut adds those modification by itself. Thus in practice it causes some second rescaling. It might be the reason of this image softness.

Thus I’m not sure if as error we should treat this quality degradation itself, or we should treat not keeping 0:0 and 1920x1080 parameters with 100% zoom. Whatever is wrong here, in my humble opinion it should be considered as area to improve. And when keeping 100% zoom, does shotcut still do any scaling?

P.S. x moving can be easily replaced with 360:Transform filter and with using Yaw parameters, and this is not causing quality degradation, but how to replace y moving?

2

I tried to reproduce your problem on Windows, but I didn’t see any image degradation after adding the last SP&R filter.

Here’s a capture of what I did:

For Linux users to test the problem, maybe you could upload a project here (use only one photo) where you experience the quality degradation.

3

Ok I will do this having a bit of time.

In the meantime do you know how to replace size, position and rotate with a different filter for y scrolling (top-bttm)?

4

Ok, I prepared this example. Please have a look:

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.

5

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.

6

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).

not_sharp2.mlt (7.5 KB)

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.

7

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.

8

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.

1 Like
9

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.

10

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.

Et en plus je parle français aussi :stuck_out_tongue:

11

I would file a stripped down example as a bug.

not_sharp_test_case.mlt (4.5 KB)

12

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.

13

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?

14

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.

15

Aren’t you on a Mac? If so, that would be the reason & hence why I think this might be a bug on Linux :wink:

Vous n’êtes pas sur un Mac ? Si c’est le cas, ce serait la raison pour laquelle je pense qu’il s’agit d’un bug sur Linux :wink :

16

Not a bug. It is what it is, and you have to deal with it. The output of the first filter is the input of the second.

17

@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?

18

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.

19

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.

Thanks for trying to help. :slight_smile:

20

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.

1 Like