Strange ghosting/after image effect after VHS capture

[wubikens]

Hi, I just finishing doing a few captures of a VHS tape, and was hoping to do some filtering via VirtualDub. I've included some pictures of an issue I've ran into. If you look at pictures 1 and 2 back to back, it should be pretty noticeable. The same effect can be seen above the flipping guy in picture 3. There is a slight discoloration that appears to be an after-image. I've included a few frames as attachments. I was wondering what this issue in particular was, and if there was a filter that could solve it?

It seems to be a "temporal" issue, I think? I'm using the "temporal smoother" filter in VirtualDub and I can see noticeable changes in the after-image effect. Although it doesn't seem to necessarily improve it, it just seems to move it around. Any recommendations on filters to improve the temporal effect? The "temporal cleaner" filter doesn't seem to do anything at all, though.

I'd also welcome any feedback for additional filters that I should be on the lookout to use.

Thank you so much!

[wubikens]

I think I see what the issue is. I used ITVC on my source because it had blending issues, but the frames that had blending issues went from that to this ghosting issue. IVTC definitely made it look better, but is there a way to apply that without getting this ghosting problem?

[davexnet]

Provide a short clip cut from your original capture and post it here in the thread

[DTL2023]

It looks like wrong conversion of 4:2:2 or 4:4:4 to 4:2:0 (progressive instead of interlaced). Maybe error in conversion filter or settings.

Example in AVS:
ConvertToYV12(interlaced=true) - correct
ConvertToYV12(interlaced=false) - wrong with such chroma ghosting at moving areas.

[lollo]

To OP, as davexnet said, provide a sample of the original untouched capture

[wubikens]

Provide a short clip cut from your original capture and post it here in the thread

It looks like wrong conversion of 4:2:2 or 4:4:4 to 4:2:0 (progressive instead of interlaced). Maybe error in conversion filter or settings.

Example in AVS:
ConvertToYV12(interlaced=true) - correct
ConvertToYV12(interlaced=false) - wrong with such chroma ghosting at moving areas.

To OP, as davexnet said, provide a sample of the original untouched capture

Thank you all for being willing to take a look! I went ahead and attached a 10 sec clip of the original capture, during a high-motion scene.

[jagabo]

It looks like a strong temporal filter has blended the chroma. Try capturing again with the VCR's noise reduction turned off. But the blending may (also) be from a frame rate conversion or other problems before it was recorded onto VHS.

[wubikens]

It looks like a strong temporal filter has blended the chroma. Try capturing again with the VCR's noise reduction turned off. But the blending may (also) be from a frame rate conversion or other problems before it was recorded onto VHS.

Ah, gotcha. I'm using a JVC S7900U and I have most of those types of features set to "OFF" (stabilization, R3, etc). I think the only NR that may be occurring is from the picture mode being set to "NORM", but I believe the only other one I could try would be "EDIT", which I've seen people advise against using?

[lollo]

but I believe the only other one I could try would be "EDIT", which I've seen people advise against using?

We always have different opinions on "edit" mode, because often it depends on the source. Try both and compare!

edit: a link of mine on croma gosting in JVC VCRs: https://forum.videohelp.com/threads/401232-JVC-S-VHS-settings-for-capture-%28again%29 you can find others in the forum, https://forum.videohelp.com/threads/395451-Chroma-mess for example

[jagabo]

My general opinion is that you want the (S)VHS player to do as little processing as possible -- only time base correction if possible. Then do all your cleanup in AviSynth which has much more advanced techniques, offers much more control, and gives you a wide choice of filters.

If you get rid of the chroma ghosting from the playback deck you might have better luck removing the ghosting from the frame rate conversion with SResotre() in AviSynth.

[DTL2023]

"10 sec clip.avi (60.93 MB, 6 views)"

