Chris Young
Forum Replies Created
-
Jim ~
Yes I know your frustration. I kept a record of how I sorted this annoying problem out. It’s fairly long winded so best you contact me off forum and I can send you a zipped Word .doc file with what worked for me. You can reach me on:
cyvideo ‘at’ ozemail.com.au just replace the ‘at’ of course with the @.Chris Young
CYV Productions
Sydney -
Gleb ~
Hi. Sorry, maybe in my reading I didn’t fully see what you were getting at. I think I got the gist of it now!
For what its worth the results as I outlined are as we see them. Just for reference the WFM is a Waveform monitor, which is used for monitoring video levels, primarily luminance levels. The Vector scope is designed for measuring chroma levels. The Miranda unit comes from Miranda Technologies, miranda.com, 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. Another one of the Miranda units goes from fire wire to SDI and vice a versa.
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. I still say YUV but really should say YCbCr but old habits die hard.
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.
PAL YUV 4:2:0, DV or DVD, is restricted to the 16-235 levels not 0-255 and herein lies your problem when you talk about colour shift or ‘posterisation’ as you call it. 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.
In this case the YCbCr gamut is converted to computer RGB 8 bit 0-255 colour space. In other words the YCbCr gamut range of 219 is represented across the 256 RGB gamut range of the computer. In this case the computer has the ability to represent all shades of the YCbCr gamut without any real visible artefacts. Your described ‘posterisation’ problem now develops when you now want to go back to the 8 bit YCbCr colour space with its narrower gamut.
For example you could have a nice graduated blue sky, or graduated sunset red sky, as you mention, which once digitised is now represented by the wider RGB 256 bit colour space. On conversion back to the 219 available in the YUV space there is no direct bit for bit representation hence the shades coming from the 256 colour space for which there is no direct equivalent in the 219 available are shifted up or down that 219 colour space to the bits that come closest to representing those 256 bit chroma levels. For a much more in depth understanding of this go to:
https://compression.ru/download/articles/color_space/ch03.pdf
Explains it far better than I could within this post.
This problem has a name and it has plagued digital broadcasting for years. It’s called ‘concatenation’ and in video terms can be summed up as:
“Concatenation is the name given to the linking of digital systems and compressions in tandem. Each compression encoding pass removes information and the compatibility of the final concatenated system can cause concern.”
Given that each encoding pass removes information we start to understand why we see chroma ‘banding’ or ‘posterisation’ as you put it, which is a pretty accurate description as that is how posterisation effects are created, by throwing away information. Do a few generations back and forth between YUV and RGB systems and you will soon see degradation in picture quality. Sadly the 4:2:0 colour space with its limited chroma sampling is possibly the worst at exhibiting these problems. 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. It’s even mildly noticeable going into a 4:2:2 10 bit Digi-Beta environment. To overcome these shortfalls stay 8 bit YUV or 10 bit YUV SDI the whole way depending on your system and you never loose information. For a lot of us though the costs involved in buying and running these high-end SDI solutions doesn’t work out economically with the ever-diminishing budgets we seem to have to work with. The 8 bit and 10 bit SDI standards are the accepted SMPTE/ITU standards that have been implemented over the years to overcome some of the problems you are witnessing. 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. Sony states:
When using 8-bit input/output, the 32-bit floating-point setting can prevent banding from compositing that contains fades, feathered edges, or gradients.
Anything rendered in fact. In practice I find this helps in some cases and not so much in others. 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!Chris Young
CYV Productions
Sydney -
Gleb ~
Hmm! This one has got me curious. Over two hundred shows for broadcast on Vegas here and have never experienced the issue as you describe it. Have just tried doing exactly what you said. I am assuming you mean that the clip with the title has been rendered?
The set-up: Watching the clips on both the Vegas vector scope and WFM and an external hardware vector and WFM set plus observing the component output results via a Miranda DV Bridge Pro on a grade 2 broadcast monitor. The results: I see no difference to the actual footage on the Vegas scopes, the external scopes or the video monitor. None that I can measure even on expanded waveforms on the hardware scopes. The segment where the titles are though is a different story. The background video clip has not been affected in any way level wise but the scopes tell me the titles are through the roof. As one would expect.
I assume that you are using a true broadcast ‘monitor’ that has no AGC set-up on the vision circuits. The reason I ask this is that a lot of so called monitors aren’t true in the sense that they will adjust the video peak to peak level dependant on the levels coming in. Bearing in mind as you said that Vegas works in 8 bit RGB colour space you will find that any titles in a clip that contain white or other high luminance levels will push these to 110 on the waveform monitor and if the titles also have black in them the black levels will go down to -8 below blanking. This is the RGB 8 bit 0-255 video gamut. Totally illegal for broadcast.
The same applies to the chroma levels. Pure red for example will push the vector out to a screaming 148 instead of the broadcast max of 100. Push these sorts of levels to a monitor with AGC circuits and sure as anything 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.
Try this experiment to see if you can chase this down. On your titles apply the Sony ‘Broadcast Colors’ plugin. If you are in PAL make sure the 7.5 IRE box is unchecked and that the Studio RGB [16 to 235] box is checked. From the drop down menu select ‘conservative’. This will now bring your titles to 1 volt peak to peak. Black being 0 and the whites and high luminance colours to 1 volt. Render out a clip with these titles in it and see if it changes your video clip gamut.
It’s a dirty way of doing it but by using the broadcast colour plug in at the ‘Video output FX’ plug point above your preview window you can apply these 16-235 levels to you entire program output, video, graphics the works. These 16-235 levels are the correct RGB levels to equate to the YUV colour space gamut. In effect it just clips anything above 100 and anything below 0 to give you a 1-volt p-p signal. In a perfect world you would ‘grade’ and colour correct and level correct each and every clip to meet the required standards. This we have just done on a two-year doco project that had the budget. For a weekly sports show that we work on it’s the quick and dirty method because of budget and time constraints.
Another caveat. I have seen in some camcorders that the video pass through mode, firewire to analogue; employs an AGC on the analogue processing side so this can affect what’s going through to the monitor. If both the camera and monitor employ AGC circuits you would never know where you are. Using Vegas’ waveform and vector scope monitoring is the only way to know if your levels are correct whether you grade every clip or use the quick and dirty ‘broadcast colors’ plugin. BTW we have found the Vegas scopes to be accurate enough for broadcast delivery.
Chris Young
CYV Productions
Sydney -
Don’t forget that Vegas is an 8 bit editor. I have had this banding problem when bringing in graphics etc done on 10 bit 4:4:4: systems. Try the following if you sre using Vegas 8. Go to the ‘project properties’ of the job in hand and under ‘pixel format’ change it from 8 bit to ’32 bit floating point’ and see if that helps. This 32 bit option was introduced in V8 to help overcome the banding problem.
Chris Young
CYV Productions
Sydney -
Forgot to mention that if they are DV AVI files from either the HVR-MRC1 or the HVR-DR60 there is another way. If you have Scenalyzer just navigate to the folder where the clips are, click, shift and select all of them then you can select ‘join’ clips from the bottom menu. 60 mins of clips take about 8 mins to combine into one. Seeing that 60 mins of clips takes about 8 mins to transfer to the PC add another 8 mins to combine it totals around 16 mins to bring an hour of material into the system. Not too bad!
Chris Young
CYV Productions
Sydney -
Bob
If you are talking about M2T files from the Z7, Z1 etc there is a file connection tool, software, that you can download from Sony. I got mine from:
Monster link but there you have it.
Chris Young
CYV Productions
Sydney -
Saving markers and regions in MXF files has been an issue since v7.0. I reported the bug/problem way back last year but it wasn’t fixed in v8.0 or v8.0a but Sony Support mailed me on the 18th that it is a listed fix in v8.0b. Just downloaded 8.0b so am about to check it out!
Chris Young
CYV Productions
Sydney -
Recently I was at broadcast trade show demonstrating Vegas and the unit I was demoing on was an Intel based Quad Core QX6700 2.67GHz unit and basically this could run HDV with pic-in-pic HDV and maintain full frame rate. Start applying any CC or filters and the rate would drop. I think for HDV editing this would be about the minimum horsepower you would need to be able to edit HDV in any meaningful manner. I know I would be frustrated if a unit I was using had much less grunt than this box. DV, well that was a different story, the box screamed through DV like no tomorrow.
Chris Young
CYV Productions
Sydney -
Thanks Ed, will do if I haven’t worked it out. Probably my finger trouble. Other than the mentioned quirks Excal has been great with numerous switches of 500 to 1000+. Congrats on a great set of tools, everyone should have it!
Chris Young
CYV Productions
Sydney -
Hi DSE, long time no see since your visit two trips ago to Aussie.
No I think you misunderstood me Doug, probably not clear enough on my part.
The files have been brought in to the system via FAM mode and are residing on the AV drives just like all the other AVI’s. Now if I have an AVI in the Vegas trimmer I can create ‘Regions’ and they will save back to the file. If I now pull these files up into Vegas the Regions are there as I expected. I have tried this with HDCam MXF files and no way will it work, ‘File write protected or off-line’ error dialogue if you try. A BUG me thinks! Will file a report with Support and see what they say.
BTW, good to see you back at the COW.
Chris Young
CYV Productions
Sydney