Not sure I understand??? the title is generated media...it just exists on the timeline so I can't bring it into gearshift so not sure how to bring it up to HD...Also, why were the titles clear in other dv projects??? There has not been any adjustment to the contrast on the title, just red text on black BG.

Thanks again in advance...

Stan.

Red on black is kind of asking for trouble, try pulling the level of the red down a bit or add a small border to the text that's about halfway between the background and the text.
Your other problem I think is you're adding keyframes at somewhere other than the start of the event. Turnoff Sync to Cursor, clsoe the FX and open again and they move the keyframe to the start of the FXs T/L
Bob.

Thank you soo much...your second point is exactly what had happened...The title issue worries me though...cannot understand how a title can be made if it is going to look like that...as I mentioned it looks fine in the preview screen prior to render...I'm curious as to the explanation...
Thanks very much for the other tip, though...much appreciated.

Stan

Red text on a black background is pretty much absolute worst case for video, particularly with the 4:2:0 color sampling of HDV.

John

thanks John...I guess I'll just have to give up on it... I am just disappointed that Vegas is limited to producing these very sub par titles unless there is a way to do it and it's just me (very possible)...I mean why can't red text be produced crisply on a black background...I've seen other movies with it...Is it a different titling product or platform??? I don't know enough to know but I sure am curious. It seems like such a small thing to expect.

Notwithstanding the good advice above, have you tried a small .. very small . . . final render experiment? If you have apologies. If not might be worth a try? - G

Stan,
It's not a matter of Vegas or anything along those lines. It's the colorspace and the way colors are sampled. You might try a lesser red against the black, or try separating the red with another lesser red. Red against black is tough for anything to do well. Try a lesser black, with blacks set to 20 or so, vs 0 or 16. That'll help.

Yes, Stan, you have rendered it, apologies.

Spot? Please give me a link to where I can read up on how this colour-space "works"?

I've just done my own experiments using a bunch of colours - foregrounds and backgrounds. Some come out SHARP and others are quite blurry. I've even just tried - unsuccessfully - chroma-keying inverts of Red = Turquoise, to see what happens. Stubborn beasty, this colour-space sampling.

TIA,

Grazie

There was a discussion here a while ago about titles generated at 4:4:4 (which they are in Vegas) rendered to DV at 4:1:1 and then compressed to 4:2:0 MPEG2. After all the chroma subsampling, you end up with only 12.5% of the original color resolution. It was discussed at greater length in this thread:

http://www.sonymediasoftware.com/forums/ShowMessage.asp?ForumID=4&MessageID=390252

Unfortunately, the thread got a bit ugly because of the limited knowledge of a former forum member, but there is some decent technical discussion about colorspace and chroma subsmapling is there. There is also a link to a set of test files I made up that demonstrate the subsampling issues. Curiously, it consists of red shapes on a black background.

John

Thanks John - G

Thanks to all for the imput...definitely a lot of stuff to read...I'll try working with the equation you suggested, Spot, thank you...

I've got a little time on my hands and like the practice anyway so I'll try to illustrate the problem.

A file rendered with compression often throws away some color data. DV25 is a good example of this and we can use the NTSC color sampling scheme as an example.

NTSC DV25 uses a 4:1:1 sampling scheme. This means that for every 4 samples in a line of picture data, the luminance (brightness) is sampled every time, and the red and blue values are sampled once every 4 samples. Green is calculated -- if your total luminance is X and red and blue are Y and Z then what's left is the green value.

What DV25 must do when decoding is estimate the color values between the actual color samples. You get averaged color values between the actual color samples.

So here's where your title smearing come in. Let's say that you have generated titles on the timeline, and these titles have a sharp edge. On one pixel you have a red title and on the next pixel you've got a black background. In an edit program this looks fine prior to rendering but once you render to DV25 that transition from red to black falls somewhere within those 4 samples. So in the case of your titles you've got a point where there is a definite red value, a point 4 samples later where there is a definte black value, and then the 3 samples in between are calculated to make a value transition from red to "not red".

NTSC DV is an easy example but many compressed formats exhibit some amount of color degradation, and if you render to one and then to another you can compound the problem.

So what do you do? The first thing is to understand the problem, at least enough that you'll have some clue how to avoid banging your head against a wall that won't move. Here's what I'd recommend:

--Don't render back to a DV format. If you must render to an intermediate format, try to use one with better color sampling. Uncompressed would be best because it retains all sample values, but you may find other codecs work well enough.
--Try not to render to an intermediate if you don't have to. It'd be better to render straight to mpeg2 than to go to DV25 and then to mpeg2. There are exceptions, of course - it's better to render HDV to an intermediate so you can work on it efficiently.
--Consider that, in compressed formats, luminance is sampled more often than colors. A white title on a black background will look sharper than a darker color on the same background. Go for contrast.

Lunchtime.
Rob Mack

Of course Grazie is a PAL man and the problem is worse with 4:2:0 as the '0' means there's even less sampling of the red part of the spectrum which is why green text on black survives better than red text on black.
I'd imagine though that rendering the red red text to NTSC DV and then encoding that to DVDs 4:2:0 would really make things fall apart.
Bob.

Bob, there is a little bit less credit being given to the fact that 4:1:1 and 4:2:0 have the equivalent amount of information remaining from the original. Whether this be 4:4:4 or a pixel shift or a line interpolated 4:2:2 or lesser format. Different information but the same amount. Conversion creates a form of blur but at a high resolution, not, by virtue of our rods being greater than our cones, one that ought to be deliverated over if we keep a couple of metres back from the TV. But I digress.

No less red ought to exist in the source information, although it would be different between that of 4:1:1 and 4:2:0. The places where the matrix are filled from are different based on an alternating algorithm not quite implied by the ratio breakdown.

I'd also credit Sony with having the ability to port between 4:4:4, 4:2:0, 4:1:1 and 4:2:2 in a format as described by EBU/SMPTE so minimising the effects of the transition. As Vegas is RGB (4:4:4) internally - wherever we are not in passthrough mode (uncompressed RGB 8bit or DV [YUV]) then I'd expect Vegas to use the optimum transcoding tables / rules and co-efficients as appropriate.

Won't stop the bleeding - which - as per previous/adjacent threads, isn't always the format or workflow - but rather a glitch in the operator's expectation or appreciation of the restrictions of digital video being passed through video format encoders/decoders (and I mean PAL/NTSC by that - not MJPEG,DV, MPEG etc).