Drop to 99% level removes Interlace wobble?

Grazie wrote on 3/29/2006, 7:31 PM
Y'know when you get that "wobbling" from interlace, when you preview and PAUSE, well I noticed that dropping the level by 1% it goes. Why is this and what exactly is happening? In doing this, am I just seeing ONE field? Dropping level by 1% I get to see only one field? Is it because I'm entering a re-sampling stage, via forcing a level change, that Vegas is wanting to now render out and create a "new" interlace?

Very curious . . . and not a little confused too.

TIA,

Grazie

Comments

Liam_Vegas wrote on 3/29/2006, 7:50 PM
Just a guess.. that by changing the composite level the frames are actually being converted to progressive - and the interlace issue goes away.
Grazie wrote on 3/29/2006, 8:02 PM
Thanks Liam.

Why? Is this for Previewing requirements? Blasphemous as it may sound, is this a function that I could employ? 1% ain't that much?

In any event is this what actually happens anyway? I do "something" and I get into Prog mode? Is this a known result?

Cheers Liam . . .

Grazie

Liam_Vegas wrote on 3/29/2006, 8:28 PM
I think it is just the way it works.

I found a while ago that if you apply the widescreen preset using pan/crop that the video frames became "softer". Upon checking things out I found out that many of the FX"s that you apply actually forces a conversion to progressive (de-interlacing) for those clips.

It surprised the heck out of me - I had no idea this was going on.

I found a work-around for my particular need - and that was to overlay letterbox bars over the top of your video track. I got the same end-result (letterbox) but without the de-interlacing and softening of my video.

I'm not actually certain that your footage is being de-interlaced in your case... but it does sound mighty similar.
Grazie wrote on 3/29/2006, 9:06 PM
So . .. has it been your experience, that on final rendering, you get-back the interlace? - Interesting.

Grazie
Liam_Vegas wrote on 3/29/2006, 9:12 PM
The final render will be interlaced... but that does not alter the fact that each frame was being de-interlaced (and made softer) prior to it converting it back to interlaced frames. So.. yes... in my example.. the actual final render was degraded by applying the pan/crop preset. I'm now very careful to check this stuff out.

Here is a link to my prior post about this issue
farss wrote on 3/29/2006, 9:49 PM
We could all spend a LOT of time experimenting with this and still draw the wrong conclusions.
Isn't these sort of issues that should be in the documentation?
You remember, the stuff we paid good money for. If we end up producing less than optimal results because someone thought explaining how their software works so we can use it to the best of it's capabilities was giving away some trade secret then it's a pretty sad day.
In the end and probably in many ways wrongly, products like Vegas get judged by the quality of what its users produce and the hard working codesmiths shouting "they didn't know how to use it" rings even hollower if they didn't bother to explain HOW it works. It'd be even nicer if they told us how to get the job done in the best possible way but I'll happily spend a few hours reading and making deductions if I have all the information is in front of me. Having to almost reverse engineer the code is just too bigger an ask and also way too easy a way to draw the wrong conclusions.

Bob.
Grazie wrote on 3/29/2006, 9:51 PM
Thanks for the link. Yes Liam, I did read your thread, and NOW it makes more sense - funny that until I've come across a related issue stuff just flies over - Am I the only one with which this happens to? Nah, guess I aint.

Of course your - " . . but that does not alter the fact that each frame was being de-interlaced (and made softer) . . " - goes to the nub, editng-decision of this issue and that IS about making edit decisions. "Oh look boyz, I got a softer image here?!? I'll better sharpen it!" WRONG!!"

So what DO you do now Liam?

Cheers,

Grazie

Grazie wrote on 3/29/2006, 10:00 PM
Wow, Bob! Do my wrists ever sting now! . .

Just got back after replying to Liam's help - . . seesshh I was seeing something that might/IS impinging on what I do to make an edit decision. I am no programmer. And please don't conclude that as I'm asking - and in my terms a "low-radar" issue - that I wish to re-write code, manuals or count angles on pin-heads - Bob?

Regards,

Grazie

Serena wrote on 3/29/2006, 10:54 PM
Agree heartily with Bob. These sort of issues get raised fairly often and very seldom do we know positively what's going on in the software. Our imperial observations about how things look leave us (or me, at any rate) with a sort of Ptolemic model of how it all works; we sort of know how it turns out but can't explain it.
Grazie wrote on 3/29/2006, 10:55 PM
Well, on further delving, it is the way I have the Preview setup - Preview was PREVIEW AUTO. I tried 99.9% and the wobble went. I then opened the Preview window to its full size and the wobble returned.

This also holds true for using Pan/Crop, Liam. Use P/C Widescreen and the wobble goes. Expand the Preview Window to its full size and the wobble returns.

So in both instances - Levels or P/C - the deinterlace happens when the Preview: Preview(Auto) window is small. When expanded the "interlace" wobble returns.

