GLOW Fx gives fluttering? We've done this?

Grazie wrote on 5/26/2006, 7:23 AM

Could somebody please remind me of the following.

Glow FX applied to an already great shot - 'cos I shot it! - and I'm getting a kinda of fluttering on the first top 1/4 of the frame region, on a very gentle pan? I've got a "misty" frame around the shot.

Track 1 WHITE solid; Bezier cutout; NEG Mode; feather IN 13.7%; Anti Alias YES and OPACITY 100%

Track 2 Video Event has this GLOW Fx

Again PAL here.

Do I nee to render just this section in Progressive? Render out section BEFORE I apply Glow? What's your solutions here?

TIA

Grazie

Comments

jrazz wrote on 5/26/2006, 7:26 AM
I've got this before- are you watching in on your computer or on a monitor? I find that when I watch it on the square pixel and it is for tv output- I get the jaggies. But, if I watch it on a set top they are gone.

j razz
Grazie wrote on 5/26/2006, 7:30 AM
"But, if I watch it on a set top they are gone." Set top as in CRT TV? I got the reverse then. OK-ish on my LCD, but flutters on my JVC Monitor.

G
farss wrote on 5/26/2006, 7:52 AM
Just a really wild guess here. What de-interlace mode is your project set to, if None try the other Alternatives.
Grazie wrote on 5/26/2006, 7:55 AM

Blend.
Grazie wrote on 5/26/2006, 8:05 AM
Tried all - "NONE" makes No Flutter. Bob?

Anyway a more interesting MOIRE effect is now residing. It looks like the Contours of a map. Very faint . but they are definitely there. Is this glow fx up to it then? It appears as if there is some "phasing" of the graphics to me? However NOT being a super-maths geyser OR programmer . .

G
farss wrote on 5/26/2006, 4:45 PM
This makes sense.

Glow is mdifying the image based on the contents (highlights).
Except we don't have a simple 'image', it's split over two fields, let's call them A and B. Pan the camera and we have temporal separation over A and B. In other words the highlight is a different position in field A and B. Hopefully you're with me so far.


Now when Vegas comes to process the FX it can do it two ways. Merge fields A and B to produce a single frame, process the FX and split the frame back into fileds A and B. Or it can process each field as a single entity. As you've seen the former causes a problem and the latter doesn't.

Here's why.

Merge A and B. Add the glow and split back will add a glow element to B that's derived from field A and add a glow element to field A that's derived from field B. Except we've now got an element (the added glow) in A and B that's spatially offset because it's been derived from the other field. Now if the camera was panning then I can see how things would get nasty. Just assume it was a shot of light bulb.
As the video progresses at the field level the image of the bulb moves from left to right. All fine so far. Now we add our glow with a defined de-interlace method as described above. Now in the A fields glow will be added that's derived from the B fields and vice versa. Visually we have added some glow that goes in the reverse direction (B,A,B,A), viewed on a interlace monitor the image will flicker, badly if there's enough glow being added.

This sounds to me like a pretty serious issue because for some things as we recently have discovered you definately need to set a de-interlace method.

Bob.
Grazie wrote on 5/26/2006, 10:26 PM
Bob? Yes, I did follow your "Grazie-Level" explanation - and for this I truly DO thank you.

However . . . .

"This sounds to me like a pretty serious issue because for some things as we recently have discovered you definately need to set a de-interlace method."

Please explain "recently" in connection WITH the "need" for a deinterlace method being set? Exactly what other issues are you referring to and how WOULD deinterlacing cure this? And I did understand WHAT you said, but I'm now guessing at the point you've made. Sounds good! But please clarify.

For my money, there is a type of "phasing" going on that I would feel should be "crushed" or "smoothed" by a Vegas algorithm. Maybe Glow FX - if any of what we are surmising is valid - should come with a health warning - NOT to use on pans or moving elements? But I must have seen glow used within pans/scans . . haven't I?

Maybe there IS an upper limit to its use? Bit like 100 on the Waveform? Or illegal yellows . . maybe I've, we've stumbled on an UPPER use of Glow?

I have had this before, but put it done to my own clumsiness, and crashed onwards . . ! LOL!

So, Bob, so just HOW serious do you think this is?

TIA,

Grazie
farss wrote on 5/27/2006, 2:08 AM
My point is that it would seem that some things such as event pan/crop need to de-interlace the fields to calculate the new fields whereas others such as your Glow need the opposite.
If I'm right then there's no one shoe fits all setting for the De-Interlace Method in Project Properties.

This setting has also gone from what we believed to be irrelevant to possibly quite critical for some things.

How serious is it:
Well if I'm correct in my assumptions then so long as we understand what's happening we can plan on how to deal with it. Conversely if we don't know what's going on then one might just assume that this is Vegas doing a bad job and that would be unfortunate.
Vegas is very flexible in how it works but more and more I feel that flexibility opens up a lot of traps that one can fall into.

Bob.

Grazie wrote on 5/27/2006, 2:23 AM
Right! Gotcha!

"Vegas is very flexible in how it works but more and more I feel that flexibility opens up a lot of traps that one can fall into."

Again, this is all speculation on our part, but I do start wondering about BETA testing these things. Maybe by the time it reaches the poor mortals that do the BETAs, and descended from Mt Olympus, where the Alpha and programmers reside, casting our fate before them, is it already too late - "The Fleece" has tarnished!

Back to Earth, would you think they are easily - comparative sentiment here, "easy" - to rectified?

Seen my latest on VeloEnvels Bob?

