Removing strange red color shift on right of pic

[colinb]

I have some old 8mm analog camorder tapes and have been capturing them to digital DV by playing them back in a Digital8 camorder. This effectively digitises the analog footage and feeds the resulting DV data across firewire to the PC as usual.

The resulting DV captures on my PC are excellent, except that on some scenes where there was an orange wall I noticed a bright green column down the right hand side, possibly 10-12 pixels wide. It still contained the picture detail, so I assumed it must be the red component missing down the right. However I also noticed that on scenes containing grass, the column seemed to have a reddish tint.

I therefore suspect that this is not just a *missing* color as such, but something wrong with the "phase" of the color signal down the right hand side.

If this is the case, is there anything I can do in Avisynth to correct this (before feeding to an MPEG encoder). The filter would have to work only down the right hand side, and may need to have a feathered edge because the column that needs to be corrected is not hard edged.

Does anyone have any ideas how I might correct this?

[Chainmax]

You really should provide a screenshot or a sample capture for us to be able to help you better. If it's chroma bleeding you are talking about, you should try FixChromaBleeding (http://forum.doom9.org/showthread.php?t=77074).

[IanB]

Possibly could be numeric overflow not being correctly clamped in your DV codec (x >=256 -> x=x-256). The real problem could be the camera producing illegal YUV values and the codec code is just being slack handling the illegal values. Try viewing with the internal DV codec in the latest VDub's, Avery's code is pretty carefull about overflow.

Avisynths Limiter() function is designed to prevent this in post-processing but would be no help here, as any such overflow will have already occured in the DV.avi file.

[colinb]

I just downloaded the 1.6.12 version of VirtualDub and the color problem displays in that the same.

Here are 3 pics showing the problem. I've cropped them to show just the righ hand side of the frame. The most vivid example is the first pic which shows the orange wall of a tent which appears green down at the right edge. The oter two pics show that green grass looks slightly reddish and blue also has a magenta tint.

Any ideas whether this might be correctable?

[Lil' Jer]

Rather than having to wait for the attachment to be approved you can just upload the pics to www.imageshack.us and link them here. It's faster and easier.

[colinb]

OK, but it looks like the attachments have been approved now.

Any thoughts anyone?

[colinb]

I've been thinking some more about this.

The color shift only covers 12 pixels on the right of the frame.

I think an acceptable solution would be if I was able to copy ONLY the choma information from the first adjacent column which has correct color into all of the 12 pixels which have incorrect color.

This would mean the luma which carries the picture detail would be unaffected, but the chroma would be replaced with copied values. This might cause a little bit a color smearing when more saturated colors occured, but would be better than the current dramatic color shift.

As this would all be working in VY12 I guess the copying would have to be done in PAIRS of columns.

Actually in my footage I have (counting horizontally from pixel number 1 on the left):

001-699 OK
700-711 color shifted area
711-720 black area

Assuming I ignore the black area, I would need to copy the chroma values from pixels 698 and 699 thus:

698 chroma copied to 700,702,704,706,708,710
699 chroma copied to 701,703,705,707,709,711

while leaving the luma values in 700 to 711 unchanged.

Anyone know how this might be achieved in Avisynth (or any other method)?

[Mug Funky]

try:

mergechroma(
\ last,
\ last.crop(0,0,-12,0)
\ .lanczosresize(last.width+12,last.height,0,0,last.width+12,last.height)
\ .crop(0,0,-12,0))

[edit]

also bear in mind that the odd coloured area is probably in the overscan area of your TV, and hence not visible. of course, if you're watching on a computer you'll want to fix it though.

[IanB]

LoadPlugin("BorderControl.dll") # S.Walters pluggin!
...Source(".....avi") # Video source ???
Luma=Last # Save a copy of luma channel
Crop(0,0,-10,0) # Strip of blank right 10 pixels
BorderControl(XRS=12) # Smear right 12 (or 14??) pixels
AddBorder(0,0,10,0) # Put back blank right 10 pixels
MergeLuma(Luma) # Combine Luma with doctored ChromaMaybe you will need to set XRSF parameter as well/instead, experiment a little.

Download Border Control (http://www.geocities.com/siwalters_uk/bordercontrol14.zip)

For more help search this forum for bordercontrol.

[colinb]

Thanks both for those suggestions. :) I won't have access to my files until later this evening, so without being able to try these out right now.....

I can see right away what the BorderControl suggestion is doing - repeating the last OK pixel across the problem area, and then overwriting the luma channel with the original. Sounds just what I need.

In MugFunk'ys solution I'm not entirely sure what this is doing - the Avisynth manual page for MergeChroma is "MergeChroma(clip clip1, clip clip2 [, float weight])" wheras yours has more dimension-related parameters. My guess is that this is stretching the chroma channel across the whole of the picture so that the problem pixels are pushed off the right hand edge - this sounds OK except that there would be a gradual spacial error in the registration of the chroma across the picture. But I may have guessed wrong! Would you venture a brief explanation?

[Mug Funky]

the resizers in avisynth have in-built (floating point accurate) cropping, so i'm abusing that.

what it does:

- crops the problem pix off
- resizes back to the original size, but cropping again (internally) off the picture plane - this means the picture doesn't stretch at all (and is bit-identical to the input - i checked this), but the side is filled by repeats of the edge pixels.
-merges the chroma of this with the luma of the input, so luma isn't touched at all.

of course, bordercontrol looks much simpler... but you need to download a plugin for it :)

[colinb]

Thanks for that explanation.

I gave BorderControl a try last night. It seems to have a couple of problems. I used VirtualDub to display the results and found that the crop() before BorderControl was causing VirtualDub to report an access violation. The only way round it was to perform BorderControl on the full 720x576 frame size, smearing across the problem pixels AND the black area; and then do the croping and re-addition of the black area afterwards.

Also I noticed that the same color shift existed in the first 4 lines, so I tried smearing the top and right hand side in a single BorderControl call. This produced a strange rectanglar area at the top right where the chroma was noticeably wrong. This seems to be the overlap of the top and right smear areas which BorderControl does not seem able to process correctly. I got around this by TWO calls to BorderControl, one smearing only the right and the other smearing only the top.

The smear factor doesn't seem to be documented very well - no indication of the legal range of values or anything. So I did't bother with it.

This produced some very satisfactory results. :)))

I also noticed that there was a smaller black area on the left hand side. The sum of lefta nd right black areas was about 16 pixels. That would make the real picture area abount 704 pixels wide. I therfore think it makes more sense to crop off the black areas on either side and encode the width as 704 in HC rather than 720. (704x576 is a legal DVD size).

The only issue now is that my DirectShowSource() produces YUV2 and I'd prefer to stay in YV12 if possible. I think I'll ask about this in the DV forum.

[Mug Funky]

instead of using directshowsource (slow and buggy, but getting better thanks to IanB's perseverance), try install the Cedocida DV codec with avisource - it's extremely fast at decoding, and gives very good control over the output colourspace (not just yuy2 vs yv12, but the actual spatial postitions of the fields etc, as DV and mpeg-2 are very slightly different in that respect).

[colinb]

Thanks. I now have the whole script using YV12. :) :) :)