Color flicker after QTGMC deinterlace? - digitalFAQ Forum
 Forum Color flicker after QTGMC deinterlace?
 Ask Question Join / Register FAQ Search Today's Posts Mark Forums Read

#1
03-17-2017, 06:15 PM
 mrb5217 Free Member Join Date: Jan 2017 Posts: 8 Thanked 0 Times in 0 Posts
When using QTGMC to deinterlace an interlaced VHS capture, I'm getting color flicker (almost like a change in white balance) between alternating frames on any setting other than "Draft".

Simple AVISynth Script:
Code:
AVISource("S:\flicker\02-hsv.avi")
AssumeTFF()
ConvertToYV12(interlaced=true)

QTGMC( Preset="Slow" )
Examples attached:
01-original.avi - Trimmed interlaced original footage directly from capture
02-hsv - Hue/Saturation tweak with virtualdub, interlaced
03-qtgmc-short - Opened the avisynth script above in virtualdub (run through QTGMC), fast recompressed with huffyuv and trimmed to 5sec to make it under the 99MB file size limit.

JPEG captures of frames 1,2,3,4 where you can see the colors alternating.

Does anyone know why this is happening, and what I can do about it? If I use SeparateRows(2), I can see that the fields are actually different colors, so I don't think that QTGMC is actually causing it (garbage in>garbage out).

Is there a way I minimize the color flicker in the output though?

Edit: 1 more piece of information - I tried the same process of looking at individual fields with SeperateRows on a capture of a tape not recorded on the same camcorder (recording of a commercial tape) and the color is consistent between fields, so it is not my VHS deck.

Matt

Attached Images
Attached Files

Last edited by mrb5217; 03-17-2017 at 06:32 PM.
Someday, 12:01 PM
 Ads / Sponsors Join Date: ∞ Posts: 42 Thanks: ∞ Thanked 42 Times in 42 Posts
#2
03-17-2017, 10:47 PM
 sanlyn Premium Member Join Date: Aug 2009 Location: N. Carolina and NY, USA Posts: 3,648 Thanked 1,176 Times in 953 Posts
Quote:
 Originally Posted by mrb5217 When using QTGMC to deinterlace an interlaced VHS capture, I'm getting color flicker (almost like a change in white balance) between alternating frames on any setting other than "Draft".
Sorry to see you're having this problem, but QTGMC has nothing to do with the alternating color balance. The problem exists in your original sample. Odd-numbered frames have a crippled U channel, giving them a yellow color cast that isn't in the even-numbered frames.

