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:
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 but it serves its purpose of demonstration):
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”):
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.
@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!
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…
Chroma key if the original video does not have an alpha channel
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 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…
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.
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.
but it serves its purpose of demonstration):
Just shows how a erroneous pesky 0 or 1 can cause problems!