Jonray's Diagonal Swipe Transition made into a Filter

A few weeks ago Jonray posted an article about a new “diagonal swipe transition” he had made using an Overlay HTML (Text: HTML) filter.

It generated a lot of interest and several members suggested ways of improving the feature. So in collaboration with Jonray I have taken it a stage further and turned it into a proper filter, parameterising such things as the angle of the swipe, its direction (from the top, right, bottom or left), the colours of the stripes etc.

It is now much easier to use and does not require separate black and white video mattes. If you would like to use it, it is available in ZIP format (along with a description and documentation) from my website at:

http://www.elusien.co.uk/shotcut/filters/JRtransition/index.html

3 Likes

Hi folks, yes, @elusien has done a great job with this filter and I highly recommend you give it a try!

(I’ve been doing a bit of beta-testing for him)!

Full instructions on elusiens website - see the link in the previous post…

I hope to make a very short tutorial showing how to use this filter in the near future, when I can grab a bit of time to do so.

I just made a quick demo video showing @elusien’s new JR transition filter applied to a series of video clips. Note - some colours I chose for the diagonal wipe bars were not particularly tasteful :yum: but it serves its purpose of demonstration):

https://streamable.com/u9dny

Note to @elusien - I am getting occasional “glitches” when using the timeline layout you suggest on your webpage - ie:

… but I think I may have found a solution - to lay out the timeline like this - apply the filters WITHOUT selecting “reverse” :

(Here’s a screenshot of my actual timeline):

Another tip : I put a colour clip on V3 and hid the track to act as a template so I knew where to split the clips for an even length of transition.

1 Like

I have updated the webpage to contain this information. I still haven’t managed to reproduce the problem with my tests.

Fantastic, thank you. I’ll try to do another quick test today with the original method and see if I still get the glitch.

Nice work guys, will be giving it a test drive.

Interesting - I just did a test and as you can see there are 2 glitches, appearing at the beginning of transitions #2 and #4 (both of which are set to “reverse”). Transitions #1 and #3 seem to work perfectly (of course these are not set to “reverse”):

https://streamable.com/v2o46

So then I made a screen capture of my SC project, advancing frame by frame. A full frame of the clip on V2 seems to be added momentarily, creating the glitch.


https://streamable.com/u4b26

@elusien - how odd that it’s not happening to you. I’m using “alt+right arrow” to locate the split points, then splitting with S (or O (outpoint) when appropriate), so I’d have thought the clips are being cut at precisely the correct positions.

Not sure whether it’s a “Shotcut thing” or something to do with the JR transition itself.

Thanks, would love to see any demos you come up with!

(Only if you have the time/inclination of course - no pressure from me!) :smiley:

What is the minimum version of SC needed?
I’m using 19.04 on this mac and all it does is create a white frame which obscures the video.

Hi @paul2, did you follow the instructions for SC versions previous to 19.06 on elusien’s website here?

I’m using 19.06.15.

Wow, those are a lot of steps in total.
The filter does give more flexibility but using a pre-made wipe is a lot simpler.

First video clip on V1
Second video clip on V2
Transition on V3

I’ve looked more closely at this and have managed to see the glitch in the “preview” window, but only the first time it goes through the split. Every time after that the glitch does not appear until you reload the MLT file and it happens again, but only the first time through the split.

I have a good idea why it’s happening (it is in the javascript code) and will try to fix it. I might not have time today (taking neighbours to the airport), but hopefully I’ll have a fix by tomorrow night.

Well, yes, @paul2 - it does look a bit complex and daunting!
However, in its defence the process looks a more complex process on paper than it actually is in practice, and for me it is worth the effort to achieve the desired effect and for the flexibility of angle-colour/speed etc.

Plus, my wipe design has a complication in that clip1 has to be gradually replaced by clip 2 as the diagonal line passes through, which is hard to achieve with a pre-made transition.

I do like your transition especially the green/red wipe in your demo 1. How does that work (is it a green screen mp4?), and did you make it yourself?

@elusien, great, you are darned clever!! (I have no idea how you got this filter to work and I am in awe of your programming skills!!) Thank you, no rush from me…

There are actually two ways to do it:

  1. Chroma key if the original video does not have an alpha channel
  2. If the video was exported as an Apple Animation in a mov then it supports alpha.

That specific transition I did not make.
The editors use Ross Expression to make their own transitions.
It’s a commercial package but there are other open source alternatives like Synfig ans Pencil 2D
which although aimed more at cartoons/animation, they can be used to make transistions.
In Pencil 2D, just use the “Camera Layer” to move things like diagonals around.

Neither Synfig nor Pencil 2D support exporting to Apple Animation, but you can export to png, bring it into SC and from there export with alpha in a mov then bring it back and use as a transition.
Or of course just use a chroma key.
Bit more of a hassle than Xpression but soooooo much cheaper.

Just back from Paphos Airport. On the 1-hour trip in the dark I got to thinking about the problem and fixed it as soon as I got home. It had to do with the opacity setting for the Chroma div at time 0.0 when the “reverse” option is specified. It was set to zero for the very first frame of such clips, so the 1st frame displayed was that on V1, not V2!

I have updated the ZIP file on the webpage, but if you want to edit the index.html file itself you can. The “if” clause at line 163 should read:

if (params.chroma || params.mask) {
	html.chroma.style.display = 'block';
	html.chroma.style.opacity = 1;	// Needed to stop a "glitch" when the "reverse" option is specified.
	for (i =0; i < 4; i++) { html[divs[i]].style.display = 'none'; }
} else {
	html.chroma.style.display = 'none';
	html.chroma.style.opacity = 0;
	for (i =0; i < 4; i++) { html[divs[i]].style.display = 'block'; }
}

Brilliant! Thank you for your detective work :smile: Just shows how a erroneous pesky 0 or 1 can cause problems!
New zip downloaded, will give it a test run if I can grab time later.

Hi @paul2, thank you so much for this information. I’ll definitely look into it. And the transition in your demo #1 has given me a few creative ides - watch this space…:smile:

Hi @elusien, sorry to report this but I’m still getting glitches, even with the new revised JRtransition file.

See this demo:

https://streamable.com/38cu3

This time the glitch appears as a full frame of the clip on V1 when the filter is applied to V2 without “reverse”- ie the other way round to the earlier problem. So there are 2 glitches in the above demo, at transitions #1 and #3.

My timeline is as follows:

Can you replicate this?

Mea Culpa,

I only tested the other transition (“reverse chroma”). The fix did in fact introduce the problem you are seeing. Thanks for spotting it and letting me know.

THE FIX is to change line 165 to say:

if (params.reverse) { html.chroma.style.opacity = 1; }	// Needed to stop a "glitch" when the "reverse" option is specified.

i.e. only set the opacity to 1 if you have the “reverse” option specified.

I have updated the ZIP file on the website.

Hey hey hey - it now works like a dream!! Thanks @elusien! :smile::smile:

https://streamable.com/avi4n