The attached YUY2 AVI is from your original .avi sample, with borders cropped to avoid affecting the histogram and analysis readout. The AVI is the original sample after being deinterlaced with yadif and the frame rate reduced to 3 frames per second. I played it in VirtualDub, Media Player Classic, and MPC_BE (it won't play in VLC Player, no surprise). During playback, especially if you play frame-by-frame at even slower rates in VirtualDub, you can see the crippled U channel in the histogram. You can also see that shadows on the walls and clothing change shape with alternating frames.

Its possible to fix this alternating problem, but I'll have to get that together for you tomorrow morning. Getting very late here.

If you have a notion to produce this same result with other parts of the video, here's the script I used to make the demo AVI:

Code:
LoadCPlugin("Drive:\path\to\Avisynth\plugins\yadif.dll")

AviSource("Drive:\path\to\video\01-original.avi").KillAudio()
AssumeTFF()
Trim(0,39)
Crop(4,0,-12,-8)
ConvertToYV12(interlaced=false)
ColorYUV(Analyze=true)
Histogram("Levels")
ConvertToYUY2(interlaced=false)
AssumeFPS(3000,1000)
A coding tip that might save you some time: The default preset for QTGMC is always "Slow", if you don't specify a preset in your code. So typing this:
Code:
QTGMC(preset="Slow")
is the same as typing this:
Code:
QTGMC()
Because Avisynth assumes bottom field first, and because most filters borrow that assumption as default, you should usually specify AssumeTFF() in scripts, to avoid problems.

Looking at your workflow, I'd advise going from YUV to RGB for filter or color work to be done last, not first. Avoid back-and-forth colorspace conversion rounding errors whenever possible.

Attached Files
#3
03-18-2017, 12:54 PM
 sanlyn Premium Member Join Date: Aug 2009 Location: N. Carolina and NY, USA Posts: 3,648 Thanked 1,176 Times in 953 Posts
Sorry for the delay. I spent a while on your sample 01-original.avi and used an .avs script that has been used many times for the problem of dissimilar color balance in alternate fields. The added problems here are chroma flutter and unstable objects such as the shape of the shadows on the back wall. The overall color balance is iffy because of mixed light sources, notably a window somewhere on the left off-camera that throws cyan light, so I decided to lean toward the warmish side.

I used the script below. The first few lines use SeparateFields() to allow correction of the U (blue-yellow) channel on odd fields only. The next section addresses noise, shimmer, and chroma flutter. I found that handling dissimilar color and working on noise separately gave better results.

Code:
AviSource("Drive:\path\to\01-original.avi")

AssumeTFF()
SeparateFields()
source=last
e=source.SelectEven()
o=source.SelectOdd().ColorYUV(off_u=10)
interleave(e,o).Weave()

ConvertToYV12(interlaced=true)
QTGMC(preset="medium",EZDenoise=8,denoiser="dfttest",ChromaMotion=true,\
border=true,ChromaNoise=true,DenoiseMC=true,GrainRestore=0.3)
ColorYUV(gain_v=10) #,gain_y=10)
SmoothTweak(contrast=1.3)
SmoothLevels(16,1.0,255,16,225,protect=6)
SMoothUV()
TemporalSoften(4,4,8,15,2)
LSFmod()
ConvertToRGB32(matrix="Rec601",interlaced=false)
return last
GradFun2DBmod and AddGrainC were used to address banding issues. SmoothTweak() and SmoothLevels() are functions in the SmoothAdjust plugin. SmoothUV is an Avisynth plugin to smooth chroma flutter. In QTGMC I enabled chroma cleaning, which is not enabled by default because it slows operations somewhat.

The attached results are deinterlaced 59.94 fps, which I assume you want for web posting. A downside here is that with a lot of camera acrobatics the double-rate video will stutter in some players (VLC Player, for one).

The script's conversion to RGB32 was for VirtualDub processing, which was applied to Avisynth's output while the script ran. I used ColorMill to tweak color and levels a little, as things looked a little too green coming out of the script. Attached is a .vcf file of the Colormill settings I used. A .vcf is a Virtualdub text file for saving processing settings. To apply the filter, you must have ColorMill v2.1 installed in your VDub plugins. If you don't have it, you can get it here: http://www.digitalfaq.com/forum/atta...colormill21zip.

To use a vcf file, click "File..." -> "Load processing settings...", navigate to the location of the .vcf file, and click OK or Open, or whatever. Note that loading a .vcf will overwrite any other VDub filters you may have loaded.

Attached Files
#4
03-18-2017, 01:13 PM
 mrb5217 Free Member Join Date: Jan 2017 Posts: 8 Thanked 0 Times in 0 Posts
Sanlyn,

Thanks so much for your work on this, and the solution. I'm going to take the time to properly digest and work through this when I have a bit more time later this weekend.

In the meantime, I have a question regarding the conversion of the color spaces you mentioned.

My workflow for capturing video so has been as follows:

For Hi8 captures (which the color was fine on):
1) Capture to HuffYUV, YUV2 AVI with VirtualDub, 1 long capture of the entire tape
2) Trim the clips into their own files (christmas, birthday, etc), - using direct stream copy
and then create 2 outputs from these trimmed clips:
Output 1) Take the trimmed clips and create a DVD using DVDStyler (encoding in MPEG2 in the process)
Output 2) Take the trimmed clips, run them through an AVISynth script to detinterlace/crop overscan > encode as H.264 with MeGUI

When I started to capture the VHS tapes, I noticed that the hue of every single tape captured by the camcorder was wrong, purple skies. Since these were amateur recorded tapes with no color bars for a true reference, after some trial and error, I found that a hue shift of -8* and 95% saturation made the tapes look more agreeable (less purple skies, oversaturated reds).

I followed the same process as above for the VHS conversions, but on step 2, I used full processing mode to fix the Hue/Saturation on the trimmed clips, which I then outputted to DVD and H.264 the same way.

Based on what you're saying though, this process converted my source YUV2 video to to RGB (with VirtualDub), corrected the hue, and then converted back to YUV2, followed by a conversion to YV12 in AviSynth for deinterlacing and final H.264 output. This doesn't sound like a very good workflow.