Curious . .

Grazie
farss wrote on 3/29/2006, 10:56 PM
Grazie,
try as I hard as I might rereading what I said I cannot see how you would conclude that I was suggesting that YOU rewrite or do anything. quite the contrary.

You shouldn't even have to ask these questions and nor should Liam. Or at the very least you might and someone might reply RTFM!
Or you might go off and RTFM and then ask someone to explain what all that technobabble means or if you've misunderstood it.
But when there's no technobabble in the manual and we're all sort of guessing or experimenting to try and give you the correct answer it's all a bit frustrating.

Take what Liam has discovered, if correct it contradicts what the documentation seems to imply, namely that unless you're de-interlacing the setting has no effect. Well now I think about it some FXs might need a de-interlaced frame to work with, so how an FX renders will be affected by that setting. All fine and dandy BUT the manual doesn't state that nor do we know which FXs are affected, are some better with it set one way etc.

I've spent a LOT of time discovering how to fix many issues with that "reduce interlace flicker" switch. I'm still only guessing as to why that works, for all I know I could be doing the wrong thing but until I know what precisely it does how can I determine that? Am I giving good advice when I suggest others use what I've found?

So please Grazie, understand I'm not having a shot at you, I'm having a rant on your behalf.

Bob.
Grazie wrote on 3/29/2006, 11:03 PM
Serena, I guess so. And I too can live with a pragmatic view, no problems there, at all.

So what do I do when I see something happen, for the first time - and I aint no programmer? What I do is I ask. Firstly, if this is what "others" are seeing/getting and as a result, secondly, I can go away and get on with the job of editing.

Grazie
Grazie wrote on 3/29/2006, 11:10 PM
Bob! I apologise . . unreservedly. I read your paragraph where you said we could spend hours, but I did not get your salient point about "I'm having a rant on your behalf" - I confused myself! LOL!

Hey Guy, you've most likely forgotten MORE than I'll EVER learn - promise!

Fancy a Tinnie? A Cold One?

G . .. ..
Serena wrote on 3/30/2006, 1:50 AM
Grazie, I wasn't really supporting being satisfied with the pragmatic view of "it works, so why understand it" ( I should be more careful in my expression). It's understanding that allows us to adopt efficient workflows, and it's lack of detailed understanding that leads to confusion (such as in the questions I ask). Bob's point, if I understood it, is that unless the software is completely arcane then all its behaviour should have been designed and documented. While we probably don't want to read all that, we might expect that a designated authority would provide definative answers to specific questions; a sort of Galileo (since previously I alluded to the Ptolemic Earth centred astronomical system, possibly rather arcane in the present context!).
farss wrote on 3/30/2006, 2:45 AM
Well even if its behaviour wasn't specifically designed hopefully with the knowledge of how it works we could easier deduce why something goes the way it does.
Take another example, Vegas works in RGB unlike many other NLEs. When i first learned of that I thought great and I still do because to me YUV is a fudge, a very clever one but I'm always laery of fudges. Since then I've come to learn that things can go wrong converting between YUV->RGB->YUV. So someone comes along here with a problem with say color banding and we can go "Ah, this might be the problem and this might be how to avoid it".
Now without that initial piece of knowledge that Vegas works in RGB we'd just be guessing, we might conclude (wrongly) that Vegas was just plain doing a bad job.

Sorry if I'm being a bit uppity, just in the middle of this VERY frustrating audio job. Client says apart from adding stingers at the end of every track the producers feels the levels are a bit off. That'd have to be the understatment of the decade, this is talkback radio, every third word can be 10dB different and the only way I can see to fix it is manually with lots and lots of nodes and a bit of compression to hold it all together. Oh and they want it yesterday. And there's nearly 3 hours of the stuff!

Bob.
FrigidNDEditing wrote on 3/30/2006, 3:31 AM
Let's hear it for the all nighter - WOOT WOOT!!!

just did a similar thing with some DVD intros for a client - their other guy wasn't able to do it in time and they needed it monday - so I went solid on it - and had em done by wed. morning - had to get a lot of stuff settled out before I was able to really roll on em, once I did though - it was right simple.

Course it was my first experience with HDV and m2t files - man am I jonzin for a new machine now - good grief, fortunately my final output was SD. took long enough though. Each render ran about 20 min for 11 seconds - had chroma keying - 3D video placement, and nested projects - so yea - good times :)

But I learned a lot, and I really like the final turned out product (more or less, I mean we can always rip at our stuff till the end of time, but you just have to lay it down for the deadline, ya know).

Dave
farss wrote on 3/30/2006, 4:29 AM
Actually I don't really mind the ones that are a bit of a technical challenge, those ones go under "what doesn't kill you makes you stronger" kind of stuff. You get up the next morning and feel great even if no richer.
This one'll make me a bit richer but no wiser.

Now back to work Bob!