DV (from VHS/Hi8/miniDV) -> HD. Expand color/luma? Bad idea?

[Colmino]

If this isn't a newbie question, I don't know what is. Here's my situation:

I've got hundreds of GB of video in DV format (as AVI). Most of that was from Hi8. Some of it was from VHS. Some was minidv. Anyway, it's all DV now. I grasp that the color space/luminance of DV is 4:1:1 and 16 to 235. The correct jargon isn't really known to me.

My plan is to ultimately make one HD video file lasting about two hours, and using footage from the DV videos. I even have some HDV video to throw in. It will be encoded using either VC-1 or H.264. Now, it occurs to me that since these two codecs are aimed at the home theater enthusiast/consumer, chances are they are capable of something better than what DV, Hi8 and VHS were designed for. Better color space, perhaps. But surely a more complete range of luminance. It seems to me that if I'm going to be playing such a HD video, on HD equipment designed to properly handle it, then it would be perhaps a wasted opportunity if I didn't expand/correct the color/luminance of my DV videos (in addition to the noise reduction I plan to undertake), to give them a bit of an edge over what they traditionally exhibit.

I can anticipate at least one observation: The equipment should be designed to expand 16-235 to 0-255 automatically. Well, for starters, I don't trust it to do so. But there are other considerations. I plan to generate some multimedia video (using AfterEffects or whatever) as well. And then there's the HDV, whose limitations I am not fully aware of. Anyway, my goal is to end up with as good-looking video as possible, and that's why I arrived at the idea of expanding my videos beyond their inherent limitations in pre-production.

So, let's see. Basically I'm wondering.. does this sound like a load of ill-informed rubbish? Or else, what sort of filters might I want to apply to achieve this or other enhancements to my videos which may or may not be standard practice for this sort of project?

Anyway, thanks.

[JohnnyMalaria]

