Purple/green VHS?

[lordsmurf]

Does anybody know what causes this.
I either forgot, or never knew. I don't see it often. Maybe once per 5-10 years?

The VHS (or U-matic) tape is mostly shades of green and purple.
Some pink and magenta.
Maybe some yellow, but more commonly brown.
No blue at all, rarely yellow, rarely reds.
Contrast, black levels, etc, all seem fine.

Anybody ever fix anything like this?

[Skiller]

What makes you believe it was not recorded that way? With old tube image sensor based cameras (Newvicon, Vidicon, Trinicon and so on) and completely wrong white balance a stark purple/green tint is typical. Way different than what a wrong white balance on a CCD or CMOS based camera looks like.

[KarMa]

Welcome to Videohelp lordsmurf, maybe you can post a snap shot or even a sample clip.

[jagabo]

I (of YIQ) desaturation would leave you with mostly greens and purples. To simulate it:

# after Tweak(hue=33) U=Q, V=I
Tweak(hue=33).ColorYUV(cont_v=-192).Tweak(hue=-33)

Before, after:

[theewizard]

3d

[johnmeyer]

You could try using manual tracking while doing the transfer. I have sometimes see the video lose color subcarrier when tracking is wrong. This can sometimes happen before you get the tracking noise bars.

[lordsmurf]

I (of YIQ) desaturation would leave you with mostly greens and purples. To simulate it:

Yep, that's exactly it.

I had a feeling you'd have the answer. I need to re-read one of my advanced VCR books. I'm sure it's there. At least now I have a lead on what to look for it.

It's actually bringing back some memories! Last time I restored a video like this was 15 years ago. And I desaturated some of the colors channels with a proc amp. Then I re-saturated the entire picture. I did some mild tweaks to the exact color tints. This was all analog, tape to tape, with stacked proc amps. It's been so long, that I don't remember exactly what I did. At very least, I think I maybe have a sample of that restoration. I'd forgotten all about that until just now.

Any other ideas on how this can be fixed?

What makes you believe it was not recorded that way?

The VCR/VCP is the cause. It may or may not therefore be present on the tape. If the faulty deck recorded the tapes, it's obviously there. If not, then the source may be fine on a better deck. Go.Video dual decks were really bad about this. Those units sucked in every way imaginable. But I too often see it on U-matic transfers. That's actually the basis of the question.

Welcome to Videohelp lordsmurf

You could try using manual tracking while doing the transfer. I have sometimes see the video lose color subcarrier when tracking is wrong. This can sometimes happen before you get the tracking noise bars.

I've sen that a few times as well, but it's rare. It's not this issue either. This is always green/purple. It's not tracking related. Jagabo nailed it.

[jagabo]

Any other ideas on how this can be fixed?

If the I channel isn't completely gone you can just resaturate it:

Tweak(hue=33).ColorYUV(cont_v=768).Tweak(hue=-33)

That will undo the earlier I crush.

[johnmeyer]

My question isn't just "how can it be fixed?" but also, "what caused it, and can the transfer workflow be changed to avoid it?" From the earlier post:

The VCR/VCP is the cause. It may or may not therefore be present on the tape. If the faulty deck recorded the tapes, it's obviously there. If not, then the source may be fine on a better deck.

I'd sure prefer trying a better deck and getting the color right, than trying to do a fix in post which will probably not get very close if indeed one color channel is gone, or almost gone.

[lordsmurf]

My question isn't just "how can it be fixed?" but also, "what caused it, and can the transfer workflow be changed to avoid it?" From the earlier post:

The VCR/VCP is the cause. It may or may not therefore be present on the tape. If the faulty deck recorded the tapes, it's obviously there. If not, then the source may be fine on a better deck.

I'd sure prefer trying a better deck and getting the color right, than trying to do a fix in post which will probably not get very close if indeed one color channel is gone, or almost gone.

The issue always comes down to the destruction of the original source. I'd always suggest a re-capture on a better deck, when that's the issue. This is almost always an nth gen issue.

Any other ideas on how this can be fixed?