Where in my process would you recommend I do the hue/saturation changes so that they are applied to both the DVD copy and the H.264 copy in best way possible? For the h.264 video I could do the changes in AVIsynth, but what about the file going to DVD?
#5
03-18-2017, 04:16 PM
 sanlyn Premium Member Join Date: Aug 2009 Location: N. Carolina and NY, USA Posts: 3,648 Thanked 1,176 Times in 953 Posts
It isn't always possible or feasible to avoid back-and-forth colorspace conversions. Generally it's best to do as much as you can in one colorspace before moving on to the next. For most encoding, of course, you have little choice but to go YV12 as a final step. I don't think the world will end if I had to use RGB at the very first processing stage and then finish with RGB -> YUY2 -> YV12 -> RGB again. I've had to do that on occasion with jumpy video that required stabilizing with VirtualDub's DeShaker before even the simplest of temporal denoisers could work on video that had such hectic motion as the originals did.

I capture to YUY2 as well, at 720x480 interlaced (with huffyuv for less CPU effort at lossless compression during capture). I correct for levels during capture using VDub's capture histogram and my capture card's proc amp controls accessed thru VirtualDub. I don't perform color correction at that step. I did it on one tape and discovered after working on it for 6 weeks that I was spending half the time undoing the corrections and the rest of the time finding better ways to do it in post-processing.

