Color Blending Post Encoding?

[Okiba]

Hi again everyone,

My sister has a collection of some old Cartoons I'm helping her to archive. The original Cartoons I tried to de-interlaced looked wrong. So I did some research on previous threads and figured out de-interlacing is not always the proper way to handle Cartoons. After some reading about Inverse Telecine and Srestore, this looked best to me:

SetFilterMTMODE("QTGMC", 2)
AviSource("E:\BabarRaw.avi")
ConvertToYV16(interlaced=true) 
RoboCrop()
ChromaShiftSP(Y=3)
MergeChroma(last, Spline36Resize(width/2, height).aWarpSharp(20).Sharpen(1.0).nnedi3_rpow2(2, cshift="Spline36Resize", fwidth=width, fheight=height))
Levels(45, 1.0, 210, 16, 235, coring=false)
AssumeBFF()
QTGMC(Preset="Slower", EdiThreads=3)
Srestore(25)
Prefetch(3)

Played around in AvsPMod and it looks strange. Like every other frame ghosting the previous. But I think something funky with this Video. When I originally Capture and masked it - there was way too much to black to crop on the left side. I suspect this was actually a NTSC cartoon that was being aired on PAL. So this might be a hint of what's going on. But, I went ahead and encoded that, and noticed strange color blending (Blend.jpg). I can't see this Blend, at least not that harsly in AvsPmod (AvsPmod.png). Is that an encoding problem?

[jagabo]

You have a field blended NTSC to PAL conversion. You need to use SRestore(frate=23.976), not 25.

When I tested SRestore(frate=23.976) I was using a script with only QTGMC and SRestore. But I noticed a few other problems in your script. You are shifting the chroma up by three lines while the video is interlaced. That will cause the chroma to swap fields. Move ChromaShift after QTGMC. And you are sharpening the chroma both horizontally and vertically while the video is interlaced. That will also cause the chroma of the two fields to blend together. Move that after QTGMC too.

[Okiba]

I used Srestore(frate=23.976) just in-case that's indeed NTSC. But that didn't solve the issue. The issue must have been the Chroma Shifting and sharpening as you said. Ofcourse. I should have thinking about the video being interlaced in the first place. Sorry about that! Indeed looking better!

What cause the NTSC blended into PAL? The fact it's an NTSC cartoon that was being converted to PAL? (I was copied from the TV ages ago. We use PAL here). Also, how can I know for myself if a video is NTSC or PAL? the extra black bars should have been a sign I guess. anything else?

By the way, I tested running with tune=animation, and indeed it looks a bit funky with VHS cartoons. I do however not sure about using the tune film in the CamCorder footage. Need more testing.

[jagabo]

What cause the NTSC blended into PAL? The fact it's an NTSC cartoon that was being converted to PAL?

I believe it's a common standards converter that produces that type of blending. They just play an NTSC tape in one end and out comes blended PAL at the other. I.e., it's easy.

how can I know for myself if a video is NTSC or PAL?

If you look at the video field by field you will see the blended fields. That's a good hint. Then look at the output after QTGMC and SRestore. Step through a panning shot frame by frame. Watch for duplicate frames or missing frames. If there are duplicate frames the frame rate is too high. If there are missing frames the frame rate is too low. Adjust SRestore accordingly.

Tune "grain" is often better for noisy sources. But it will produce bigger files with CRF encoding.

[Okiba]

Tune "grain" is often better for noisy sources. But it will produce bigger files with CRF encoding.

Noisy would by any VHS tapes? or just the really bad? I didn't tested "grain". I was reading somewhere here I think "Film" would be the best use for VHS. I will be trying grain for sure now. See which one is better.

Thank you jagabo!

[Okiba]

OK. Having Chroma Offset after QTGMC makes much more sense now. I can actually see Black and White section on the lower part of the video (I shifted 3 pixels up with Y=3). Which makes sense makes sense as all the Chroma shifted up! So I cropped by 4 more pixel on the bottom to negate that. It pretty much means that if I am to use Chrome Shift, no AutoCrop pluging will work. Will have to do it manually.

Some else I noticed when playing around with Crop and Chroma Sharping. I noticed that specific video I masked, wasn't perfectly masked. I could have masked 2 pixel extra to the right to make it looks better. So I adjust the cropping level:

crop(26, 8, -24, -10)

Instead of:

crop(24, 8, -24, -10)

