I found a bug - not a software bug, but I noticed that when I apply a “Clock Top” transition to 2 clips, the result is not linear - ie there is a definite speeding up of the effect in quadrants 2 and 4.
I made this short demo to show this :
I downloaded the “Clock Linear” LUMA PGM file from the Kdenlive store site (I converted it to a JPG file) and tried it as a custom transition and it was indeed linear. See Transition 2 in the demo.
I’m presuming the Shotcut preset uses a Luma file hidden somewhere under the hood but clearly it does not give a completely smooth result. Would it be possible to change the Luma file within SC to this one, I wonder?
Just to make it a bit clearer, here’s another demo, each transition alternating between the standard Clock Top transition and the custom transitions, using the Clock-linear Luma file…
Guess which one I started with? …
Pour moi, votre masque n’a pas le défaut du fichier d’origine de SC mentionné par @jonray, et il a en plus l’avantage de pouvoir faire varier l’angle de départ.
For me, your mask does not have the defect of the original SC file mentioned by @jonray, and it has the added advantage of being able to vary the starting angle.
Yep, indeed, works fine. In fact the generated file and the Clock-linear Luma file are exactly the same. And as @namna says, it is superb to be able to vary the starting angle. It just gets better!
I’m not sure if it is an artifact or a defect, but I see faint white lines (like magnetic lines) radiating out from the centre of the image.
Je ne sais pas s’il s’agit d’un artefact ou d’un défaut, mais je vois de faibles lignes blanches (comme des lignes magnétiques) rayonnant du centre de l’image.
I don’t think there is a problem with the code. The problem is in the luma*.pgm file that was used. I have found a luma1.pgm file in the mlt/master/demo directory. It is the “Clock Top” transition file and has exactly the same problem when I use it as a “custom” preset in a transition. The gradient is not smooth in this PGM file and that is the cause of the problem.
Obviously this is not the exact PGM file used to create the transition preset (I cannot find such a file anywhere in the ZIP I downloaded from Github) but it has exactly the same gradient problem.
The transition code redirects the property for a file name that ends with .pgm and does not exist to this code. It does it this way for compatibility because MLT used to generate these files in a few different aspect ratios and resolutions at build time. Now, they are generated upon demand using this code per the project aspect ratio and resolution.
case 3:
{
int length;
for ( j = -half_h; j < half_h; j ++ )
{
if ( j < 0 )
{
for ( k = - half_w; k < half_w; k ++ )
{
length = sqrti( k * k + j * j );
*p ++ = ( max / 4 * k ) / ( length + 1 );
}
}
else
{
for ( k = half_w; k > - half_w; k -- )
{
length = sqrti( k * k + j * j );
*p ++ = ( max / 2 ) + ( max / 4 * k ) / ( length + 1 );
}
}
}
}
break;
Line
*p ++ = ( max / 4 * k ) / ( length + 1 );
can be rewritten as
*p ++ = ( max / 4) * (k / ( length + 1 ));
The term: k / ( length + 1 ) is effectively the Sine of the angle subtended from the pixel to the baseline (the + 1 is to prevent division by zero). This means that the conic gradient is based on the Sine function, which is non-linear.
You need to take the Arcsine that will give you the angle and base the gradient on that. However, the code seems to be designed for speed and taking the Arcsine at every pixel will slow it down considerably. So I think it best to leave it as it is and if someone wants a conic gradient with a linear speed of transition they need to provide the relevant PNG file, such as can be produced by my HTML code here: Greyscale Luminosity Masks.
Thanks for your comment, but I think Dan is the genius: he even implemented an integer square-root based on the Newton-Raphson approximation method for this transition. How cool is that?
Admittedly this conic-gradient isn’t perfect, but people have been using it for years without any comment, until your eagle-eyes noted the “defect”. Personally, I would leave the code as it is, after all people who already use this in their projects may be a bit concerned if they come back to the project and see their transitions acting (slightly) differently and then file a bug report.
I would close this “bug” as it is really a “feature”.
Linear, Radial and Conic gradients are now fully built into CSS. However, if you want to use them in an HTML canvas it is less easy. A very useful description of how to accomplish this is given here:
Fair point. But sometimes a linear movement would be essential. The reason I found it was when I was trying to show @ertan and others that you can easily make an animated circle to highlight a section of a video. In this use-case, a linear effect is definitely required. See my demo:
