[Gleb Rysanov]

Hello Emmanuele,

It’s hard to say what’s wrong with your setup — the texts of the expressions have been tested and worked well, if applied properly. Judging by the text of the error, there must be a missing bracket somewhere in the layer’s expressions.
Make sure you’ve rigged your character properly and applied expressions to respective pin points positions (not layer position).

Hope this will help!

[Gleb Rysanov]

I’m obviously not Dan, but I do feel grateful to him for all the knowledge he shares. Maybe it’s time to pay a tiny bit back to the community he represents. I recently worked on a character animation project and found it quite tortureous to animate puppet tool limbs manually. so, a friend of mine has written these expressions and granted authorization to post them here. the idea is to animate rotation and bending of a limb through manual animation of one single puppet pin only (wrist/foot). the elbow/knee shall be making natural movements being parented to the wrist/foot through expression. the shoulder/hip shall stay in place, serving as rotation axis.

1. expression for the wrist/foot (for a 3-point limb like leg or arm):

// Character Animation — Puppet Tool Inverse Kinematic:
// simulating a three-joint (puppet pins) limb movement
// through one single joint animation.
// This expression is for Puppet Pin 3 (wrist or foot)
if (time < 0) { B = value; } else { A = effect("Puppet").arap.mesh("Mesh 1").deform("Puppet Pin 1").position.valueAtTime(-1); B = effect("Puppet").arap.mesh("Mesh 1").deform("Puppet Pin 3").position.valueAtTime(-1); C = effect("Puppet").arap.mesh("Mesh 1").deform("Puppet Pin 2").position.valueAtTime(-1); BC = thisComp.layer("Bending Controller").transform.position; T = thisComp.layer("Puppet Controller").transform.position; R1 = length(A, C); R2 = length(B, C) A = effect("Puppet").arap.mesh("Mesh 1").deform("Puppet Pin 1").position; d = length(A, T); if (d > R1 + R2) {
B = add(A, mul(sub(T, A), (R1+R2)/d));
}
else {
B = T;
}
}
B

2. expression for the elbow/knee (for a 3-point limb like leg or arm):
// Character Animation — Puppet Tool Inverse Kinematic:
// simulating a three-joint (puppet pins) limb organic movement
// through one single puppet pin animation.
// This expression is for Puppet Pin 2 (elbow)
if (time < 0) { C = value; } else { A = effect("Puppet").arap.mesh("Mesh 1").deform("Puppet Pin 1").position.valueAtTime(-1); B = effect("Puppet").arap.mesh("Mesh 1").deform("Puppet Pin 3").position.valueAtTime(-1); C = effect("Puppet").arap.mesh("Mesh 1").deform("Puppet Pin 2").position.valueAtTime(-1); BC = thisComp.layer("Bending Controller").transform.position; T = thisComp.layer("Puppet Controller").transform.position; R1 = length(A, C); R2 = length(B, C) A = effect("Puppet").arap.mesh("Mesh 1").deform("Puppet Pin 1").position; d = length(A, T); if (d > R1 + R2) {
C = add(A, mul(sub(T, A), R1/d));
}
else if (d < 1.0) { C = add(A, mul(sub(BC, A), R1/length(BC, A))); } else { B = T; a = ((R1 * R1 - R2 * R2 + d * d) / (2 * d)); h = Math.sqrt(R1 * R1 - a * a); D = add(A, mul(sub(B, A), a/d)); C1 = [D[0] + h * (B[1] - A[1]) / d, D[1] - h * (B[0] - A[0]) / d]; C2 = [D[0] - h * (B[1] - A[1]) / d, D[1] + h * (B[0] - A[0]) / d]; try { S1 = length(C1, BC); S2 = length(C2, BC); if (S1 < S2) { C = C1; } else { C = C2; } } catch(e) { C = add(A, mul(sub(BC, A), R1/length(BC, A))); } } } C To get these running, you'll obviously need to apply the Puppet Tool to your character's limb so that the Puppet Pin's numbers are as follows: (1) shoulder/hip, (2) elbow/knee and (3) wrist/foot. You'll have to create two Null Objects and name them "Puppet Controller" and "Bending Controller." Puppet Pin 3 is parented to the first one through expression and the whole animation should be done through this Null. The second one determines direction of the limb bending, depending on this Null position respective to imaginary line between Pins 1 and 3. And, finally, to move or rotate the limb as a whole it's advisable to nest your limb comp into new one, where you can safely manipulate by the limb comp as a layer without ruining your puppet animation. I personally prefer to parent the "Puppet Controller" to another Null in a parent composition so I can have access to any kind of animation from one single place. That's it -- helped my a lot. By the way, the author of these expressions is a freelancer programmer Anatoliy Moskovsky (avm@sqlbatch.com), so feel free to contact him shopuld you feel like it's time to let expressions do all the hard work for you 😉

[Gleb Rysanov]

Chris,

Thanks for the reply.

>…and is a unit that complies to broadcast spec and enables
> fire wire DV streams to be converted to full SMPTE ITU-R
> BT.601 (old YUV) spec for recording to VTRs that have YUV
> inputs.

Perhaps, this is that very stage in your workflow where video signal is being clipped to broadcast safe gamut cutting thereby all ‘illegal’ colors?

> In the strict sense of the word YUV should be expressed as
> YCbCr as it is the ITU-R BT.601 world wide standard for
> digital component video.

The most correct abbreviation technically would be Y’CbCr, I guess, as the signal is gamma-corrected. But that doesn’t really matter in the context of this discussion.

> PAL YUV 4:2:0, DV or DVD, is restricted to the 16-235
> levels not 0-255…

Why is that? Most DV camcorders output YUV 16-255 levels, don’t they? Anyway, there is no way to see the ‘true’ levels within Vegas as it analyses video AFTER YUV->RGB conversion, already clipped. As an example, on this page: https://aeclub.net/forums/index.php?showtopic=4686&st=30 (it’s in Russian, but in the lower part of the page there are screenshots clearly demonstrating what’s being discussed there) you can see what my Vegas vectroscope showed on an ‘illegal levels’ short video footage (native DV). Further down the page, there are screenshots from other people’s systems vewing that very same DV video through Edius and Adobe Premiere (working in YUV color space) vectroscopes (with defferent levels). All the files (source and outputs in different formats) were uploaded, so you can download them and try to see what’s going on.

> When you bring any YUV gamut signal, 16-235, 4:2:0 or 4:2:2
> into an 8 bit RGB environment, or vice a versa you have
> colour space sampling takes place.

Color sampling with different schemes like 4:4:4, 4:1:1 or 4:2:0 is a different story with its own conversion problems. But in my particular case, color sampling for both the source and the output remains the same: PAL DV/DVD standard 4:2:0. I have no idea what happens to video in the sense of sampling scheme when it’s decoded by Vegas DV codec.

> Your described ‘posterisation’ problem now develops when
> you now want to go back to the 8 bit YCbCr colour space
> with its narrower gamut.

Not really. The problem occurs well before that — I notice the color shift while my video is still on Vegas’ timeline (RGB) and it remains there when I render my output into MPEG2.

Technically speaking, I wouldn’t call any color space (YUV or RGB) wider or narrower — they are just different and, even though every particular color value of one of them can MATHEMATICALLY be matched to the other, in fact, not all colors of one space can VISUALLY be matched in the other (with the limit of the same bit depth for both). This is why, I guess, the original RGB analogue video signal taken from a camcorder matrix is converted into YUV space using 12 or higher bpc. On the backwards conversion of DV YUV into RGB, there wouldn’t be much problem if an output RGB video was 12/14 bpc, while 8bpc RGB that we get in almost every RGB video application simply can’t reproduce all the original YUV colors VISUALLY adequate. If previous examples are not enough, try this native DV video: https://www.videoediting.ru/tmp/16_235_Sun.avi. And, finally, a simple math exercise (as discussed in a YUV->RGB thread on another forum):

Quote:
Imagine we would like to mix two YUV colors 200:200:200 and 170:170:170. As a result, we should get something in the middle: 185:185:185. Now let’s see how it works when converting YUV->RGB (using standard conversion equations):

YUV 200 200 200 -> RGB 249 140 380
YUV 170 170 170 -> RGB 185 139 290
YUV 185 185 185 -> RGB 217 140 335

Mixing two RGB colors:

(249+185)/2 = 217.0
(139+140)/2 = 139.5
(380+290)/2 = 335.0

Is that mathematically correct? Yes!
Does any of the resulting RGB colors physically exist? No!
Unquote

There’s also a book by Dan Margulis (if I remember his name correctly) on LAB color space (mainly, for Photoshop users). He explains the way a visual difference occurs when converting LAB->RGB->LAB (YUV color space is quite similar to LAB in that context).

> For a much more in depth understanding of this go to:
> https://compression.ru/download/articles/color_space/ch03.pdf

Thanks, but this one is more comprehensive, I guess:
https://www2.tek.com/cmsreplive/tirep/2211/2008.03.04.10.28.33_2211_EN.pdf
(pay special attention to the ‘Bandwidth Considerations’ and the ongoing chapters).

> Given that each encoding pass removes information…

In this particular case, it doesn’t necessarily have to. In fact, there would be little or no loss at all if 8bpc YUV was converted into >14 bpc RGB. Surprisingly, I couldn’t find an application capable of doing that. To my regret.

> Do a few generations back and forth between YUV and RGB
> systems and you will soon see degradation in picture
> quality.

Actually, one conversion is more than enough for that. Not for all kinds of source video, though.

> Sadly the 4:2:0 colour space with its limited chroma
> sampling is possibly the worst at exhibiting these
> problems.

You’re absolutely right.

> It happens from the other end as well though because when
> creating graphics on 10 bit 4:4:4 broadcast systems we have
> to limit the colour palette for any graduations used…
> otherwise we see very bad banding artefacts when going into
> any 8 bit system, NLE or linear tape suite.

Can’t these be limited by a higher bit depth of CG project? I work in After Effects and same banding problem occurs (especially noticeable on color gradients) only in a 8bpc project (10 bpc is probably not enough either?). Rising the project bit depth to 16 or even 32 bpc eliminates it usually, although slowdowns the work and renders. As regards sampling — does it really make sense to create grafics with 4:4:4 sampling scheme so far as the final output is anyway going to be 4:1:1 or 4:2:0, as I understand?

> To overcome these shortfalls stay 8 bit YUV or 10 bit YUV
> SDI the whole way…

I’d love to, but that would mean I have to eliminate Vegas from my workflow. Which I frankly wouldn’t want — both in terms of costs and…well, you know, like you put it, old habits die hard. I would prefer finding a way to convert my native 8bpc DV video into 14 (or higher) bpc video BEFORE importing it into Vegas. That would solve the problem, I guess.

> Vegas 8.0 has implemented a 32 bit floating point setting
> which when working in 8 bit video can help with some of the > banding issues.

The bit depth of Vegas’ project only matters for the quality of compositing you perform therein, i.e. synthetic video going out of such project will look much better indeed (likewise, the bit depth of After Effects project does what I wrote above). However, Vegas seems to work with the video data received from DV decoder, which is already 8 bpc RGB by that time, so it doesn’t really make sense to increase the bit depth of a project in that context.

> Wish I could suggest some other answers to your problem but
> I have not yet found any way of getting around what you
> describe, well not unless I use SDI. Wish I could!

Thanks for that, neither do I see any workaround that could effectively deal with this issue. If Sony doesn’t address this in next Vegas generation, I think I’ll be moving to Edius.

[Gleb Rysanov]

Wow! That was quite an in-depth answer. Thanks, Chris. Below are my comments:

> Over two hundred shows for broadcast on Vegas here and have
> never experienced the issue as you describe it.

Here goes the difference between you and me. Like I wrote above, I do not do any broadcast video. If I did, I wouldn’t have noticed any problems either, because RGB 16-235 gamut cuts it all. But I’m doing video just for home DVD playback, which is not limited to just 16-235 levels but is instead PAL DVD YUV 4:2:0 (0-255 gamut or even wider, depending on the cam), which is the same as native DV. So my problem is to preserve colors to the most possible extent, leave them as they were.

> I am assuming you mean that the clip with the title has been rendered?

I meam that once Vegas has to render a frame, it does so by converting 8 bpc YUV into 8 bpc RGB, which is not sufficient since 8 bpc YUV stores noticeably more color information that 8 bpc RGB principally can. This results in a color shift. Posterisation. I don’t know how to call it — colors just deteriorate. Sometimes it’s not obvious (that is in a scene, for example, with colors very similar or identical to those RGB can reproduce). But sometimes, when colors are barely legal (if at all) in terms of RGB (studio or computer) color gamut, the difference is awsome. Again, if your video will go to the air, it doesn’t really matter becuase whatever your source colors are, they shall anyway be clipped to narrow studio RGB gamut. So in your case the problem has to be solved the other way: a cameraman shall shoot his video with that in mind and shall not allow colors exceed the ‘final destination’ broadcast color gamut.

> Watching the clips on both the Vegas vector scope…

It will only show you computer RGB colors and not the full native gamut of your DV video.

> …and WFM…

If you mean a FireWire monitor, that’s quite strange you see no difference. Is the monitor you output your video to via FW a TV monitor, not a LCD TV or computer monitor?

>…and an external hardware vector…

I’m not sure what signal this external device gets. If you plug it to your video card output, you’ll most probably get the same computer RGB colors, already clipped. As far as I know, Vegas is only capable of outputting the ‘true’ video signal through some special hardware cards (like BlackMagic, AJA, etc.) listed in the manual. I don’t remember exactly which ones Vegas supports and I personally don’t use any.

> …plus observing the component output results via a Miranda DV Bridge Pro on a grade 2 broadcast monitor.

I’m not familiar with that kind of equipment and this specific setup. Make sure that in both cases you get an output of what’s on Vegas’ timeline directly, without RGB intermediary conversion and without color clipping on the side of your external equipment.

> The results: I see no difference to the actual footage on
the Vegas scopes…

You won’t see it there.

> …the external scopes or the video monitor.

That’s strange to me. I just plug in a regular CRT monitor via FireWire and see the difference clearly. Check what signal your external hardware gets. Try seeing a video that you know is ‘illegal’ in terms of broadcast gamut (overbrights will do perfectly).

> I assume that you are using a true broadcast ‘monitor’ that
has no AGC set-up on the vision circuits.

Well, I’m actually using my TV set. Whether it’s ‘true’ or not — I have no idea 🙂 Same about AGC setup.

> This is the RGB 8 bit 0-255 video gamut. Totally illegal
for broadcast.

But quite legal for me. I can see no reason to limit the colors in my video for as long as they can be reproduced by my DVD-player and TV.

>…you will see changes to your overall picture gamut
because the monitor is adjusting based on the levels it sees
coming through on the titles.

Hmm…if it was the problem, then, if I understand your reasoning correctly, the video behind the titles must become brighter, more vivid as its levels are being pushed up? Is that right? In fact, the effect I see is quite opposite to that — colors get rather faded, lose their brightness.

> Try this experiment to see if you can chase this down. On
> your titles apply the Sony ‘Broadcast Colors’ plugin.
> …
> This will now bring your titles to 1 volt peak to peak.

That will narrow down the entire color gamut of my video to just 16-235. While I’m looking for a way to retain it as wide as it was shot.

> In a perfect world you would ‘grade’ and colour correct and
> level correct each and every clip to meet the required standards.

I tried that. But couldn’t get back those sunset colors as seeing on my DV tape.

> Using Vegas’ waveform and vector scope monitoring is the
> only way to know if your levels are correct…

Again, there is no such thing in my workflow as ‘correct levels.’ They are correct for me if identical to those I see on DV tape.

> BTW we have found the Vegas scopes to be accurate enough
> for broadcast delivery.

They should be. If I was doing broadcast video, I wouldn’t ever rise this question.

[Gleb Rysanov]

Thanks for the reply, Mike. I surfed through his site and, although found it very useful in that it explains color coversion basics, can’t see how this information can help me.

My question rather concerns the general problem of YUV-RGB conversion which in most cases can’t be done 100% adequately just because of the math (rounded-up figures, negative values treatment, etc.), no matter which RGB model (computer or studio) is used. Unless, of course, you can convert 8bpc YUV (DV) to something like at least 12-14 (16 would be the best option) bpc RGB, which would in such case be properly matched, processed and converted back to 8bpc YUV by any RGB video application. Vegas doesn’t do this. Actually, there is no such convertor that I know of, but maybe I just overlooked it.

To easily see what I mean, try doing this:
1. Import a DV footage (source)
2. Duplicate it and place two events on top of each other on your timeline
3. Add titles to any one of the two events
4. By soloing a track, output them one after another to a TV monitor (as far as I know, this can only be done in Vegas via your camcorder plugged to the PC’s FireWire; viewing events on your PC monitor doesn’t show the difference, so don’t bother).

You will see the difference in colors between those two events. If you find a footafe with ‘semi-legal’ colors like overbrights, sunsets, etc. — you can assess how drastical the difference could be.

[Gleb Rysanov]

Hello, Greg

This is easy indeed. All you have to do is render voice-over as an independent file, and import it into Architect. Place it on the ‘timeline’ (add a track, if needed). Now you can add a button and specify in its propertins the proper number of the audio track that it should activate (by default, the track No. 1 will play; the button that you insert gives an option to chose another track — just go to the button’s properties window and specify the right number for that track).