VHS capturing device in 2022?

[Sharc]

Originally Posted by lansing

The article is a little bit confusing, what I got is basically for VHS capture we'll need the black level to be at 16 on the waveform and white level at 235.

Exactly. That's the main point for the luma (Y). Once we are in the digital domain the IRE has no relevance any more.
Next step could be check the chroma (U,V). This is normally no problem as the chroma (U,V) is usually well within the legal 16 .... 240 range. However it is possible that some YUV triplets - although all valid within the range - lead to out-of-gamut RGB (usually clipped, rarely folded-over R,G,B) when converted to RGB for viewing on a monitor. It materializes as loss of details for example, and (slight) color distortions which can however be corrected in post processing if need be - unless the capture is totally off the kilter.
Last but not least color tweaks are also a matter of personal preference which is not always in line with 'technical correctness'.

[Sharc]

Originally Posted by lansing

As for the video proc-amp in Hauppauge's device setting, is it the same thing as to running color correction filters in the post?

As long as Y and U,V are within their legal ranges ie. Y(16....235) and U,V (16 ....240) or even 0....255 for 8 bit, it should be possible to do all corrections in post, I think.
I don't believe that the device "proc-amp" does anything with the USB-live2 on its analog side of the video (the original meaning of proc-amp). It's all done after A/D conversion in the digital domain as I understand it. So I don't see a real difference between the "proc-amp" settings and post correction tweaks as long as the Hauppauge's A/D converter does not clip due to an excessive input signal level. If so (unlikely), one would probably have to use an external attenuator before the signal is fed into the Hauppauge USB-live2.
Maybe there are different opinions on that ....

My anime has blowout red that needs fixing, so I want to know the position of the device's proc-amp in the processing chain.

It has to be done experimentally with the help of the levels and/or RGB inspection and tweaks. Can you upload a sample, or at least post a .png snapshot of a critical frame?

[lansing]

Originally Posted by Sharc

As long as Y and U,V are within their legal ranges ie. Y(16....235) and U,V (16 ....240) or even 0....255 for 8 bit, it should be possible to do all corrections in post, I think.
I don't believe that the device "proc-amp" does anything with the USB-live2 on its analog side of the video (the original meaning of proc-amp). It's all done after A/D conversion in the digital domain as I understand it. So I don't see a real difference between the "proc-amp" settings and post correction tweaks as long as the Hauppauge's A/D converter does not clip due to an excessive input signal level. If so (unlikely), one would probably have to use an external attenuator before the signal is fed into the Hauppauge USB-live2.
Maybe there are different opinions on that ....


It has to be done experimentally with the help of the levels and/or RGB inspection and tweaks. Can you upload a sample, or at least post a .png snapshot of a critical frame?

sample here.

The image looks so saturated, but vectorscope was showing all color within legal range. The red channel was blowing up in the RGB parade in Davinci Resolve, but surprisingly it didn't clip and was recoverable with decreasing "color boost" or "saturation" parameter.

[Sharc]

Originally Posted by lansing

sample here.

The image looks so saturated, but vectorscope was showing all color within legal range. The red channel was blowing up in the RGB parade in Davinci Resolve, but surprisingly it didn't clip and was recoverable with decreasing "color boost" or "saturation" parameter.

Yes, legal YUV triplets translate into illegal RGB. For example many of the pinks are around YUV(190,126,167). With the 601 matrix these get converted to RGB(265,172,199) which is eventually clipped to RGB(255,172,199).
I don't know how DaVinci Resolve deals with it, but I would suggest to legalize the colors in Avisynth before taking the clip to an NLE, and only then do the fine color tweaks in the NLE in RGB color space. My point is as soon as the capture gets converted to RGB (e.g. by the NLE) the damage is already done, hence the first correction should be done in the YUV color space. But as I said, I don't know how DaVinci Resolve handles this, and the Gamut legalization step in Avisynth may not be required.

Also, I think the black level is high, e.g. the black background of the intro.

Here a proposal which 'legalizes' the colors and shifts the black level down:

SmoothTweak(contrast=0.95,saturation=0.7,HQ=true,TVrange=True, Limiter=False)
mergechroma(SmoothLevels(input_low=16,gamma=1.0,input_high=235,output_low=8,output_high=235,HQ=true,TVrange=True,Limiter=0),last) #black level adjusted with chroma copyback

Edit:
And b.t.w. the chroma really deserves some sharpening (not included in the script above).

[lansing]

The black level looks fine on the rgb parade



I compared the RGB Parade on both the NTSC_M and NTSC_M_J captures. The blown up red in NTSC_M_J was recoverable while the other one was permanently clipped.

NTSC_M_J before and after decreasing "color boost"


NTSC_M


Why?

[Sharc]

Did you capture lossless in YUV or RGB? The sample you posted was AVC reencoded, so that was YUV (YV12) but this doesn't tell how it was captured. If your capture (the .avi) got converted from YUV (S-Video) to RGB it is possible that you got out-of-gamut values which are irrecoverably lost.

The NTSC_M_J after decreasing "color boost" looks fine to me. No clipping, that's essential.
I don't use DaVinci but it looks like "color boost" tweaks the contrast and saturation (in avisynth terminology), very similar to what I suggested with my script.
You can judge yourself whether the black background of the intro is "black enough" or still a bit grayish.

Can you sharpen the chroma in DaVinci? The edges would look sharper with less color smear.

[lansing]

Color boost in Davinci Resolve is a saturation/saturation curve that affects more on higher saturation while not really touching the lower one.

My original capture is in Lagarith lossless. I converted to x264 because Resolve couldn't open it.


The thing I don't understand is why was the red in the NTSC_M_J version not clipped like the NTSC_M.

How do I sharpen the chroma?

[Sharc]

You could also capture in YUV (YUY2) 4:2:2 rather than RGB and significantly reduce the file size (but keep an eye on potential Gamut violations).

No idea why the NTSC_M messes with the red channel. (Is it really the same frames which you compare? or did you capture to a different color space?)

Chroma sharpening in Avisynth for example:

MergeChroma(last,Spline36Resize(last,width(last)/8*4, height(last)).aWarpSharp2(depth=20).Sharpen(0.4,0.4).nnedi3_rpow2(2, cshift="Spline36Resize", fwidth=width(last), fheight=height(last))) 
ChromaShiftSP(x=0.0,Y=1.0)  #adjust for best luma/chroma fit

[lansing]

Oddly I couldn't reproduce the clipping anymore on my new test captures. The blown up red on both NTSC_M and NTSC_M_J versions are recoverable now. So it seems like color adjustment can be done after the conversion without problem.

Switching RGB mode in Lagarith setting to YUY2 mode makes no difference in file size.

Another thing I found is that if I load in my original capture Lagarith file and run ConvertToYV12(), the default "interlaced=false" parameter will cause chroma ghosting.

AVISource("source.avi")
ConvertToYV12(interlaced=false)
tfm()
tdecimate()

[Sharc]

Originally Posted by lansing

Switching RGB mode in Lagarith setting to YUY2 mode makes no difference in file size.

I would have expected a smaller .avi file size in YUY2 due to the color subsampling. I made a few tests: the pixel format of the captured stream seems always to be YUV (e.g. yuv422p), even for RGB mode in Lagarith. This would explain why the filesize is the same for RGB and YUY2 mode selection; it's always YUV for S-video or composite signals, which is fine - unless you want to capture Component.

Another thing I found is that if I load in my original capture Lagarith file and run ConvertToYV12(), the default "interlaced=false" parameter will cause chroma ghosting.

One should capture VHS (VCR output signals) as interlaced and specify 'interlaced=true' when converting, because VHS is natively interlaced, even if the source is telecined or PsF. The header of the standard .avi container has however no flag to indicate "interlaced", therefore one has to state it explicitely. One may also want to specify the conversion matrix, although the default "Rec601" (for SD, based on vertical resolution) is fine.

(P.S. I just noticed that your uploaded telecined sample (x264 encoded YV12) has been encoded as progressive. It should have been encoded as interlaced, I think.)

[Sharc]

Originally Posted by lansing