HDV is similar to DV in that both use 4:2:0 (actually PAL DV uses 4:2:0 and NTSC DV uses 4:1:1 but the amount of information is the same). HDV and DV also have the same luma/chroma ranges (the 16-235 etc). So, the important part of your process is the quality of the upsampling from SD to HD. This is especially true for NTSC since it has to go from 4:1:1 to 4:2:0 (assuming that's what your final format uses). If your final format supports 4:2:2, it would be wise to test that option for NTSC DV source.

[Colmino]

Okay, thanks. Would you happen to be able to recommend any VDub filters which are commonly used to enhance the image? (Noise reduction can wait. I'm thinking about the washed-out colors and the gray blacks, mostly. Every VHS tape I own looks like that, so I like to assume that those common problems have common solutions.)

[JohnnyMalaria]

I'll have to defer to the VDub experts...

[jagabo]

Gray blacks can be fixed with the Brigtness/Contrast filter or Levels. In VirtualDub the brightness should span the full 0 to 255 range. More complex non-linear adjustments can be done with Gradation Curves.

You can increase the saturation with HSV Adjust or Color Mill.

If your video has has luma values outside the 16-235 range you should use AviSynth to do the filtering. Filtering in VirtualDub will lose the blacker-than-black (luma < 16) and brighter-than-bright (luma > 235) portions because VirtualDub performs the usual CCIR.601 contrast expansion on converting YUV to RGB.

Or you can use Cedocida for DV decompression and compression in VirtualDub. On decompresssion you can have Cidocida do the YUV to RGB conversion without the contrast expansion, and then on compression have it perform the RGB to YUV conversion without contrast reduction. If you do it this way, be sure to keep blacks at 16 and whites at 235 while working in VirtualDub.

[Colmino]

This is some good info. Quick question: I've seen people post screenshots of a frame of video with spectographs on the bottom and right, seemingly indicative of luminosity analyses. The method for enabling that display in VDub isn't immediately apparent to me. How does one go about it?

[edDV]

If this isn't a newbie question, I don't know what is. Here's my situation:

I've got hundreds of GB of video in DV format (as AVI). Most of that was from Hi8. Some of it was from VHS. Some was minidv. Anyway, it's all DV now. I grasp that the color space/luminance of DV is 4:1:1 and 16 to 235. The correct jargon isn't really known to me.

Yes but... DV is 8bit with black defined as 16 and nominal white at 235 but consumer camcorders routinely take whites up to 255 where they clip. Matching black levels at 16 is probably the most important quality issue.

My plan is to ultimately make one HD video file lasting about two hours, and using footage from the DV videos. I even have some HDV video to throw in. It will be encoded using either VC-1 or H.264.

What is the point? HDTV sets can handle the upscale in hardware from DV or DVD format to HD. You are unlikely to match the upscale quality with software. The only reason I can see to do this would be to incorporate DV material into a mainly HD production. I'd also recommend interlace DV or interlace HD MPeg2 encoding for quality. VC-1 or H.264 should only be used if you want smaller files.

Now, it occurs to me that since these two codecs are aimed at the home theater enthusiast/consumer, chances are they are capable of something better than what DV, Hi8 and VHS were designed for. Better color space, perhaps. But surely a more complete range of luminance.

Nope: All home HD formats use the same 8bit 16-235 luminance values, same as DV. HD origination can be higher quality but not DV upconversion. You can "colorcorrect" to match scene to scene where necessary.

If you go much higher in production level there are small differences in color space (e.g. 601 vs. 709) and higher bit depths (e.g. 10-14) but that won't be a factor with VHS and DV source. You will be doing eyeball color matching.

It seems to me that if I'm going to be playing such a HD video, on HD equipment designed to properly handle it, then it would be perhaps a wasted opportunity if I didn't expand/correct the color/luminance of my DV videos (in addition to the noise reduction I plan to undertake), to give them a bit of an edge over what they traditionally exhibit.

I can anticipate at least one observation: The equipment should be designed to expand 16-235 to 0-255 automatically. Well, for starters, I don't trust it to do so. But there are other considerations. I plan to generate some multimedia video (using AfterEffects or whatever) as well. And then there's the HDV, whose limitations I am not fully aware of. Anyway, my goal is to end up with as good-looking video as possible, and that's why I arrived at the idea of expanding my videos beyond their inherent limitations in pre-production.

All of those formats reference the same 8bit 16-235 luminance levels. Consumer level DV and HDV camcorders will probably need clip to clip luminance correction to bring typical hot whites down closer to 235*. Best to do this during editing for scene flow. Color correction is lossy and should only be done once.

So, let's see. Basically I'm wondering.. does this sound like a load of ill-informed rubbish? Or else, what sort of filters might I want to apply to achieve this or other enhancements to my videos which may or may not be standard practice for this sort of project?

Anyway, thanks.

Experiment as you wish. Personally, I'd edit the DV format material as DV and leave upconversion to display hardware. Even cheap HDTV's do reasonably well with clean DV format source. Future sets will get better and better at it as hardware processing improves.


* Prosumer camcorders (e.g. Sony VX-2100 DV or HVR-FX1 HDV up) are likely to have better luminance 16-235 black to white management. Consumer cams "cheat" whites up to 255 for better low light performance but pay for it with bright scene clipping (e.g. sky).

[edDV]

This is some good info. Quick question: I've seen people post screenshots of a frame of video with spectographs on the bottom and right, seemingly indicative of luminosity analyses. The method for enabling that display in VDub isn't immediately apparent to me. How does one go about it?

A standard video waveform monitor* works fine for luminance analysis. This picture shows how the Canon HV20 HDV camcorder clips the sky to 255 under some conditions when auto exposure is set.




* Sony Vegas shown

[jagabo]

VirtualDub's Levels filter has a histogram feature. It's not as good as waveform monitor. Remember that brightness should range from 0 to 255 in this filter.



Notice how the detail in the sky has been washed out by the YUV->RGB contrast expansion in VirtualDub. The large washed out area is also causing a big peak in the histogram making the rest of the histogram hard to read.

AviSynth's VideoScope filter is a nice waveform monitor that works in YUV. So 16-235 is correct in that display.

[Colmino]

My plan is to ultimately make one HD video file lasting about two hours, and using footage from the DV videos. I even have some HDV video to throw in. It will be encoded using either VC-1 or H.264.

What is the point? HDTV sets can handle the upscale in hardware from DV or DVD format to HD. You are unlikely to match the upscale quality with software. The only reason I can see to do this would be to incorporate DV material into a mainly HD production.

Bingo. Although most of the video will be sourced from various SD formats (and ultimately DV in fact), some of the video is HDV, and I intend the menus and such to also be HD. As for deinterlacing, outside of Algolith, I just don't trust the realtime hardware solutions. Certainly none of the hardware available to me boasts motion-adaptive deinterlacing. Besides, I intend to perform quite a bit of restoration and similar processes on the old video footage, and I've had much happier experiences when it's been properly converted into a usable 60Hz format. Perhaps if Premiere Pro (and the rest) could deal with video in a field-by-field capacity, it would be less of an issue.

I'd also recommend interlace DV or interlace HD MPeg2 encoding for quality. VC-1 or H.264 should only be used if you want smaller files.

Hmm. In my experience, while MPEG2 can match H.264's quality, I have to throw approximately 2.5x the bandwidth at it to accomplish this. Considering that I am shooting for an average 30 Mbps (contemporary codec) to begin with, the math suggests that I would run into practical limitations if I tried to use MPEG2. What am I missing about this codec?

All of those formats reference the same 8bit 16-235 luminance levels. Consumer level DV and HDV camcorders will probably need clip to clip luminance correction to bring typical hot whites down closer to 235*. Best to do this during editing for scene flow.

Great info here. Particularly the observation about cheating camcorders. I wouldn't have expected it of my HV20, since it seems to me that if anything, the camcorder has a major weakness in anything less than a well-lit room. I note that Sony Vegas is shown with the handy scope. I have a suspicion that my poor Premiere Pro just doesn't have it.

The question begs, incidentally, that if video can be "contaminated" in the manner illustrated by the HV20's superwhites, how is e.g. a projector supposed to know whether or not to perform luma expansion to 0-255? Questions like these are what prompted my concerns over the possible desirability of manipulating such facets of the video ahead of time.

[Colmino]

Those Avisynth scopes are the ones I saw before. Though I do like the one in Sony Vegas a bit better. What they both need is an Adobe Audition-style clipping "fuse" to notify the user when the video's luma has gone out of bounds. (This assumes they don't, of course.)

[guns1inger]

This is some good info. Quick question: I've seen people post screenshots of a frame of video with spectographs on the bottom and right, seemingly indicative of luminosity analyses. The method for enabling that display in VDub isn't immediately apparent to me. How does one go about it?

They aren't built into virtualdub, however there is a plugin called color tools that has all of this. You can read about it here : http://forum.doom9.org/showthread.php?s=&threadid=72634 and download it here : http://trevlac.us/colorCorrection/clrtools.vdf

The only problem is you cannot see the meters and the output image at the same time because of the way virtualdub works. Otherwise it is an indispensable plugin.

There are also reports that it does not play nicely under Vista.

[jagabo]

Remember that VirtualDub does all it's filtering in RGB with expanded contrast. This makes VirtualDub useless for correcting too-hot DV camcorder video. You need to use AviSynth instead. If you don't want to do all your filtering in AviSynth, at least use AviSynth to convert to RGB before giving the video to VirtualDub. This way you can retain the luminance range:

AviSource("filename.avi")
ConvertToRGB(matrix="PC.601")

Make sure the output codec is set not to compress the luma range on conversion back to YUV. In Cedocida (DV encoder) for example:



Oh, and one hint: don't use (or even install) Panasonic DV Codec. An addition to several bugs it doesn't give you the option of not compressing the luma range.

[Colmino]

A standard video waveform monitor* works fine for luminance analysis. This picture shows how the Canon HV20 HDV camcorder clips the sky to 255 under some conditions when auto exposure is set.




* Sony Vegas shown

Coming back to this thread, I had a question regarding the screenshot you provided. It shows Sony Vegas with the waveform monitor on. I note that you are seeing the video with its fully represented Y channel resolution. Now, my understanding is that both Sony Vegas and Premiere Pro share the (frankly inexcusable) problem of blindly clipping a YUV video with 16-255 values down to 16-235, crushing the whites. Yet this supposed fact doesn't jive with your screenshot. Going by the screenshot, one might assume that Sony Vegas, at least, is capable of properly interpreting non-compliant YUV, or in any event avoiding the unnecessary clipping of whites. I have already determined that Premiere Pro cannot do this.

I have never used Sony Vegas. But it says a lot that you can access a waveform monitor within Sony Vegas, while Premiere Pro lacks this undeniably handy utility. So perhaps I have been using the wrong editing software. But I would like to pin this one down now: Can Sony Vegas import DV/HDV videos without crushing the whites?

[edDV]

Re: Crushing whites to 235

I've never seen that with Vegas or in Premiere Pro for that matter but I haven't used Premiere Pro much since v1.5. It may be caused by the codec you are using. DV/HDV work over the 16-255 range and below black 0-16 will show as well. Same goes for encoding MPeg2 with the internal Mainconcept encoder.

I prefer Vegas for a number of reasons but mostly for stability, support for multiple instances, desktop layout flexibility, and the scopes.

I suggest you test your system with the Bell Nuit color bar to characterize behavior in the 0-16 and 235-255 levels.


If you search IRE or Belle Nuit you will find several discussions on 235 vs. 255 like these which includes some Premiere analysis.
https://forum.videohelp.com/topic319733.html
https://forum.videohelp.com/topic259098.html


Re: Can Sony Vegas import DV/HDV videos without crushing the whites?

Yes most certainly as the above threads will show. This is also true if you use WinDV for DV capture or HDVsplit for HDV capture.

[Colmino]

WinDV and HDVsplit are what I use. But there's truly no doubt about what I see in Premiere Pro: The highlights are crushed. The same (HDV .M2T) frame viewed with DGIndex showcases the whites which Premiere Pro crushed.

I suppose I will have to try out Sony Vegas now, and see how it handles things.

[jagabo]

I don't use Premiere Pro but I seem to recall reading that it does all its filtering in RGB and uses the standard rec601 and rec709 conversion matrices. In which case it would blow out highlights and crush blacks.

Here's a test DV test chart with IRE below 0 and above 100 if you need a verified source:

https://forum.videohelp.com/images/guides/p1820664/belle%20nuit%20ntsc%20dv.zip

It's possible that the program only performs the contrast expansion for display, not in the filter chain. I would try a little filtering of the above file and see what shows up in the output.

[Colmino]

Here's what PPro spat out. Precisely what I was expecting, based on my observations.


belle%20nuit%20ntsc%20dv.bmp

Edit: And that really sort of tears it, doesn't it. Sony Vegas evidently doesn't have this horrible limitation. Adobe's products are such a mixed bag. AE is great. Audition needs to be rewritten from the ground up to truncate away all of its legacy Cool Edit shortcomings. Flash lacks some features that are so ubiquitous that I ended up doing them from within AE's amazingly limited painting utility. And then there's Premiere Pro, which I have been using for years, blissfully unaware of the fact that all along I had been chopping detail out of my videos needlessly. Blah.

[jagabo]

Here's what PPro spat out. Precisely what I was expecting, based on my observations.
belle%20nuit%20ntsc%20dv.bmp

How did you save that bitmap? It's approriate for a program to expand the luma when exporting to an RGB image. If you simply exported one frame from the DV file it may not be representative of what the program does internally when handling video.

What you need to do is open the source DV, run a simple filter like blur, and save as DV. Then compare the source and output files with something that will let you see the luma levels without conversion to RGB. Or you can use AviSynth with the right DV decoder (one that decodes to YUY2, Cedicida is a good choice, don't use Panasonic DV codec) will work:

AviSource("file.avi") #or DirectShowSource()
ConvertToRGB(matrix="PC.601") #don't expand luma

Then open that in VirtualDub.

[Colmino]

Okay, I'll get cracking on that and will report back. In the meantime, though, it probably says enough that PPro's preview window has the blacks/whites crushed as well. So even if, contrary to my expectation, it is able to pass the video without crushing things, the practical use of such unexpected compliance is limited. It would come down to the need to "trust" PPro, rather than my own eyes. Maybe if there wasn't a clear alternative, that would be Hobson's choice.

Edit: Okay, here's what VDub gave me.

belle_blur0.bmp

Just to be 100% certain, I loaded the original up (via Avisynth) and it looked fine and non-crushed. So that settles that. Premiere Pro crushes 'em, doesn't tell you it's doing so, and doesn't offer a way to circumvent it.

[edDV]

I wish I had Premiere Pro here to test but I don't.

I think you need to prove your case with output results, not the PPro computer monitor. Premiere 6.5 did this correctly and if PPro didn't we would have heard by now.

[jagabo]

I'm no fan of Adobe or Premiere, but the problem is really your source, not Premiere. Video shouldn't have significant content below IRE 0 or above IRE 100. If your source was within spec it wouldn't matter that Premiere clips. In cases like this I would just use AviSynth to fix the video.

[Colmino]

I think you need to prove your case with output results, not the PPro computer monitor. Premiere 6.5 did this correctly and if PPro didn't we would have heard by now.

I was actually alerted to this problem by two sources. The www.hv20.com forums, and this thread:

http://www.adobeforums.com/webx/?14@763.W50iic1DSjN@.3c0648b1/51

According to said thread, Premiere didn't deal with YUV at all until 2.0, and is therefore new to the game, which, in one of the poster's judgment, explains why the software handles it so badly. Well, in actuality I wasn't hoping to try to convince everyone of PPro's faults. I've convinced myself, thanks to your help. Now I'll be looking into solutions.

I'm no fan of Adobe or Premiere, but the problem is really your source, not Premiere. Video shouldn't have significant content below IRE 0 or above IRE 100. If your source was within spec it wouldn't matter that Premiere clips.

This is true. But I don't think it's much of a case in PPro's defense, since other software - including a lot of free stuff - enables solutions, and PPro doesn't so much as notify when it's applying this destructive modification to one's video. I'll also say that the HV20 (or HV30) is more or less the defacto informed consumer's hi-def camcorder (for now), and its Y range is 16-255. And this isn't a type of non-compliance that Canon invented; it's been around for a while.

In cases like this I would just use AviSynth to fix the video.

I've just now looked into that option and it seems there is indeed a way of forcing PPro to accept AVS files. Until I get my hands on Sony Vegas (which I anticipate being costly), that should prove an acceptable interim solution, provided of course I can also get Avisynth to deal with HDV .M2T files.

[jagabo]

provided of course I can also get Avisynth to deal with HDV .M2T files.

Haali Media Splitter and DirectShowSource().

[guns1inger]

YMMV given local pricing policies, but over here Vegas 8 Pro DVD costs around 65% of the price of Premiere Pro CS3, which for mine makes it far better value for money. Academic pricing is even better, if you qualify.

[Colmino]

provided of course I can also get Avisynth to deal with HDV .M2T files.

Haali Media Splitter and DirectShowSource().

It works. But there are two problems. Perhaps they are FAQs.

First, something (AVS, Haali, whatever) seems to be taking it upon itself to adjust the aspect ratio of the HDV video to where it's a 4:3 box inside an anamorphic 16:9 frame. Ie, the resolution of the image is 1080x1080, with black bars making up 180 lines on each side of the image (left/right) for a total of 1440x1080. This certainly isn't how the footage was recorded, and importing the .M2T without the AVS container does not generate this anomaly.

Second, there is a four or five pixel thick green line at the bottom. Not present in the pre-AVS rendition.

No time remains to puzzle this out. But again, at least it is being imported without anything being crushed. Just need to iron out these new wrinkles. ;p

[jagabo]

I only have a few small sample .M2T files sitting around but I don't see the problems you describe. The the AR issue probably results from the loss of DAR information in AviSynth. Open the AVS file in VirtualDub and check the frame size. I'm pretty sure you will see 1440x1080 and no black borders. There is probably some way in Premiere to tell it the 1440x1080 source is 16:9 DAR, not square pixel. (In many programs you right click on the clip in the timeline and the menu that pops up has AR options.) Or you could resize to 1920x1080 in AviSynth.

Regarding the green pixels at the bottom of the frame: I know there are some containers that claim to be 1088 lines tall but the data is only 1080 lines. There is a program that patches the file header to 1080 to get around this. If AviSynth gets a 1088 line image you can always just crop off the bottom 8 lines with Crop(0, 0, -0, -8).

[Colmino]

In Cedocida (DV encoder) for example:

Quick question: How are you getting that configuration menu? Far as I can tell, Cedocida is just a .dll. Can't find any associated .exe or whatever. (Hey.. it's the newbie forum. ;p )

[jagabo]

How are you getting that configuration menu?

Start VirtualDub. Select Video -> Compression. Select Cedocida in the left pane. Press the Configure button to the right.

[edDV]

My recall of Premiere history is Premiere 1.0-6.5 were internally RGB but later versions supported certain external SDI->YCbCr->SDI hardware paths. Any processing required a conversion to RGB and back.

Starting with Version 5.0, a virtualized YCbCr for DV format was added. Version 6.0 fully supported DirectShow without proprietary DV I/O port drivers. DV was converted to RGB for any processing.

Premiere Pro 1.0 to CS3 was a total rewrite (XP DirectShow only) that allowed native RGB or YCbCr project timelines. YCbCr support mainly applied to SDI I/O hardware and third party codecs. Certain filters still required internal RGB conversion.

Version 3.0 (CS3) includes a native HDV project virtualization and HDV capture/monitoring much like DV in earlier versons. A Mac version of CS3 was added.