But this break Chroma Sharping. Because "Planet Destination Size must be a multiple of 2". But it's already is it right? because I change from 24 to 26? so the Total is still a multiple of 2? It wasn't the first time, I see a similar thing once using perfect crop(26, 6, -26, -6): "nnedi3_rpow2: YV16 input width must be mod 4 (334). I can make it mod 334 and it will work, but it means I'm cropping more then I want.


I wasn't able to detect a change when using "Grain" on a carton (and the file is almost double the size). I will see how it work with Camcorder footage next.

Thanks!

[jagabo]

When you shift the chroma up by three pixels the bottom 3 pixels of the frame are unchanged. So the solution is to crop away the black borders, shift the chroma, then add the borders back (if necessary).

Yes tune=grain is expensive in terms of bitrate (it takes a lot of bitrate to retain grain/noise). But it will prevent posterization artifacts in shallow gradients. This is most visible in dark areas and blue skies. Whether it's of benefit with VHS depends on how much noise you remove.

[Okiba]

When you shift the chroma up by three pixels the bottom 3 pixels of the frame are unchanged.

What do you mean by "unchanged"? attached you can find the original video (720x576) without any cropping (but with black bars/masking), with Shift L=3. This makes sense to me before all the chroma shifted up - so it means the bottom 3 pixel no longer had Chroma. So instead of cropping just the black bottom bar - I also crop the the 3 extra pixels (4 technically speaking).

Whether it's of benefit with VHS depends on how much noise you remove.

Well, it's hard to tell how many of the 200 videos has shallow gradients. Because I'm batching, and theatrically it can only help maintain quality in small amount of videos - I will be encdoing without it - and I can always re-encode with grain if I'll notice a problem.

I was playing with the "Resize: Planar destination width/height must be a multiple of 2" error. I really have no idea why it's happening. If you will take the raw file I attached at the start of the thread (720x576), and crop it by 24, 6, -26, -6, It will output that error again. But both the height and weight are even even post cropping. So why Spline36Resize(width/2, height) fails?

Also, after a bit more research, it seems different plugin maybe require a specific frame size. NNEDI3 require the image to be mod 4 on both width and height. So if I am to use it - It means I probably need to crop more then I need and there's nothing to do about it (unless there's other plug-ins that re more flex-able, but I assume it depends on logic that process the image and there is no one filter that fit all anyhow).

Thanks!

[jagabo]

When you shift the chroma up by three pixels the bottom 3 pixels of the frame are unchanged.

What do you mean by "unchanged"? attached you can find the original video (720x576) without any cropping (but with black bars/masking), with Shift L=3. This makes sense to me before all the chroma shifted up - so it means the bottom 3 pixel no longer had Chroma. So instead of cropping just the black bottom bar - I also crop the the 3 extra pixels (4 technically speaking).

I was wrong about the unchanged chroma -- what happens is the chroma from the very last line is repeated to cover the are for which there would be no chroma. Here I first cropped the frame to eliminate the black borders but then added a single pixel thick black border to the bottom and shifted the chroma up by 30 lines:


[Attachment 55317 - Click to enlarge]

You can see that the chroma from the black line was used to fill the bottom 30 lines.

the "Resize: Planar destination width/height must be a multiple of 2" error.

The error message is because of the Spline36Resize(width/2, height) on that line. After cropping, downscaling the 670 pixel wide frame would result in 335 pixels wide. You can prevent that by changing it to Spline36Resize(width/4*2, height) to get 334 instead of 335. But that will lead to the next problem: nnedi3_rpow2() requires a mod 4 frame size. So you have to assure that the downscaled size is mod4: Spline36Resize(width/8*4, height).

[Okiba]

what happens is the chroma from the very last line is repeated to cover the are for which there would be no chroma

Oh, OK. That makes sense. So In case I Shifted 3 lines up, the 3 bottom lines will be looking strange (as they are being repeated). So the only reason solution here is to crop those 3 bottom pixels?

I'm swinging about playing around with Chroma Offset, at least when the pixel count is low. For example, It's clear there's a Chroma Offset on the Crown (the attached NoShift.jpg). However - on the other scene (NoShift2.jpg), there still some point where you see the Chroma Offset (like the brown strike on top right). But the Grey faces, and the cloths - not so much. It's looks like Chroma Offset is very visible on specific colors, or on contrasted background. Is it worth cropping 3 pixels from the bottom? Maybe?

The error message is because of the Spline36Resize(width/2, height) on that line. After cropping, downscaling the 670 pixel wide frame would result in 335 pixels wide