I'm still very much in awe of this software ..

Grazie

jaegersing wrote on 5/27/2006, 2:32 AM
Hi Grazie. I've used Glow on loads of shots, many involving pans and moving camera. So far I haven't come across this sort of probvlem.

So what's different about your case? Seems to me that the

"Track 1 WHITE solid; Bezier cutout; NEG Mode; feather IN 13.7%; Anti Alias YES and OPACITY 100%"

could be part of the problem. Have you tried muting this track to see what happens? Just a quick suggestion from another PALman.

Richard
Grazie wrote on 5/27/2006, 3:03 AM
Quick response Richard, as I need to run, I MUST'VE tested this - maybe? . . . I'll get back at yah . . but will run a test though.



Grazie
farss wrote on 5/27/2006, 3:03 AM
Richard,
I think we've already found the cause of the problem. Grazie made it go away by setting DE-Interlace Method to None, hence our ensuring protracted speculations as to what the full implications of that are.

Grazie,
no I don't think it would be simple to fix, well make goof proof would be a more apt aim. Vegas is I think doing exactly what it should based on what we tell it to do. My beef is that we we weren't told how much WE had to tell it about what we wanted it to do. A bit like the dreaded Ripple Edit. Perfectly logical how that works, just a pity that the logic of it has little bearing on what anyone would want to happen.

But back to your question.

The logic would have to analyse the footage to determine if the source material is I or P, it'd have to know if the output is meant to be I or P and then decide the best way to render the FX based on those two factors. Even then it could come unstuck as one can mix ANYTHING on a Vegas T/L.

Bob.
jaegersing wrote on 5/27/2006, 9:56 AM
Hi Bob. I htought that if the problem is so inherent to interlaced footage, I would have seen it by now because I have used Glow a lot, with all sorts of footage. I thought in this case it would be useful to know if the extra track is contributing to the problem, because that would be one explanation for why not everybody is reporting this problem.

Richard
Grazie wrote on 5/27/2006, 11:02 AM
"I thought in this case it would be useful to know if the extra track is contributing to the problem, . . "

Quite correct .. and no. Muted it, deleted completely, put it back . . did not change the fluttering. I've SOLO-ed the track and still the fluttering is there.


" . . because that would be one explanation for why not everybody is reporting this problem."

Well, I too have Events WITH Glow Fx and NO fluttering. It is just this one event, with a pan . . well . .it ISN'T that!


I can't "Grow" a glow using keyframes. This produces the flutter. Remove the K/Fs that create an INCREASE in the Glow - nice effect, as if going into dreamland - then I get this flutter.

Please try this Richard. I'd reeeeeally like you to dupe this one! Then you could also report it too! LOL!

Seesshhh.....


Grazie
jaegersing wrote on 5/27/2006, 6:13 PM
Hi Grazie. OK, I'll give it a try. What parameters are you keyframing, and over what sort of timeframe?

Richard
jaegersing wrote on 5/27/2006, 8:42 PM
Grazie. I tried it, and managed to find some settings that cause it to flutter, just as you described. It happens without any KF of the Glow parameters, just with these settings: Glow pc 0.667, Intensity 3.2, Suppression 0.3.

My test clip was with a locked down camera (VX2000) looking up at a moving subject that has blue sky as background.

As Bob recommended, setting the project deinterlace to None stops the fluttering, and also found that applying Reduce Interlace Flicker to the clip does it too (but with the usual softening of the image).

Richard
Grazie wrote on 5/27/2006, 10:08 PM

Richard, on re-reading my posts it was I that experimented with the Project settings and returned the +ve for NONE.

Bob "assumed" that I WAS using NONE, hence his:

"Just a really wild guess here. What de-interlace mode is your project set to, if None try the other Alternatives."

Consequently NOT employing a deinterlace method, as you too have discovered, can be successful.

As to one or many altering K/F settings while an Event progresses, my guess is that we are in the realms of the actual content creating the necessary "flutter" effect. Meaning, Richard, you have some media that flutters using just ONE setting. I have media that flutters when I have gradual changing in the FX. If I remove the "other" keyframe that fluttering goes.

This is now positing yet a further issue. That there is a reaction/response being created by Glow FX, and IS repeatable for 2 separate approaches of Glow FX k/f management. Consequently this would point to a yet further and another variable appearing.

Some media - mine - WILL produce flutter on multiple K/Fs while other media - yours - WILL produce flutter on a single K/F.

So, in summary, IMHO, "flutter" can result if:

1/- The Project setting is not "appropriate", and one solution can be NONE!

2/- The actual content of the Event. Completely arbitrary, but potentially THE main culprit, if amongst this set of variables one can have a "main" culprit.

3/- The settings - Percentage, intensity, suppression - of Glow FX can be such that they can result in "flutter". And that single or multiple adjustment of these settings can eradicate this flutter.

Interesting . . . .

And what IS fascinating is that all the 3 can, either singly OR in combination, "conspire" and create what appears AS a deinterlace issue and consequently make one think that the project's deinterlace method has to be altered to compensate - INCLUDING forcing a setting of "NONE"!

Richard, thanks for taking the time to confirm this flutter and establish too that - and I kinda guessed this - it will depend, to some extent, on the media being "Glowed-up" - well, that isn't THAT Earth shattering revelation, but the methods we have stumbled on to maybe finding solutions to the issue are NOT as straightforward as one might have originally expected.

In an environment of variables, the one thing that doesn't change is . . change itself.

Grazie