It looks like wrong frame-rate conversion of animation to 30fps NTSC. It is a mix of interlaced and progressive frames and some progressive frames has residuals of chroma fields from previous frames. If it is the only source available - may be only complex attempt of IVTC with attempt of bad chroma subtraction may help somehow. Or better to look for better quality source.

[wubikens]

but I believe the only other one I could try would be "EDIT", which I've seen people advise against using?

We always have different opinions on "edit" mode, because often it depends on the source. Try both and compare!

edit: a link of mine on croma gosting in JVC VCRs: https://forum.videohelp.com/threads/401232-JVC-S-VHS-settings-for-capture-%28again%29 you can find others in the forum, https://forum.videohelp.com/threads/395451-Chroma-mess for example

Gotcha, I went ahead and did another capture in EDIT mode. Results look to be the same, however. I'll upload a clip.

My general opinion is that you want the (S)VHS player to do as little processing as possible -- only time base correction if possible. Then do all your cleanup in AviSynth which has much more advanced techniques, offers much more control, and gives you a wide choice of filters.

If you get rid of the chroma ghosting from the playback deck you might have better luck removing the ghosting from the frame rate conversion with SResotre() in AviSynth.

Gotcha, yeah my deck has TBC enabled on all my captures. I went ahead and put it into EDIT mode for another capture, but it seems the effect is still occurring.

"10 sec clip.avi (60.93 MB, 6 views)"

It looks like wrong frame-rate conversion of animation to 30fps NTSC. It is a mix of interlaced and progressive frames and some progressive frames has residuals of chroma fields from previous frames. If it is the only source available - may be only complex attempt of IVTC with attempt of bad chroma subtraction may help somehow. Or better to look for better quality source.

For this source, it was only released on VHS. But I did purchase two new/unused copies still in the shrink wrap, so they were never played before I started capturing on them. Although it looks like it happens on both tapes.

I did stumble across AnimeITVC: http://avisynth.nl/index.php/AnimeIVTC

I got this working and have been trying to minimize the effects as much as possible. I can get rid of the horizontal interlacing effect, but then the chroma/ghosting thing just takes its place. The chroma/ghosting is a lot less noticeable than the horizontal lines, at least.

[jagabo]

The edit mode clip has less chroma ghosting. Side by side after QTGMC(preset="fast").SRestore():

v1 = LWLibavVideoSource("10 sec clip.avi", cache=false, prefer_hw=2).AssumeTFF()
v2 = LWLibavVideoSource("10 sec clip in edit mode.avi", cache=false, prefer_hw=2).AssumeTFF()

v1 = QTGMC(v1, preset="fast").SRestore().Subtitle("Norm")
v2 = QTGMC(v2, preset="fast").SRestore().Subtitle("Edit")

StackHorizontal(v1, v2)

[lollo]

but I believe the only other one I could try would be "EDIT", which I've seen people advise against using?

We always have different opinions on "edit" mode, because often it depends on the source. Try both and compare!

edit: a link of mine on croma gosting in JVC VCRs: https://forum.videohelp.com/threads/401232-JVC-S-VHS-settings-for-capture-%28again%29 you can find others in the forum, https://forum.videohelp.com/threads/395451-Chroma-mess for example

Gotcha, I went ahead and did another capture in EDIT mode. Results look to be the same, however. I'll upload a clip.

No, as jagabo already pointed out, there is a difference: https://imgsli.com/MjU4NzIy

[wubikens]

but I believe the only other one I could try would be "EDIT", which I've seen people advise against using?

We always have different opinions on "edit" mode, because often it depends on the source. Try both and compare!

edit: a link of mine on croma gosting in JVC VCRs: https://forum.videohelp.com/threads/401232-JVC-S-VHS-settings-for-capture-%28again%29 you can find others in the forum, https://forum.videohelp.com/threads/395451-Chroma-mess for example

Gotcha, I went ahead and did another capture in EDIT mode. Results look to be the same, however. I'll upload a clip.

No, as jagabo already pointed out, there is a difference: https://imgsli.com/MjU4NzIy