If the I channel isn't completely gone you can just resaturate it:

Tweak(hue=33).ColorYUV(cont_v=768).Tweak(hue=-33)

That will undo the earlier I crush.

That really helped.

Between my own saturation tweaks, and this, the output is looking about as perfect as can be expected. I think some blue shades are still missing, but overall everything is restored.

[jagabo]

Using the images from wikipedia:

https://en.wikipedia.org/wiki/YUV
https://en.wikipedia.org/wiki/YIQ

I'm finding that to get a transformation of YUV to YIQ you need to perform the following:

FlipHorizontal().Tweak(hue=57) # Q increases going up, I increases going right

If you desaturate the I component (by 3/4) with:

FlipHorizontal().Tweak(hue=57).ColorYUV(cont_v=-192).Tweak(hue=-57).FlipHorizontal()

you end up with a mostly green/magenta image. If you leave out the FlipHorizontal in the first script you end up with Y(-I)Q. That's fine for the purposes of squeezing out the I component:

Tweak(hue=57).ColorYUV(cont_v=-192).Tweak(hue=-57)

Those last two scripts give exactly the same result.

So if the I component of a video lost 3/4 of its amplitude you would use:

Tweak(hue=57).ColorYUV(cont_v=768).Tweak(hue=-57)

to restore it.

[lordsmurf]

Just playing with value numbers, I've gotten good results. For example:

Tweak(hue=33).ColorYUV(cont_v=868).Tweak(hue=-43)

That's just the Avisynth aspect. It needs follow-up with VirtualDub, and yet again with Premiere.

[jagabo]

Can you upload a short sample video with the problem?

[JVRaines]

I'm finding that to get a transformation of YUV to YIQ you need to perform the following:

FlipHorizontal().Tweak(hue=57) # Q increases going up, I increases going right

Does this mean the 33 value at the Avisynth wiki is wrong?

[jagabo]

I'm finding that to get a transformation of YUV to YIQ you need to perform the following:

FlipHorizontal().Tweak(hue=57) # Q increases going up, I increases going right

Does this mean the 33 value at the Avisynth wiki is wrong?

I'm still not sure about this. There are many places that indicate 33 is the value to use, even Charles Poynton's site. But the only way I can get the the diagrams at wikipedia to align is with a horizontal flip and a 57 degree rotation. Note that 90 = 57 + 33 so those number are related. The AviSynth wiki hint's that there may be something wrong with 33 degrees:

The components iq can be obtained by rotating vu 33 degrees poyton - eq.33 (Poyton wrong; det!=1, or am I too drunk?), that is...

http://avisynth.nl/index.php/ColorBars_theory

Or the YIQ diagram at wikipedia could be wrong and nobody has ever checked it.

[Wilbert]

It was a long time ago when i wrote that on avisynth. It seems to be wrong. I see that Poyton actually says the following:

To transform to Y' IQ to Y' UV, perform a 33 degree rotation and an exchange of colour difference axes:

Meaning rotate 33 degrees and exchange the U,V channels. Let's look at your script and try to relate it to the formula in 33 (Poyton):

FlipHorizontal() means mirroring around the vertical axis (U gets -U, V remains unaltered):

U    [1 0]   -U
V -> [0 1] x  V

FlipHorizontal + rotate 57 degrees (and taking care of the minus sign in front of U):

I   [ COS(57*pi/180) SIN(57*pi/180)]   [1 0]  -U   [-COS(57*pi/180) SIN(57*pi/180)]   U
Q = [-SIN(57*pi/180) COS(57*pi/180)] x [0 1] x V = [ SIN(57*pi/180) COS(57*pi/180)] x V

using cos(x) = sin(90*pi/180-x), sin(x) = cos(90*pi/180-x) one gets

I   [-COS(90*pi/180-33*pi/180) SIN(90*pi/180-33*pi/180)]   U   [-SIN(33*pi/180) COS(33*pi/180)]   U   [-0.544639 0.838671]   U
Q = [ SIN(90*pi/180-33*pi/180) COS(90*pi/180-33*pi/180)] x V = [ COS(33*pi/180) SIN(33*pi/180)] x V = [ 0.838671 0.544639] x V