Ohhh, so the error was because of the values AFTER the width/2. I was sure it complains about the width before the dividing happens. Is there a formula I can follow for the proper scale? Or as long as It's mod 4 I should be fine?

Thank you!

[jagabo]

It's clear there's a Chroma Offset on the Crown (the attached NoShift.jpg). However - on the other scene (NoShift2.jpg), there still some point where you see the Chroma Offset (like the brown strike on top right). But the Grey faces, and the cloths - not so much. It's looks like Chroma Offset is very visible on specific colors, or on contrasted background.

The chroma is shifted down on everything -- it's just not as noticeable in some areas.

Is it worth cropping 3 pixels from the bottom? Maybe?

I would just crop away black borders before the shift (and restore the border afterward if you need it). That will keep the last lines of the active picture from becoming greyscale (which can be very obvious). With most picture content the fact the last 3 rows have the same chroma won't be very obvious -- especially with the very blurry chroma of VHS.

Crop(0,0,0,N).ChromaShiftSP(y=3).AddBorders(0,0,0,N)

The error message is because of the Spline36Resize(width/2, height) on that line. After cropping, downscaling the 670 pixel wide frame would result in 335 pixels wide

Ohhh, so the error was because of the values AFTER the width/2.

Spline36Resize() failed because it could not produce the 335 pixel wide output.

I was sure it complains about the width before the dividing happens. Is there a formula I can follow for the proper scale? Or as long as It's mod 4 I should be fine?

After changing to Spline36Resize(width/4*2, height) the resize succeeds but the following upscale with nnedi3 fails because nnedi3 requires a mod4 source. So I changed to Spline36Resize(width/8*4, height) (which always results in a mod4 width) so that both operations would succeed. Note that AviSynth in a case like that performs the divide and multiply operation in the order they appear. 670/8 is 83.75. But the calculation is truncated to an integer, 83. Then 83 is multipled by 4 to get 332. The result of those two operations will always be an integer multiple of 4, mod 4. You can use any mod4 size you want for the downscale. You can manually enter Spline36Resize(336,height), for example.

Thank you!

You're welcome.

[Okiba]

With most picture content the fact the last 3 rows have the same chroma won't be very obvious -- especially with the very blurry chroma of VHS.

It indeed depends on the content I guess. I crop before saving it as view-able x264. So I don't need the black bars back. Attaching two pictures (same video, same AviSynth script). One one picture is visible, but not much (you can see black dots on a yellow background, but that's OKish). The other one you is much more harsh (that's without borders, I even 2 extra pixels just in case the preview doesn't some some black section). I also guess it's more prominent on cartoons.

Spline36Resize() failed because it could not produce the 335 pixel wide output.

My bad was that I took the original width and adding the cropping: 720-24-26 = 670. 670 can be divided by two, so I wasn't sure whats up. I wasn't taking in mind the second divide that brings it into 355 Learn new stuff everyday!

So I changed to Spline36Resize(width/8*4, height) (which always results in a mod4 width)

I don't yet know how it being processed in the background, so I wondered if the resize working differently if the width is different variant of mod4. But if it's the same, I can just replace:

MergeChroma(last, Spline36Resize(width/2, height).aWarpSharp(20).Sharpen(1.0).nnedi3_rpow2(2, cshift="Spline36Resize", fwidth=width, fheight=height))

With this:

MergeChroma(last, Spline36Resize(width/8*4, height).aWarpSharp(20).Sharpen(1.0).nnedi3_rpow2(2, cshift="Spline36Resize", fwidth=width, fheight=height))

And I should be good Sharping any resolution

Thank you!

[Okiba]

Following on that problem. I think it's the video fault. Attached is the Loseless file. I'm not sure what exactly is happening at the bottom. But it looks like strange dots. I tried a different cartoon, and as you said - it's not that major like the pig picture on the post above.

[jagabo]

Those are dot crawl artifacts from incomplete removal of the chroma carrier from the luma in a composite video source. They appear in many places in your videos, in and near areas of high color saturation. The more saturated the colors the stronger the dots can be. Some capture devices are better able to filter them out.

https://en.wikipedia.org/wiki/Dot_crawl

Another way to reduce them is to downscale horizontally then upscale:

Spline36Resize(width/2, height).Spline36Resize(width, height)

That usually doesn't hurt VHS too much because of the generally low resolution of VHS.

Using an S-VHS deck for playback can eliminate them entirely.