The edit mode clip has less chroma ghosting. Side by side after QTGMC(preset="fast").SRestore():

v1 = LWLibavVideoSource("10 sec clip.avi", cache=false, prefer_hw=2).AssumeTFF()
v2 = LWLibavVideoSource("10 sec clip in edit mode.avi", cache=false, prefer_hw=2).AssumeTFF()

v1 = QTGMC(v1, preset="fast").SRestore().Subtitle("Norm")
v2 = QTGMC(v2, preset="fast").SRestore().Subtitle("Edit")

StackHorizontal(v1, v2)

Ah you're both right, looking side by side, I can definitely see the difference. Thank you for pointing it out!

Would it be alright if I asked a few follow up questions?

I noticed that the QTGMC Restore function seems to do the same thing as the ITVC I've been applying (specifically AnimeITVC mode=1). Do they perform a similar function?

Secondly, I've uploaded another picture (from the EDIT capture). On the left is the clip before the Restore function is called, and the one on the right is after Restore is called. Is the "bleeding/ghosting" effect that gets left behind after a Restore/ITVC is performed just some unavoidable chroma/bleeding due to the source?

[jagabo]

There are differences between TFM().TDecimate() (apparently what AnimeIVTC does) and QTGMC().SRestore(). One of the biggest being that TDecimate() removes identical (or the most similar) frames when decimating, whereas SRestore() removes the frames with the most blending. So SRestore() tends to remove blended frame, TDecimate() tends to keep them.

Another thing to keep in mind is that SRestore() often takes a while to lock into a pattern. If you seek to a random frame you will usually see something different than when you seek to an earlier fame and move frame by frame to that same frame.

[wubikens]

There are differences between TFM().TDecimate() (apparently what AnimeIVTC does) and QTGMC().SRestore(). One of the biggest being that TDecimate() removes identical (or the most similar) frames when decimating, whereas SRestore() removes the frames with the most blending. So SRestore() tends to remove blended frame, TDecimate() tends to keep them.

Another thing to keep in mind is that SRestore() often takes a while to lock into a pattern. If you seek to a random frame you will usually see something different than when you seek to an earlier fame and move frame by frame to that same frame.

Oh interesting, thank you so much for explaining! So it sounds like for this specific issue, the Restore function would be the way to go, over AnimeIVTC.

[jagabo]

Also, TFM() is a primarily a field matcher. It stars with one field, then looks at the prior and next fields. It picks whichever one delivers the fewest comb artifacts when combined with the current field. If it detects any residual combing it deinterlaces those areas. The result is the same frame rate as the source.

QTMGC() is primarily a double frame rate deinterlacer. It starts with something like TFM() but does it for each field. The result is double the frame rate of the source. After that matching it uses more sophisticated methods of deinterlacing to remove residual combing. This is better for SRestore() as you have twice as many choices of frames to work with; SRestore() is more likely to find blended frames to remove and more likely to leave only unblended frames.

[wubikens]

Also, TFM() is a primarily a field matcher. It stars with one field, then looks at the prior and next fields. It picks whichever one delivers the fewest comb artifacts when combined with the current field. If it detects any residual combing it deinterlaces those areas. The result is the same frame rate as the source.

QTMGC() is primarily a double frame rate deinterlacer. It starts with something like TFM() but does it for each field. The result is double the frame rate of the source. After that matching it uses more sophisticated methods of deinterlacing to remove residual combing. This is better for SRestore() as you have twice as many choices of frames to work with; SRestore() is more likely to find blended frames to remove and more likely to leave only unblended frames.

Oh interesting, so it's not only a less destructive process, but it's a lot more careful and precise as well. Thank you so much again for the explanation!

"10 sec clip.avi (60.93 MB, 6 views)"