Which is the same formula as in Poyton.

Guess i need to fix some things over at avisynth.nl (and check Colorbars too).

[jagabo]

Wilbert, Thanks for clarifying this. So using Poynton's procedure we have:

Function YUVtoYIQ(clip clip)
{
    YtoUV(clip.VtoY(), clip.UtoY(), clip) # swap U and V
    Tweak(hue=-33)
    # Now: U corresponds to I, V corresponds to Q
}

Function YIQtoYUV(clip clip)
{
    clip.Tweak(hue=33)
    YtoUV(VtoY(), UtoY(), last) # swap U and V
}

[lordsmurf]

What would a new refined script look like?

Although I did get really good results from my own slight modification of jagabo's suggestion.

[jagabo]

What would a new refined script look like?

Well, a 75 percent reduction of I would be:

YUVtoYIQ()
ColorYUV(cont_u=-192)
YIQtoYUV()

And to reverse it:

YUVtoYIQ()
ColorYUV(cont_u=768)
YIQtoYUV()

The U and V channels may move up or down a bit because of rounding errors -- causing a white balance shift. To bring the white balance back you may need something like:

ColorYUV(off_u=1, off_v=1)

I'm not exactly sure what the equivalent of your:

Tweak(hue=33).ColorYUV(cont_v=868).Tweak(hue=-43)

would be. Maybe something like:

YUVtoYIQ().ColorYUV(cont_v=868).YIQtoYUV()
Tweak(hue=-10)

[jagabo]

Here's the problem with my observations in post 11. I used FlipHorizontal() to invert the U channel. With a UV color wheel image that inverts U because the horizontal axis represents U. With a "normal" image that just flips the image, it doesn't change the color. After flipping the image (and hence inverting U) it was necessary to rotate the image 57 degrees to match the IQ color wheel. To invert U and rotate the hue 57 degrees with a normal image you would use:

yiq = YtoUV(yuv.UtoY().Invert(), yuv.VtoY(), yuv).Tweak(hue=57)

which is equivalent to Poynton's method (aside from rounding errors) of swapping the U and V channels and rotating 33 degrees:

yiq = YtoUV(yuv.VtoY(), yuv.UtoY(), yuv).Tweak(hue=-33)

After either of these you're left with I on the U axis and Q on the V axis. With Poynton's method, if you skip the UV swap and just Tweak(hue=33) you're left with I on the V axis and U Q on the U axis. So if you're in a hurry and just want the orange/teal look so common in movies you can just:

Tweak(hue=33).ColorYUV(cont_u=-192).Tweak(hue=-33)

Otherwise, with the full YUV to YIQ transform:

YUVtoYIQ().ColorYUV(cont_v=-192).YIQtoYUV()

[pandy]

For me it looks like common issues on HDMI where RGB is confused with YCbCr - are you sure that this is not such problem? (RGB interpreted as YCbCr)

[JVRaines]

With Poynton's method, if you skip the UV swap and just Tweak(hue=33) you're left with I on the V axis and U Q on the U axis.

Thus, for I and Q manipulation with eventual return to the YUV space, it's simpler to do the Tweaks alone and let V = I and U = Q. This is very helpful, jagabo! There was a post not so long ago on this forum with a video that kept popping into purple/green. I bet this approach would have fixed it.

[jagabo]

With Poynton's method, if you skip the UV swap and just Tweak(hue=33) you're left with I on the V axis and U Q on the U axis.

Thus, for I and Q manipulation with eventual return to the YUV space, it's simpler to do the Tweaks alone and let V = I and U = Q.

Yes, exactly.

This is very helpful, jagabo! There was a post not so long ago on this forum with a video that kept popping into purple/green. I bet this approach would have fixed it.

Do you have a link?

[JVRaines]

Do you have a link?

Here it is. 2Bdecided nails the IQ issue in #17 but there was no further discussion of manipulating those channels.

[Wilbert]

incorrect post