[Okiba]

Using an S-VHS deck for playback can eliminate them entirely.

I own one of the LG Combo DVD/VHS units (RC288). Are those new devices are S-VHS Deck by de definition?

Dot crawling indeed looks better after the resizing, and the quality hit is not that much (attached). It's a bit more soft, but this being a cartoon... That being said, the Chroma shift still make the bottom to looks strange. The previous "guess" about blaming it on the Dot crawling was a wrong guess. But something else strange is happening. This video was strange to start with, being NTSC in PAL system. I captured another cartoon just after this one (same setup, same tape) - the Chroma is also shift to Y=3. But it's way harder to tell it's shifted (attached).

So for this specific cartoon, I probably just going to crop those 3 dots (4, because it has to be even), and live with that. This was just interesting to talk about (at least to me lol )

[jagabo]

I own one of the LG Combo DVD/VHS units (RC288). Are those new devices are S-VHS Deck by de definition?

That LG unit is not S-VHS. Not many S-VHS combos were made. JVC had a few.

Dot crawling indeed looks better after the resizing, and the quality hit is not that much (attached). It's a bit more soft

You can play around with the downscale size. If you downscale less (Say 400 vs. 360) the image will blur less but the dot crawl won't be removed as well. It's a matter of finding a balance that works for you. If you're using other noise reduction you can get away with less downscaling because the NR may reduce the residual dot craw.

That being said, the Chroma shift still make the bottom to looks strange. The previous "guess" about blaming it on the Dot crawling was a wrong guess.

In all likelihood the chroma of the bottom line is discolored. Since that last line's chroma is being repeated over the bottom four lines after the shift it becomes much more obvious.

I captured another cartoon just after this one (same setup, same tape) - the Chroma is also shift to Y=3. But it's way harder to tell it's shifted (attached).

That image doesn't have a lot of sharp horizontal colored edges so the shift isn't as obvious. You can definitely see it under the charater's right arm (left from our perspective).

[zing269]

Babar DVDs seem to be readily available on eBay and if you found someone selling a Region 1 version you wouldn't have to deal with the PAL > NTSC conversion. If nothing else you should have a cleaner source to work with.

[Sharc]

A dumb question:
What's the idea behind using aWarpSharp at half horizontal resolution with MergeChroma, like

MergeChroma(last, Spline36Resize(width/8*4, height).aWarpSharp(20).Sharpen(1.0).nnedi3_rpow2(2, cshift="Spline36Resize", fwidth=width, fheight=height))

rather than just

aWarpSharp(20)

I tried to compare using the script

v0=AviSource(.....).converttoYV16(interlaced=true).separatefields()
v1=v0.ChromaShiftSP(x=0, y=1)
a=v1.aWarpSharp2(depth=20).subtitle("a")
b=MergeChroma(v1,v1.aWarpSharp2(depth=0)).subtitle("b")
c=MergeChroma(v1,v1.aWarpSharp2(depth=20)).subtitle("c")
d=MergeChroma(v1,v1.Spline36Resize(width(v1)/8*4, height(v1)).aWarpSharp2(depth=20).Sharpen(1.0).nnedi3_rpow2(2, cshift="Spline36Resize", fwidth=width(v1), fheight=height(v1))).Subtitle("d")  #mod4 compliant

return interleave(v1,a,b,c,d)

The sharpest (.... oversharpened, "thinned") picture with my 'natural' test video is from a. Is the script ok at all, or do I miss something (I probably do...) ?
Thanks.

[Okiba]

That LG unit is not S-VHS. Not many S-VHS combos were made. JVC had a few.

I see. I will keep an eye for a S-VHS unit then. I haven't seen any dot crawl on the Camcorder footage, and that's what currently counts. The Cartoons are a plus.

If you're using other noise reduction you can get away with less downscaling because the NR may reduce the residual dot craw.

QTGMC also doing some NR I think? At any rate. I downscale the resolution before QTGMC kicks in.

That image doesn't have a lot of sharp horizontal colored edges so the shift isn't as obvious. You can definitely see it under the charater's right arm (left from our perspective).

Now that you mention it, I can clearly the bush has strange colors.

Babar DVDs seem to be readily available on eBay and if you found someone selling a Region 1 version you wouldn't have to deal with the PAL > NTSC conversion.

The one in the tape is dubbed locally, there's a small community here that archive those rare pieces. But It's interesting. I was always sure Babar originated from France. Apparently, It's Candian! (probably produced by the France community over there). That's why it's NTSC I guess.