It looks like wrong frame-rate conversion of animation to 30fps NTSC. It is a mix of interlaced and progressive frames and some progressive frames has residuals of chroma fields from previous frames. If it is the only source available - may be only complex attempt of IVTC with attempt of bad chroma subtraction may help somehow. Or better to look for better quality source.

I also wanted to ask, could this be an issue with my capturing process? I've been capturing in VirtualDub with it set to NTSC_M_J @ 29.970 FPS. Should I be setting those to other values? The tape itself is NTSC (Japan).

[jagabo]

(TFM vs QTGMC) Oh interesting, so it's not only a less destructive process, but it's a lot more careful and precise as well.

For normal telecined video (without blending) TFM is usually better than QTGMC because there's always a pair of matching fields. For this field-blended video QTGMC() is better.

[wubikens]

(TFM vs QTGMC) Oh interesting, so it's not only a less destructive process, but it's a lot more careful and precise as well.

For normal telecined video (without blending) TFM is usually better than QTGMC because there's always a pair of matching fields. For this field-blended video QTGMC() is better.

Ah, gotcha. Yeah the results look amazing. I went ahead and used that script on the entire video file, but I noticed that it seems to be causing some "stuttering" at certain points in the video now. Could that be because of the doubling of the frame rate? I'll include a short clip. If you keep an eye on the giant fish, you should see some stuttering as it moves.

[jagabo]

That is a field order issue. Are you sure you included the AssumeTFF() calls at the end of the LWlibavVideoSource() lines?

[wubikens]

That is a field order issue. Are you sure you included the AssumeTFF() calls at the end of the LWlibavVideoSource() lines?

Oh crap! I did not. That was my mistake, I apologize. Thank you for catching that. I'll update the script with those fields.

[wubikens]

That is a field order issue. Are you sure you included the AssumeTFF() calls at the end of the LWlibavVideoSource() lines?

I apologize for bugging you again, I know this is off-topic from the original intent of the thread I posted, but I was doing additional research into restoring the footage now that this field-blending issue is taken care of, and I ran into a post you made back in 2014: https://forum.videohelp.com/threads/362895-VHS-Anime-to-DVD-in-Virtualdub#post2306889

I gave your script a try and I think it worked beautifully for my video as well. Personally, I think it breathed new life into it, but I'm no expert, and I know this script was originally written for the other person's video in mind. For the video I'll upload, would you change any particular settings from the original script you wrote back then?

Also, I wanted to ask: I noticed that after using the script with the AssumeTFF and QTGMC's SRestore functions there seems to be a slight stuttering during some scenes involving motion that wasn't present in the original lossless file. It's noticeable in the video I'll upload as well, particularly during the pan up on the tree. I was wondering, was that stuttering introduced as a result of the AssumeTFF/Srestore functions? Or was that stuttering always there, and only became more noticeable as a result of using those functions? Just to see what would happen, I ran TFM().TDecimate() on the source and noticed the stuttering does not occur then.

I should also probably mention, this stuttering is different from the other one I was seeing, when I forgot to add AssumeTFF.

Thank you so much again! Your help in this thread and all of the other threads I've found in my research has been invaluable.

[jagabo]

I can't really say what's causing the stuttering. I'd have to see the source to get a better idea.

Try this script after QTGMC/SRestore process:

LWLibavVideoSource("QTGMC Srestore Only.avi", cache=false, prefer_hw=2) 
ConvertToYV12()

ColorYUV(gain_y=90, off_y=-55, gamma_y=50, cont_u=90, cont_v=90).ColorYUV(levels="PC->TV")

ConvertToRGB(matrix="rec601")
RGBAdjust(r=203.0/237.0, b=203.0/237.0, bb=-9)
ConvertToYV12()

FineDehalo(rx=2.5, ry=2.5, brightstr=1.0, darkstr=1.0, thmi=40, thma=80)
MergeChroma(aWarpSharp2(depth=5).Sharpen(0.5, 0.0), aWarpSharp2(20).ChromaShiftSP(x=-3))
SMDegrain(thsad=100, tr=2, prefilter=4, plane=0)

before, after:

[Attachment 78655 - Click to enlarge]

I pulled the black level down more, and increased the gamma to bring out more shadow detail. There weren't a lot of full blacks and full whites so I had to guess with the levels and white balance.

[wubikens]

I can't really say what's causing the stuttering. I'd have to see the source to get a better idea.

Try this script after QTGMC/SRestore process:

LWLibavVideoSource("QTGMC Srestore Only.avi", cache=false, prefer_hw=2) 
ConvertToYV12()

ColorYUV(gain_y=90, off_y=-55, gamma_y=50, cont_u=90, cont_v=90).ColorYUV(levels="PC->TV")

ConvertToRGB(matrix="rec601")
RGBAdjust(r=203.0/237.0, b=203.0/237.0, bb=-9)
ConvertToYV12()

FineDehalo(rx=2.5, ry=2.5, brightstr=1.0, darkstr=1.0, thmi=40, thma=80)
MergeChroma(aWarpSharp2(depth=5).Sharpen(0.5, 0.0), aWarpSharp2(20).ChromaShiftSP(x=-3))
SMDegrain(thsad=100, tr=2, prefilter=4, plane=0)

before, after:

[Attachment 78655 - Click to enlarge]

I pulled the black level down more, and increased the gamma to bring out more shadow detail. There weren't a lot of full blacks and full whites so I had to guess with the levels and white balance.

For sure! I've uploaded a clip of the tree panning up from the lossless source. Thanks for taking time out to keep looking at it, and for those new filter values.

Quick question though, I'm getting an error on FineDehalo's "mt_expand_multi" function. Do you know which plugin that belongs to? I tried to google it, and it came back as MaskTools2, which I added to my AviSynth plugins folder, but VirtualDub is still complaining. I can see in the AviSynth documentation for MaskTools2 that it does have a function called "mt_expand", but not "mt_expand_multi".

[jagabo]

I don't remember where it comes from, but here's what I have in mt_xxpand_multi.avsi:

# This program is free software. It comes without any warranty, to
# the extent permitted by applicable law. You can redistribute it
# and/or modify it under the terms of the Do What The **** You Want
# To Public License, Version 2, as published by Sam Hocevar. See
# http://sam.zoy.org/wtfpl/COPYING for more details.

#=============================================================================
#	mt_expand_multi
#	mt_inpand_multi
#
#	Calls mt_expand or mt_inpand multiple times in order to grow or shrink
#	the mask from the desired width and height.
#
#	Parameters:
#	- sw   : Growing/shrinking shape width. 0 is allowed. Default: 1
#	- sh   : Growing/shrinking shape height. 0 is allowed. Default: 1
#	- mode : "rectangle" (default), "ellipse" or "losange". Replaces the
#		mt_xxpand mode. Ellipses are actually combinations of
#		rectangles and losanges and look more like octogons.
#		Losanges are truncated (not scaled) when sw and sh are not
#		equal.
#	Other parameters are the same as mt_xxpand.
#=============================================================================

Function mt_expand_multi (clip src, int "thY", int "thC", string "mode",
\	int "offx", int "offy", int "w", int "h", int "y", int "u", int "v",
\	string "chroma", int "sw", int "sh")
{
	sw   = Default (sw, 1)
	sh   = Default (sh, 1)
	mode = Default (mode, "rectangle")

	mode_m =
\	  (sw > 0 && sh > 0) ? (
\		  (mode == "losange" || (mode == "ellipse" && (sw % 3) != 1))
\		? "both" : "square"
\	                       )
\	: (sw > 0          ) ? "horizontal"
\	: (          sh > 0) ? "vertical"
\	:                      ""

	(mode_m != "") ? src.mt_expand (
\		thY=thY, thC=thC, mode=mode_m,
\		offx=offx, offy=offy, w=w, h=h, y=y, u=u, v=v, chroma=chroma
\	).mt_expand_multi (
\		thY=thY, thC=thC, mode=mode,
\		offx=offx, offy=offy, w=w, h=h, y=y, u=u, v=v, chroma=chroma,
\		sw=sw-1, sh=sh-1
\	) : src
}

Function mt_inpand_multi (clip src, int "thY", int "thC", string "mode",
\	int "offx", int "offy", int "w", int "h", int "y", int "u", int "v",
\	string "chroma", int "sw", int "sh")
{
	sw   = Default (sw, 1)
	sh   = Default (sh, 1)
	mode = Default (mode, "rectangle")

	mode_m =
\	  (sw > 0 && sh > 0) ? (
\		  (mode == "losange" || (mode == "ellipse" && (sw % 3) != 1))
\		? "both" : "square"
\	                       )
\	: (sw > 0          ) ? "horizontal"
\	: (          sh > 0) ? "vertical"
\	:                      ""

	(mode_m != "") ? src.mt_inpand (
\		thY=thY, thC=thC, mode=mode_m,
\		offx=offx, offy=offy, w=w, h=h, y=y, u=u, v=v, chroma=chroma
\	).mt_inpand_multi (
\		thY=thY, thC=thC, mode=mode,
\		offx=offx, offy=offy, w=w, h=h, y=y, u=u, v=v, chroma=chroma,
\		sw=sw-1, sh=sh-1
\	) : src
}

Regarding the clip, it looks like the correct frame rate should be 23.976, not 25. That may be the correct frame rate for the other clips too -- they didn't have long enough panning shots to say before. There's something about the latest clip that confuses the QTGMC/SRestore sequence. This seems to clean it up and give a nice smooth result (well, as smooth as 24 fps ever is):

LWLibavVideoSource("Source Capture.avi", cache=false, prefer_hw=2) 
AssumeTFF()

QTGMC(SourceMatch=3, Lossless=2)
SRestore(frate=24000.0/1001.0) # restore to 23.976 fps

prefetch(8)

[wubikens]

I don't remember where it comes from, but here's what I have in mt_xxpand_multi.avsi:

# This program is free software. It comes without any warranty, to
# the extent permitted by applicable law. You can redistribute it
# and/or modify it under the terms of the Do What The **** You Want
# To Public License, Version 2, as published by Sam Hocevar. See
# http://sam.zoy.org/wtfpl/COPYING for more details.

#=============================================================================
#	mt_expand_multi
#	mt_inpand_multi
#
#	Calls mt_expand or mt_inpand multiple times in order to grow or shrink
#	the mask from the desired width and height.
#
#	Parameters:
#	- sw   : Growing/shrinking shape width. 0 is allowed. Default: 1
#	- sh   : Growing/shrinking shape height. 0 is allowed. Default: 1
#	- mode : "rectangle" (default), "ellipse" or "losange". Replaces the
#		mt_xxpand mode. Ellipses are actually combinations of
#		rectangles and losanges and look more like octogons.
#		Losanges are truncated (not scaled) when sw and sh are not
#		equal.
#	Other parameters are the same as mt_xxpand.
#=============================================================================

Function mt_expand_multi (clip src, int "thY", int "thC", string "mode",
\	int "offx", int "offy", int "w", int "h", int "y", int "u", int "v",
\	string "chroma", int "sw", int "sh")
{
	sw   = Default (sw, 1)
	sh   = Default (sh, 1)
	mode = Default (mode, "rectangle")

	mode_m =
\	  (sw > 0 && sh > 0) ? (
\		  (mode == "losange" || (mode == "ellipse" && (sw % 3) != 1))
\		? "both" : "square"
\	                       )
\	: (sw > 0          ) ? "horizontal"
\	: (          sh > 0) ? "vertical"
\	:                      ""

	(mode_m != "") ? src.mt_expand (
\		thY=thY, thC=thC, mode=mode_m,
\		offx=offx, offy=offy, w=w, h=h, y=y, u=u, v=v, chroma=chroma
\	).mt_expand_multi (
\		thY=thY, thC=thC, mode=mode,
\		offx=offx, offy=offy, w=w, h=h, y=y, u=u, v=v, chroma=chroma,
\		sw=sw-1, sh=sh-1
\	) : src
}