Oddly I couldn't reproduce the clipping anymore on my new test captures. The blown up red on both NTSC_M and NTSC_M_J versions are recoverable now. So it seems like color adjustment can be done after the conversion without problem.

Maybe the red clipping oddity happens for the first frame after the intro only? There seems to be some transition effect (fade-in, telecined).

[lansing]

Originally Posted by Sharc

One should capture VHS (VCR output signals) as interlaced and specify 'interlaced=true' when converting, because VHS is natively interlaced, even if the source is telecined or PsF. The header of the standard .avi container has however no flag to indicate "interlaced", therefore one has to state it explicitely. One may also want to specify the conversion matrix, although the default "Rec601" (for SD, based on vertical resolution) is fine.

(P.S. I just noticed that your uploaded telecined sample (x264 encoded YV12) has been encoded as progressive. It should have been encoded as interlaced, I think.)

Yes, the x264 sample was inherently converted to yv12 by the encoder. Though the "interlaced" parameter seems to only affect the output of yv12. There is no chroma ghosting when I convert to YUV422 or YUV444

ConvertToYUV422(interlaced=false)
tfm()
TDecimate()

[Sharc]

Originally Posted by lansing

Yes, the x264 sample was inherently converted to yv12 by the encoder. Though the "interlaced" parameter seems to only affect the output of yv12. There is no chroma ghosting when I convert to YUV422 or YUV444

ConvertToYUV422(interlaced=false)
tfm()
TDecimate()

I assume your captured .avi is already YUV 4:2:2, interlaced. So converttoYUV422(interlaced=true) has no effect. ConverttoYUV422(interlaced=false) mixes the croma between fields when you put it before the IVTC I am afraid. I don't see that it eliminates the residual ghosting, but as I have only your YV12 progressively re-encoded AVC version I can't tell for sure.
Add santiag() or vinverse() after TDecimate if you see residual combing.

[lansing]

Originally Posted by Sharc

I assume your captured .avi is already YUV 4:2:2, interlaced. So converttoYUV422(interlaced=true) has no effect. ConverttoYUV422(interlaced=false) mixes the croma between fields when you put it before the IVTC I am afraid. I don't see that it eliminates the residual ghosting, but as I have only your YV12 progressively re-encoded AVC version I can't tell for sure.
Add santiag() or vinverse() after TDecimate if you see residual combing.

Here's a sample of the original capture to play around

[Sharc]

Originally Posted by lansing

Here's a sample of the original capture to play around

Do you still see the same ghosting with this?
https://www.mediafire.com/file/xd12x...sing3.mp4/file

P.S.
For capturing one should normally switch NR (noise reduction filters) off (VCR, DVD-recorder passthrough device), as these filters may cause ghosting. It is usually better to make the noise reduction in post processing.

[lansing]

Originally Posted by Sharc

Do you still see the same ghosting with this?

What I'm saying is ConvertTOYV12(interlaced=false) behaves differently from ConvertTOYUV422(interlaced=false) or ConvertTOYUV444(interlaced=false), where the latter two don't produce chroma ghosting.

[Sharc]

Originally Posted by lansing

What I'm saying is ConvertTOYV12(interlaced=false) behaves differently from ConvertTOYUV422(interlaced=false) or ConvertTOYUV444(interlaced=false), where the latter two don't produce chroma ghosting.

The pixel format of your uploaded .avi is yuv422p means 4:2:2 subsampled. ConverttoYV12 halves the vertical chroma resolution (4:2:0). Interlace=false may however apply because the underlying video is telecined rather than true interlaced, i.e. there is no motion between fields.

[jefix]

I'm sorry if I'm asking in the wrong place. I would like to know at what point should I use NeatVideo noise reduction? Do I need to de-interlace first?
I think I need to do noise reduction before de-interlacing. Is this true?

[Sharc]

I don't know NeatVideo filters, but usually one would deinterlace before noise filtering. Few noise filters do have an "interlace-aware" setting though which typically means that they filter even and odd fields separately and then reinterlace.
Spatial and temporal filters also behave differently. When in doubt I would just deinterlace first.

[jefix]

Sharc, I think I can open the file in Adobe as interlaced.