Thanks everyone!

[jagabo]

I haven't seen any dot crawl on the Camcorder footage

It's there. For example in the red flowers in the Swiss video. But it's fairly mild since the saturation isn't very high.

QTGMC also doing some NR I think?

Yes, a little noise reduction is a byproduct of it's edge stabilization. You can also explicitly enable further noise reduction with EZDenoise=value, etc.

[jagabo]

What's the idea behind using aWarpSharp at half horizontal resolution

With VHS the chroma resolution is usually far less horizontally than vertically. The idea is to get the horizontal and vertical resolution of the chroma closer to the same so that the sharpening and warping is more similar on both axis.

Source chroma:

[Attachment 55360 - Click to enlarge]

aWarpSharp(depth=20) only:

[Attachment 55362 - Click to enlarge]

Spline36Resize(width/8*4, height).aWarpSharp(20).Sharpen(1.0).nnedi3_rpow2(2 , cshift="Spline36Resize", fwidth=width, fheight=height)

[Attachment 55363 - Click to enlarge]

Though looking more closely at the OP's video the vertical chroma resolution is pretty low too. So it may have worked better reducing both axis.

[Sharc]

What's the idea behind using aWarpSharp at half horizontal resolution

With VHS the chroma resolution is usually far less horizontally than vertically. The idea is to get the horizontal and vertical resolution of the chroma closer to the same so that the sharpening and warping is more similar on both axis.

Ah I see. Thank you.

Though looking more closely at the OP's video the vertical chroma resolution is pretty low too. So it may have worked better reducing both axis.

Maybe the OP's source was 4:2:0 (even interlaced) at some stage.

[jagabo]

Though looking more closely at the OP's video the vertical chroma resolution is pretty low too. So it may have worked better reducing both axis.

Maybe the OP's source was 4:2:0 (even interlaced) at some stage.

Yes, and I think the NTSC to PAL conversion contributed to it too.

[Okiba]

It's there. For example in the red flowers in the Swiss video. But it's fairly mild since the saturation isn't very high.

Bummer. Now that I know where to look, I will keep seeing that

Thanks again jagabo!

[jagabo]

I've written filters that detect dot crawl artifacts and limit the blurring to just those areas. But the detection needs to be tuned for different videos. There are other dot craw filters too:

http://avisynth.nl/index.php/External_filters#Rainbow_.26_Dot_Crawl_Removal

[Okiba]

What's the name of the filter you wrote? I will gladly give it a try!

[jagabo]

Here's one thread where I use such detection:

https://forum.videohelp.com/threads/396037-Reducing-Moir-Effect#post2574191

That one just detected areas of high saturation.

[Okiba]

Interesting! Thanks! I'll try to run it and tweaking around with it. Thanks again!

[jagabo]

Here's an example with your Barbar video.

##########################################################################
#
# simple saturation-like mask
#
##########################################################################

function Saturation(clip vid)
{
    U = Overlay(vid.UtoY().ColorYUV(off_y=-128), vid.UtoY().Invert().ColorYUV(off_y=-128), mode="add")
    V = Overlay(vid.VtoY().ColorYUV(off_y=-128), vid.VtoY().Invert().ColorYUV(off_y=-128), mode="add")
    Overlay(U, V, mode="add")
    Spline36Resize(vid.width, vid.height)
}

##########################################################################

LWlibavVideoSource("Babarraw.avi") 
AssumeBFF()
src = last

SeparateFields()
blur = Spline36Resize(width/4*2, height).Spline36Resize(width,height)
smask = Saturation().ColorYUV(gain_y=1100, off_y=-50)
#return(Interleave(last, smask))
Overlay(last, blur, mask=smask)
Weave()

Interleave(src.Bob(), last.Bob())

Enable the return line to see the mask (alternates between field and mask).

[Okiba]

I didn't have a lot of time to play around with it (more like Copy-paste and compare the results). The upper section is indeed less harsh. But everything else is also soft. Are the dots in the Crown are also Dot Crawling? Also - this is baseline. No Croping/QTGMC etc.

It's probably the fault of this specific video. While I do see dots crawls in other videos, it's no where near this one. It's possible the original broadcasted video was just plain bad.

Thanks!

EDIT: Well, I play around with the Chroma Shift (x), and those dots are almost gone when I set it back to 0. So I'm assuming that not dot crawling but another problem. or moving the chrome on the X makes it worse.