Function mt_inpand_multi (clip src, int "thY", int "thC", string "mode",
\	int "offx", int "offy", int "w", int "h", int "y", int "u", int "v",
\	string "chroma", int "sw", int "sh")
{
	sw   = Default (sw, 1)
	sh   = Default (sh, 1)
	mode = Default (mode, "rectangle")

	mode_m =
\	  (sw > 0 && sh > 0) ? (
\		  (mode == "losange" || (mode == "ellipse" && (sw % 3) != 1))
\		? "both" : "square"
\	                       )
\	: (sw > 0          ) ? "horizontal"
\	: (          sh > 0) ? "vertical"
\	:                      ""

	(mode_m != "") ? src.mt_inpand (
\		thY=thY, thC=thC, mode=mode_m,
\		offx=offx, offy=offy, w=w, h=h, y=y, u=u, v=v, chroma=chroma
\	).mt_inpand_multi (
\		thY=thY, thC=thC, mode=mode,
\		offx=offx, offy=offy, w=w, h=h, y=y, u=u, v=v, chroma=chroma,
\		sw=sw-1, sh=sh-1
\	) : src
}

Regarding the clip, it looks like the correct frame rate should be 23.976, not 25. That may be the correct frame rate for the other clips too -- they didn't have long enough panning shots to say before. There's something about the latest clip that confuses the QTGMC/SRestore sequence. This seems to clean it up and give a nice smooth result (well, as smooth as 24 fps ever is):

LWLibavVideoSource("Source Capture.avi", cache=false, prefer_hw=2) 
AssumeTFF()

QTGMC(SourceMatch=3, Lossless=2)
SRestore(frate=24000.0/1001.0) # restore to 23.976 fps

prefetch(8)

Thank you so much! Adding that .avsi did the trick and the QTGMC changes worked beautifully, too!

I went ahead and gave those color adjustments a try as well, and I'll probably have to experiment and tweak things a bit on some full black/white scenes (went ahead and uploaded a couple screenshots). The adjustments definitely looked great during the scenes in that clip, but yeah, during a full white scene it had a bit of a green~ish hue. I can definitely do that on my own though for a bit!

One last question if that's okay, regarding the ColorYUV(TV->PC) and ColorYUV(PC->TV) settings. I've experimented with both, and while TV->PC makes it a little too vivid, PC->TV by itself actually looks really good (at least to my amateur/untrained eye). The colors are a little more vibrant, but not too much. Would there be any issues in just using that setting by itself, without any sort of other adjustments? I'm trying to understand the documentation and look stuff up, but it's a bit over my head.

[jagabo]

Yes, the white balance does't look appropriate for that shot.

One last question if that's okay, regarding the ColorYUV(TV->PC) and ColorYUV(PC->TV) settings. I've experimented with both, and while TV->PC makes it a little too vivid, PC->TV by itself actually looks really good

PC->TV would make that shot look really washed out. Don't you think the dark areas should be near black (RGB 0,0,0) and the light areas near full white (RGB 255,255,255)? More like this?


[Attachment 78665 - Click to enlarge]

That was with Levels(50, 1.0, 190, 16, 235, coring=false). But two calls to ColorYUV(levels="TV->PC") comes close.

[jagabo]

Do you know how to use a waveform monitor? Ie, Histogram() in AviSynth.

https://forum.videohelp.com/threads/340804-colorspace-conversation-elaboration#post2121568

Also make sure your system is at least rough calibrated:

https://forum.videohelp.com/threads/374734-Superblacks-and-superwhites-question#post2414529