Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Capturing Video

Reply
 
Thread Tools Search this Thread Display Modes
Old 4th April 2022, 08:12   #61  |  Link
Sharc
Registered User
 
Join Date: May 2006
Posts: 3,920
Quote:
Originally Posted by lansing View Post
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'.

Last edited by Sharc; 4th April 2022 at 09:32.
Sharc is offline   Reply With Quote
Old 4th April 2022, 08:55   #62  |  Link
Sharc
Registered User
 
Join Date: May 2006
Posts: 3,920
Quote:
Originally Posted by lansing View Post
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 ....

Quote:
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?

Last edited by Sharc; 4th April 2022 at 09:33.
Sharc is offline   Reply With Quote
Old 5th April 2022, 00:05   #63  |  Link
lansing
Registered User
 
Join Date: Sep 2006
Posts: 1,616
Quote:
Originally Posted by Sharc View 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 ....


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.
lansing is offline   Reply With Quote
Old 5th April 2022, 08:37   #64  |  Link
Sharc
Registered User
 
Join Date: May 2006
Posts: 3,920
Quote:
Originally Posted by lansing View Post
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:
Code:
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).

Last edited by Sharc; 5th April 2022 at 10:17.
Sharc is offline   Reply With Quote
Old 5th April 2022, 21:16   #65  |  Link
lansing
Registered User
 
Join Date: Sep 2006
Posts: 1,616
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?
lansing is offline   Reply With Quote
Old 5th April 2022, 22:26   #66  |  Link
Sharc
Registered User
 
Join Date: May 2006
Posts: 3,920
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.

Last edited by Sharc; 8th April 2022 at 10:38.
Sharc is offline   Reply With Quote
Old 5th April 2022, 23:04   #67  |  Link
lansing
Registered User
 
Join Date: Sep 2006
Posts: 1,616
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?
lansing is offline   Reply With Quote
Old 5th April 2022, 23:11   #68  |  Link
Sharc
Registered User
 
Join Date: May 2006
Posts: 3,920
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:
Code:
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

Last edited by Sharc; 6th April 2022 at 09:35. Reason: Added ChromaShift in the script
Sharc is offline   Reply With Quote
Old 6th April 2022, 04:35   #69  |  Link
lansing
Registered User
 
Join Date: Sep 2006
Posts: 1,616
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.

Code:
AVISource("source.avi")
ConvertToYV12(interlaced=false)
tfm()
tdecimate()
lansing is offline   Reply With Quote
Old 6th April 2022, 07:56   #70  |  Link
Sharc
Registered User
 
Join Date: May 2006
Posts: 3,920
Quote:
Originally Posted by lansing View Post
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.
Quote:
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.)

Last edited by Sharc; 6th April 2022 at 14:39.
Sharc is offline   Reply With Quote
Old 6th April 2022, 08:20   #71  |  Link
Sharc
Registered User
 
Join Date: May 2006
Posts: 3,920
Quote:
Originally Posted by lansing View Post
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).

Last edited by Sharc; 6th April 2022 at 14:02.
Sharc is offline   Reply With Quote
Old 6th April 2022, 17:22   #72  |  Link
lansing
Registered User
 
Join Date: Sep 2006
Posts: 1,616
Quote:
Originally Posted by Sharc View Post

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
Code:
ConvertToYUV422(interlaced=false)
tfm()
TDecimate()
lansing is offline   Reply With Quote
Old 6th April 2022, 22:40   #73  |  Link
Sharc
Registered User
 
Join Date: May 2006
Posts: 3,920
Quote:
Originally Posted by lansing View Post
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
Code:
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.

Last edited by Sharc; 6th April 2022 at 22:57.
Sharc is offline   Reply With Quote
Old 7th April 2022, 00:14   #74  |  Link
lansing
Registered User
 
Join Date: Sep 2006
Posts: 1,616
Quote:
Originally Posted by Sharc View Post
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
lansing is offline   Reply With Quote
Old 7th April 2022, 10:47   #75  |  Link
Sharc
Registered User
 
Join Date: May 2006
Posts: 3,920
Quote:
Originally Posted by lansing View Post
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.

Last edited by Sharc; 7th April 2022 at 15:25.
Sharc is offline   Reply With Quote
Old 7th April 2022, 17:26   #76  |  Link
lansing
Registered User
 
Join Date: Sep 2006
Posts: 1,616
Quote:
Originally Posted by Sharc View Post
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.
lansing is offline   Reply With Quote
Old 7th April 2022, 22:53   #77  |  Link
Sharc
Registered User
 
Join Date: May 2006
Posts: 3,920
Quote:
Originally Posted by lansing View Post
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.

Last edited by Sharc; 12th April 2022 at 07:39.
Sharc is offline   Reply With Quote
Old 13th July 2022, 10:37   #78  |  Link
jefix
Simple User
 
jefix's Avatar
 
Join Date: Jul 2022
Posts: 5
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?
jefix is offline   Reply With Quote
Old 13th July 2022, 13:20   #79  |  Link
Sharc
Registered User
 
Join Date: May 2006
Posts: 3,920
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.
Sharc is offline   Reply With Quote
Old 13th July 2022, 14:47   #80  |  Link
jefix
Simple User
 
jefix's Avatar
 
Join Date: Jul 2022
Posts: 5
Sharc, I think I can open the file in Adobe as interlaced.
jefix is offline   Reply With Quote
Reply

Tags
capture card, vhs capture

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 18:50.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2022, vBulletin Solutions Inc.