Post-process begins in Avisynth, with some basic color and levels work that Avisynth can handle (I almost always have to tweak these later in RGB or apply VDub RGB denoising, etc., but anything clipped in YUV can't be recovered after going to RGB so YUV levels work comes first). What you do with hue and saturation at that point is up to you, but other than fixing basic levels I usually go to Avisynth denoising first. Reason: many YUY2/YV12 denoisers, especially chroma cleaners, work on saturation, color bleed, and hue changes caused by chroma noise, etc. So I wait for the results of denoise/repair before moving to final color work in RGB.

While some denoisers work in YUY2 or YV12, the results are almost always require YV12. I save those intermediate files as YV12 losslessly compressed with Lagarith. As you saw in the script I used, I applied RGB filters to Avisynth's output while the script ran in Virtualdub. This isn't always possible, especially since I sometimes convert a work file to RGB and color correct in AfterEffects with ColorFinesse. Or sometimes the color work is going to be a major pain, so I save my YV12 work file for later. The file is saved out of VirtualDub as YV12 by setting "color depth..." and "compression...." to YV12 and Lagarith respectively in VirtualDub, before clicking the "Save AVI" command. If I'm not applying any VrtualDub RGB stuff, I set color depth and compression and then select "fast recompress" mode.

The result after post process is almost always interlaced YV12. I've done a lot of movie tapes, so I have to qualify that by saying that my movie caps are first inverse telecined from the start and remain purely progressive until the encoding step, when 3:2 pulldown is applied by the encoder. In any event, that YV12 file is denoised, color corrected, and ready for the encoder. I noted your cropping for overscan reference -- I don't throw away any of the image or do any resizing because of overscan borders. The borders get dirty or off-color during processing, so they're cropped off and replaced with black borders sized so that the image is centered. If I start with 720x480 and uneven borders, I end up with 720x480 and balanced borders.

What remains is encoding. For web posting of my sister's godawful VHS family videos, I deinterlace with QTGMC in "super fast" mode with no denosiing, resize to square pixel 640x480 (or sometimes 400x300) using Avisynth's Spline36 Resize, then encode that to mp4. All else gets encoded into standard playback and disc formats at 720x480, usually for DVD but sometimes for standard definition BluRay.

If you don't have Lagarith, it's here: https://lags.leetcode.net/codec.html

Color balance is a touchy subject because everyone has their druthers. I'm not satisfied with the color of the mp4 posted, but then again I didn't spend much time with color. It looks almost like a sepia print. It can be fixed, but in RGB and not without some sophisticated help such as gradation curves and two or three stages of correction. It's made more complicated because of mixed lighting.

Last edited by sanlyn; 03-18-2017 at 04:29 PM.
#6
03-18-2017, 06:14 PM
 sanlyn Premium Member Join Date: Aug 2009 Location: N. Carolina and NY, USA Posts: 3,648 Thanked 1,176 Times in 953 Posts
And while I'm at it, allow me to correct myself and add a new attachment.

In the script I posted earlier I used a crop-and-center statement that has an error:
Code:
Crop(4,0,-12,-8).AddBorders(6,4,6,4)
That should have been an obvious error on my part, because the frame is off by 4 pixels horizontally. That's what I get for being lazy and pasting in a rush from another script. The line should read:

Code:
Crop(4,0,-12,-8).AddBorders(8,4,8,4)
The attached is the YV12 59.95 fps progressive working file I saved from the previous script, but re-interlaced, resized for DVD, and encoded to MPEG2. The scripted lines that do that work are:

Code:
SeparateFields().SelectEvery(4,0,3).Weave()
Spline36Resize(720,480)
The problem with maintaining the interlace structure is that you can see the sloppy interlacing job your camera was doing (common with consumer camera shutters designed for the CRT era), making line twitter more obvious and showing the flutter of changing shapes in the wall shadows because of whatever defect caused the flicker problem in the first place. One way around that is to keep the 29.97 frame rate by discarding alternate frames. That will cut temporal smoothness on motion by 50%, so the video would have to be stabilized with DeShaker or something like it to avoid at least a little of that motion judder. I guess it's too late to suggest the use of a tripod or a shoulder brace. But ithese are all common problems with home video.

Attached Files
#7
03-19-2017, 01:12 AM
 NJRoadfan Premium Member Join Date: Sep 2010 Posts: 1,066 Thanked 328 Times in 269 Posts
I might have to consult this with my own VHS camcorder captures.

I can confirm that the camcorder is indeed the source of the OP's chroma channel woes as all my family camcorder tapes from 1987 to 1994 suffer from the same problem. The date stamp format give it away that it was likely a Hitachi built camcorder with MOS sensor from the late 80's, likely 1987-89. They were sold under the Realistic (Radio Shack), LXI Series (Sears), RCA, and Hitachi brands. They were EXTREMELY popular since I think it was the first sub \$1000 VHS camcorder on the market at the time and were based on the Hitachi VM-3000A or VM-3100A model. I still have the camcorder if sanlyn wants some more sample output (directly captured, not from tape) to play with.

Whats annoying is the defective color channel only appears on one field of video. Most flat panel TV deinterlacing functions will exhibit a stripping effect. Its most noticeable with blue skies (as noted), and in indoor footage where one might encounter beige walls.
 The following users thank NJRoadfan for this useful post: msgohan (03-20-2017), sanlyn (03-19-2017)
#8
03-19-2017, 05:16 AM
 sanlyn Premium Member Join Date: Aug 2009 Location: N. Carolina and NY, USA Posts: 3,648 Thanked 1,176 Times in 953 Posts
Thanks for the info, NJRoadefan. This likely explains why I've seen this effect several times in the past.
#9
03-19-2017, 06:40 AM
 themaster1 Free Member Join Date: Feb 2011 Posts: 223 Thanked 41 Times in 36 Posts
if it's either U or V the problem someone has posted an excellent solution on videohelp( avisynth) not long ago:
basically you take the channel that's ok andyou invert its colors
here the U component is toasted so:
avisource()
YtoUV(VtoY().Invert(), VtoY(), last)
#10
03-19-2017, 08:30 AM
 sanlyn Premium Member Join Date: Aug 2009 Location: N. Carolina and NY, USA Posts: 3,648 Thanked 1,176 Times in 953 Posts
Quote:
 Originally Posted by themaster1 YtoUV(VtoY().Invert(), VtoY(), last)
Yes, I've seen that one used as well. But in this case it introduces a different problem, a cyan color cast and blotchy chroma in some areas, with white shadows turning blue, yellows turning white -- much more difficult to color correct, IMO. I don't think in this case that the U channel is inverted, but is instead suppressed.
#11
03-19-2017, 09:43 AM
 mrb5217 Free Member Join Date: Jan 2017 Posts: 8 Thanked 0 Times in 0 Posts
Quote:
 The date stamp format give it away that it was likely a Hitachi built camcorder with MOS sensor from the late 80's, likely 1987-89. They were sold under the Realistic (Radio Shack), LXI Series (Sears), RCA, and Hitachi brands.
You got it, it is a Realistic Moviecorder Model 100.

So what was the deal with these camcorders? If the problem was so widespread, surely it wasn't a matter of being broken. Did all the cameras with this circuitry have the same problem? Every single tape ever recorded by this camcorder has the problem, from the first test tape to the last tape before we started using Hi8.

The fact that the color problem occurs with alternating fields would make me think that the output to the heads was inconsistent (since each pass of alternating heads is one field). Was this it a calibration issue? A QC problem with the heads? An inherent flaw in the circuitry/design that nobody cared about in the days of interlaced CRT displays because it all blended together?

Attached Images
#12
03-19-2017, 10:54 AM
 NJRoadfan Premium Member Join Date: Sep 2010 Posts: 1,066 Thanked 328 Times in 269 Posts
I'd say its the image sensor itself. Its likely that in the quest to cut costs and build a cheap imaging sensor, someone noticed that shorting the chroma channel was hardly noticeable to the viewer on interlaced CRTs. I never noticed the problem until I started capturing to the computer a decade later.
#13
03-19-2017, 04:54 PM
 mrb5217 Free Member Join Date: Jan 2017 Posts: 8 Thanked 0 Times in 0 Posts
Something I noticed as I played around with the messed up U channel on various clips was that even in the correction's simplest form (without any overall color correction and noise reduction) on a large scale this is proving to be difficult (if not impossible).

Between clips on the same tape (even different shots 1 after another in the same lighting), not only is the required correction between which field needs it's U different (sometimes even/sometimes odd), but also how much it needs to be shifted varied considerably as well (some clips 3, some 8, some 10). I guess the amount of error present stems from whatever the image sensor, processing circuitry, and video heads felt like doing at the time (yay analog!)

What I mean is, setting up a simple ColorYUV(off_u=10) for one one shot makes the next shot completely wrong. I guess to really fix an entire scene, you'd have to break apart every shot, figure out the U channel correction, and then piece them all back together again.

While it may be viable commercially for something important like a TV show, that level of effort is seems to be pretty much an impossible feat for hundreds of hours of old VHS home movies. Certainly an interesting discussion though.
#14
03-19-2017, 06:02 PM
 themaster1 Free Member Join Date: Feb 2011 Posts: 223 Thanked 41 Times in 36 Posts
#15
03-19-2017, 06:38 PM
 sanlyn Premium Member Join Date: Aug 2009 Location: N. Carolina and NY, USA Posts: 3,648 Thanked 1,176 Times in 953 Posts
Do think it's a good idea? Can rgbadapt correct alternate frames at the same time? if you separate the fields will it correct both series to have the same colors? Why don't you try it and post your results or a script you've used?
#16
03-20-2017, 10:34 AM
 themaster1 Free Member Join Date: Feb 2011 Posts: 223 Thanked 41 Times in 36 Posts
I don't have that color flicker you're talking about
mrb5217 when i use qtgmc or bob so it's a problem on your end only. maybe you're using and outdated version (i know there is a qtgmc version that can handle yuy2 the other not) or maybe a problem at the decoding stage (directshow source...)
#17
03-20-2017, 04:15 PM
 msgohan Free Member Join Date: Feb 2011 Location: Vancouver, Canada Posts: 1,146 Thanked 252 Times in 221 Posts
themaster1: As sanlyn noted at the top of post #2, it's nothing to do with QTGMC. Any method that shows the actual source at 60Hz will show this flicker, i.e. SeparateFields().

Quote:
 Originally Posted by mrb5217 Between clips on the same tape (even different shots 1 after another in the same lighting), not only is the required correction between which field needs it's U different (sometimes even/sometimes odd), but also how much it needs to be shifted varied considerably as well
Well, there's always the evil, ugly method: duplicate whichever channel is "good". Either a dumb repetition (which would make chroma run at 30Hz) or SVP interpolation up to 60Hz.

Someone, somewhere did some work interpolating chroma based on the luma motion of a frame, which would further improve things.

 Tags color, flicker, qtgmc, vhs capture

 Similar Threads Thread Thread Starter Forum Replies Last Post mo418 Capture, Record, Transfer 18 09-16-2015 01:06 PM jriker1 Capture, Record, Transfer 1 02-18-2015 08:16 AM noelyoung Video Hardware Repair 4 01-07-2013 10:45 PM Joekster Restore, Filter, Improve Quality 1 12-22-2011 04:27 PM CaZeek Encode, Convert for discs 10 12-03-2004 08:14 AM