Color Blending Post Encoding?

[Sharc]

Dot crawls are indeed difficult to remove.
Your video may also benefit from some de-rainbowing and de-noising. You may collect some ideas from these old but still valid sites:
https://www.animemusicvideos.org/guides/avtech31/post-qual.html
https://www.aquilinestudios.org/avsfilters/index.html

[Okiba]

Oh wow. Those are indeed great read. I was looking for this all around filter guide, thanks!

There something that's not very clear to me with the Histogram. After following the talk we had, I indeed up with this:

Levels(41, 1.0, 209, 16, 235, coring=false)

The image is indeed less washed up - but something else happened due do that. I'm losing details on Red/Orange and it seems like the color leaks (so it takes more space on the picture then it should - and it doesn't seems to be ChromeShift). It doesn't seems to be white/black clipping - because those even after the level fix, seems to be on the right spot find on the histrogram. Attaching example.

[Sharc]

Same script except the 'levels'? Any other filters in the workflow?
Source?

[jagabo]

Levels also increases saturation. If you look at the luma and chroma channels you'll see that the details are still there in the luma. But the chroma is blown way out of gamut, causing red to wash away other details when converted to RGB.

ImageSource("attachment.png", start=0, end=23, fps=23.976) 
Crop(0, 256,-2,-0)
ConvertToYV16()
Interleave(last, Levels(41, 1.0, 209, 16, 235, coring=false))
StackHorizontal(GreyScale(), UtoY(), VtoY())

before:

[Attachment 55397 - Click to enlarge]

after:

[Attachment 55398 - Click to enlarge]

ImageSource("attachment.png", start=0, end=23, fps=23.976) 
Crop(0, 256,-2,-0)
ConvertToYV16()
Interleave(last, Levels(41, 1.0, 209, 16, 235, coring=false))
Histogram(mode="color")

before:

[Attachment 55399 - Click to enlarge]

after:

[Attachment 55400 - Click to enlarge]

[jagabo]

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?

Yes, cartoons tend to have lots of highly saturated colors so limiting blurring to areas of high saturation blurs a lot of the picture. You can play around with the thresholds to effect more or less of the image.

While I do see dots crawls in other videos, it's no where near this one.

It's because of the large amount of highly saturated colors in the cartoon.

If you look at the analog waveform of a composite signal you can see why the chroma carrier causes those dots in the luma.

https://www.eetimes.com/measuring-composite-video-signal-performance-requires-understa...e-part-1-of-2/


In figure 1 (greyscale color bars) you can see that the luma steps cleanly down from high levels to low levels in the colorbar signal.



But when color is added, figure 2, it appears in the composite signal as a high frequency sinusoidal added to the luma signal. The amplitude of the carrier corresponds to the saturation, the phase of the signal the hue. When digitizing that signal the chroma carrier has to be removed from the composite signal. There are different types of filters for this (low pass filter, 3d comb filter, etc.) with different effectiveness. But you almost always get a little of the carrier leaking through.

S-video avoids this problem by sending the chroma on a separate wire.

[Okiba]

Same script except the 'levels'? Any other filters in the workflow?

BarbarRaw.avi is small loseless part of a bigger Barbar episode. I might be wrong, but I think the screenshots I posted were on that smaller section. The script looks like so:

SetFilterMTMODE("QTGMC", 2)
AviSource("F:\BarbarRaw.avi")
ConvertToYV16(interlaced=true) 

crop(28, 7, -26, -9)
Levels(41, 1.0, 209, 16, 235, coring=false)

AssumeBFF()
QTGMC(Preset="Slower", EdiThreads=3)
Srestore(23.976)
ChromaShiftSP(X=0, Y=2)
#MergeChroma(last, Spline36Resize(width/8*4, height).aWarpSharp(20).Sharpen(1.0).nnedi3_rpow2(2, cshift="Spline36Resize", fwidth=width, fheight=height))
Prefetch(3)

(MergeChroma is currently disable for this specific Cartoon as it's really make the error on the edges harsh).

Levels also increases saturation

Oh. I didn't know that. I was sure it only modify the Luma.

Thank you yet again for the detailed explanation Jagbo. Can I ask something personal? Is that a hobby? or your working in the video industry? You seems to know a LOT about Video.

S-video avoids this problem by sending the chroma on a separate wire.

The capture was being done with S-Video. It doesn't matter as when it digitialized the chroma carrier going to get removed anyhow?

So what would be a decent solution for that? I can decide not to modify the Levels on this specific video. It will be slightly washed out, but I won't lose so many details. I'll check some of the filters you mentioned (low pass filter, 3d comb filter). Something simple like Tweak(sat=x) won't fix that? I see see any change in the white/black historgram when tweaking sat.

[Sharc]

Same script except the 'levels'? Any other filters in the workflow?

BarbarRaw.avi is small loseless part of a bigger Barbar episode. I might be wrong, but I think the screenshots I posted were on that smaller section.

I couldn't find it in the smaller section, but the problem materialized also with the red pants. I think you just overdid with the levels. Try

Levels(41,1.0,235,16,235,coring=false)

[Okiba]

230 indeed has more details (although everything is still quite red). The Color Histogram still showing red being crashed. Attached.

But I'm not sure what I did wrong? If you check the histogram on the Default.png image I shared earlier, It around 180. And I found a very bright/white scene, and It was around 210. That's why I set the number in the Level to be 210. Isn't it the proper way doing it based on the talk we had about histogram earlier?

Thanks!

[Sharc]

230 indeed has more details (although everything is still quite red). The Color Histogram still showing red being crashed. Attached.

But I'm not sure what I did wrong? If you check the histogram on the Default.png image I shared earlier, It around 180. And I found a very bright/white scene, and It was around 210. That's why I set the number in the Level to be 210. Isn't it the proper way doing it based on the talk we had about histogram earlier?

Thanks!

The waveform monitor shows Y (Luma) only. For U and V we need to check the histogram or the vectorscope, I think.
I am not sure though how much out-of-gamut colors are caused by color subsampling.

[jagabo]

Is that a hobby? or your working in the video industry? You seems to know a LOT about Video.

It's a hobby. But I've worked with computer graphics and video as a computer programmer since the 1980's.

So what would be a decent solution for that? I can decide not to modify the Levels on this specific video. It will be slightly washed out, but I won't lose so many details. I'll check some of the filters you mentioned (low pass filter, 3d comb filter). Something simple like Tweak(sat=x) won't fix that? I see see any change in the white/black historgram when tweaking sat.

To avoid changing the chroma you could merge the new luma with the old chroma. Or use Tweak() or ColorYUV() instead of Levels(). But even that can lead to illegal values.

Look at the RGB cube inside the rec.601 YUV (YCbCr) cube:


[Attachment 55405 - Click to enlarge]
(That image originally came from https://software.intel.com/en-us/node/503873. But Intel appears to have (re)moved it.)

[EDIT]
New link:
https://www.intel.com/content/www/us/en/develop/documentation/ipp-dev-reference/top/vo...en?language=en
[/EDIT]

The inner cube is all 16 million valid 8 bit RGB colors. The outer cube is all 16 million possible 8 bit YUV combinations. You can see that most YUV combinations fall outside the RGB cube. In fact only about 1/6 of the possible YUV values map to valid RGB colors. You can see that if you start changing Y, U, and V values it's easy to move some of them outside the RGB cube. For example, look at the red corner of the RGB cube. You can see that if you moved a pixel of that color down by one Y unit, ColorYUV(off_y=-1) or Tweak(bright=-1), it will move outside the RGB cube.

Another solution is to Convert the video to RGB, use Levels(), then convert back to YUV (you'll have to use different Levels values). But even with that you can crush RGB values against the edge of the inner cube.

[Okiba]

It's a hobby

Impressive!

When digitizing that signal the chroma carrier has to be removed from the composite signal.

So It doesn't really depends on your setup. When digitzing happens, you lost that Chroma carrier (even if S-Video is used). We believe the VHS/DVD Combo doing some sort of digitizing on it own. But even if I had just a simple VHS - the capture process would have cause the same problem?

To avoid changing the chroma you could merge the new luma with the old chroma.

This sounds like the "correct" answer? because you technically doing what S-Video does? Is that a complex thing to do? Save the Chroma into variable, change the levels - and apply the older Chrome back while the Luma values are the values modified by the Levels function?

Or use Tweak() or ColorYUV() instead of Levels(). But even that can lead to illegal values.

If Tweak and ColorYUV only effect the black/white - why would it lead to illegal values? unless the illegal values are already there due to the capture digitializing process.

Another solution is to Convert the video to RGB, use Levels(), then convert back to YUV (you'll have to use different Levels values). But even with that you can crush RGB values against the edge of the inner cube.

So the Conversion method is smart enough to lower both the Y and UV accordingly?

Thank you!

[Sharc]

To avoid changing the chroma you could merge the new luma with the old chroma.

Would below do it? The waveform monitor and vectorscope seem to confirm it.....

new=levels(last,41,1.0,209,16,235,coring=false)
mergechroma(new,last,1.0) #play with the weight, e.g. 0.5

[Okiba]

Yep! Looking better! The red while being dominate, is no longer being crashed. I can see the details. There's couple of orange dots. I'm not sure if they are being crashed or not. But I assume if Orange is indeed crashed it's because It was captured that way? (so there's nothing to do anyhow because details are already lost). I wonder if that's a good practice? Maybe It should also be added to the generic QTGMC Camcorder script we talked about previously?

Also, is there a name to the "Leaking" of colors like happening on the image? the face has some red leaking from around him.

[Sharc]

I wonder if that's a good practice? Maybe It should also be added to the generic QTGMC Camcorder script we talked about previously?

You could also try with

autoadjust(auto_gain=true)

instead. It seems to do a pretty good job with the Babarraw.avi

Also, is there a name to the "Leaking" of colors like happening on the image? the face has some red leaking from around him.

Chroma bleeding.

[jagabo]

When digitizing that signal the chroma carrier has to be removed from the composite signal.

So It doesn't really depends on your setup. When digitzing happens, you lost that Chroma carrier

The capture device may not remove all the dot crawl artifacts. There's usually a little bit left. Where the residual dots appear depends on the algorithm used to remove the chroma carrier from the luma.

(even if S-Video is used)

With a "perfect" s-video signal there will be no dot crawl artifacts. Because the chroma and luma are sent on separate wires -- there's no need to separate them.

even if I had just a simple VHS - the capture process would have cause the same problem?

With a composite input, yes.

But the dot crawl artifacts are a separate issue from the YUV values leading to invalid RGB colors.

To avoid changing the chroma you could merge the new luma with the old chroma.

This sounds like the "correct" answer?

It may work better but it's not the full answer.

Is that a complex thing to do? Save the Chroma into variable, change the levels - and apply the older Chrome back while the Luma values are the values modified by the Levels function?

Yes, like MergeChroma(last, Levels())

Or use Tweak() or ColorYUV() instead of Levels(). But even that can lead to illegal values.

If Tweak and ColorYUV only effect the black/white - why would it lead to illegal values? unless the illegal values are already there due to the capture digitializing process.

Again, look at the image of the RGB cube inside the YUV cube. The inner cube marks the range of all valid RGB colors. Any YUV combination that doesn't fall within that inner cube are illegal. An existing RGB image may not use all 16 million RGB colors but all its colors will fall somewhere within that inner cube. If you move an image's Y values down any pixels near the bottom edges of the inner cube may move outside the cube. For example, look at the red corner of the RGB cube (R=255, G=0, B=0). A pixel of that color will have YUV values of Y=81, U=91, V=240. Lowering the Y value to 80 moves it outside the cube of valid RGB colors -- producing an illegal color.

Another solution is to Convert the video to RGB, use Levels(), then convert back to YUV (you'll have to use different Levels values). But even with that you can crush RGB values against the edge of the inner cube.

So the Conversion method is smart enough to lower both the Y and UV accordingly?

Not exactly. But since you can't produce illegal RGB values when working in RGB (any values that you try to move outside the RGB cube get crushed against the edges of the RGB cube) you won't produce illegal YUV values upon conversion back to YUV.

[Okiba]

With a composite input, yes.

So I'm not 100% clear on that, forgive me for being slow. My LG DVD/VHS Combo, is connect to Capture device (Diamond VC500) using S-Video That's not a "Perfect" S-Video setup. Because the Capture device effects the signal. A perfect S-Video signal is SVideo from the VHS straightly to the TV, and in that case - no Dot Crawling will happen? So how many Dot Crawler we see, is effect directly by the Capture device and it ability to handle it?

Thanks for answer my other question. In that case, I have some home work to do. MergeChroma seems like a decent solution. It allow me to handle Luma decent, and I can just over-write the captured Chroma settings. That doesn't means the Chroma settings are correct or calibrated - but at least they are not getting crashed.

What I need to compared it against, is convert to RGB, Use Level (I assume it's the same logic, but the the values are caped at 0-256), and convert back to YUV. I'll post results later on. I might as well check the AutoAdjust like Sharc suggested.

Thanks you both!

[Sharc]

Yes, like MergeChroma(last, Levels())

Hmm...., for merging the new luma with the old chroma, shouldn't it be reversed, like
MergeChroma(Levels(),last,1.0)
(The default weight is 1.0)
Never mind if I am wrong.

[Okiba]

I assume the RGB Convert should looks something like that?

ConvertToRGB (interlaced=true)
Levels(41, 1.0, 209, 0, 256, coring=false)
ConvertToYV16(interlaced=true)

Range in 0-256, but 41/209 are the YUV Values. I couldn't pick the proper values because waveform Histogram doesn't seems to work on RGB?

[jagabo]

So I'm not 100% clear on that, forgive me for being slow. My LG DVD/VHS Combo, is connect to Capture device (Diamond VC500) using S-Video That's not a "Perfect" S-Video setup.

VHS/DVD combos often have a standard VHS deck with composite output internally. That composite signal is digitized within the unit to apply digital filters (line TBC? proc amp?) and for recording onto DVDR. The S-video output from the combo is that digital data converted back to analog video. During the digitization step it may not have completely removed dot crawl from the luma channel. And the artifacts are then sent out over s-video.

FYI, here's an example of a composite signal without any separation of the chroma carrier:

[Attachment 55439 - Click to enlarge]

That's the Belle Nuit color chart:

[Attachment 55443 - Click to enlarge]

played by a DVD player, with the composite output of the player routed to the s-video luma pin of a capture device.

Here's another filter for removing dot crawl:

LWlibavVideoSource("Babarraw.avi") # you can use AviSource()
AssumeBFF()
src = last

########################### dot crawl removal
SeparateFields()
blur = Spline36Resize(width/4*2, height).Spline36Resize(width,height)

vmask = mt_edge(thy1=2, thy2=2, mode="0 -1 0   0 2 0   0 -1 0") # vertical dark-light-dark (or opposite) transitions
hmask = mt_edge(thy1=2, thy2=2, mode="0 0 0   -1 2 -1   0 0 0") # horizontal dark-light-dark (or opposite) transitions
smask = Overlay(vmask, hmask, mode="multiply").GreyScale() # logical and of the two

Overlay(last, blur, mask=smask)
Weave()
########################### end dot crawl removal

Interleave(src.Bob(), last.Bob()) # compare before and after

That one attempts to find small dots and blurs only those dots. It doesn't blur other parts of the picture as much as the simpler saturation mask version.

And a filter you'll find useful... This highlights out of gamut portions of the frame in a chosen color (red is the default):

function HighlightBadRGB(clip vid, int "color")
{
  color = default(color, $ff0000)

  badcolor = BlankClip(vid, color=color)
  Subtract(ConvertToYV24(vid), ConvertToYV24(vid).ConvertToRGB().ConvertToYV24())
  absY = Overlay(ColorYUV(off_y=-126), Invert().ColorYUV(off_y=-130), mode="add")
  absU = Overlay(UtoY().ColorYUV(off_y=-128), UtoY().Invert().ColorYUV(off_y=-128), mode="add")
  absV = Overlay(VtoY().ColorYUV(off_y=-128), VtoY().Invert().ColorYUV(off_y=-128), mode="add")
  Overlay(absU,absV, mode="add")
  Overlay(last,absY, mode="add")
  ColorYUV(gain_y=65000)
  Overlay(vid,badcolor,0,0,last)
}

It works by converting the input YUV image to RGB then back to YUV. Then looking for colors that have changed. It's not perfectly accurate but good for a quick test. With chroma subsampled video you expect to see some bad colors near lines/edges. Just watch out for large areas of bad colors.

LWlibavVideoSource("Babarraw.avi") 
Levels(41, 1.0, 209, 16, 235, coring=false)
HighlightBadRGB(color_white)

[Attachment 55445 - Click to enlarge]

[Okiba]

VHS/DVD combos often have a standard VHS deck with composite output internally

Ohhh, OK. That was I was missing. The fact the composite output is internal. So the S-Video Luma is already contaminated with Dot Crawling. Roger that.

This Cartoon is so heavy with Dot Crawl, I'm not sure there is much that can be done. Here's a results with the Dot Crawl script you share:



But it is working better with the Camcorder Footage. And I added the HighlightBadRGB script to my set of new tools. Thanks!

Regarding the blown out Reds, some testing I did:

That's the AutoAdjust(). While better, It still clip red:

AutoAdjust(auto_gain=true)

That's the results with manually merging the Chroma. Looks much better:

MergeChroma(Levels(41, 1.0, 209, 16, 235, coring=false), last)

As I mentioned, I tried to convert into RGB, Level it up and then Back into Yuv. But I didn't know which values to use. It clear that the range should be 0-256, but because waveform Histogram won't work with RGB - I didn't know how to read RGB Histogram and apply it into appropriate levels.

Thanks!

[johnmeyer]

I did not know any of what jagabo said about how the composite signal makes its way to the S-video output, but it does confirm what I have sometimes seen: the S-video can often look almost the same as the composite, especially if you have a capture device or display chain that includes a really good comb filter.

[Sharc]

It's all about the quality of the filter, but no filter can totally eliminate dotcrawl from composite video. In the 1990's so called '3D comb filters' were introduced which were substantially better than the usual simple notch filters. I don't remember which capture cards did actually include such 3D filters. Most relied on simple notch filters AFAIK.
Many years ago I had reasonable good success with Steve Elliot's (aka tacosalad) vdub plugin. One can still find it here:
http://web.archive.org/web/20180505194328/http://home.earthlink.net:80/~tacosalad/vide.../dotcrawl.html
It works for NTSC only and has never been updated for PAL. See the usage notes on that page. No idea whether it is still working/useful.

[Okiba]

Many years ago I had reasonable good success with Steve Elliot's (aka tacosalad) vdub plugin

Ermm. The results on the link looking good. I will give it a try, thanks!

By the way, I see playing around with saturation lowers the red values. Why not just tweak saturation until all colors are on the right limit?

[Sharc]

Many years ago I had reasonable good success with Steve Elliot's (aka tacosalad) vdub plugin

Ermm. The results on the link looking good. I will give it a try, thanks!

By the way, I see playing around with saturation lowers the red values. Why not just tweak saturation until all colors are on the right limit?

You may end up again with washed-out colors .... (which you wanted to have fixed originally as far as I remember).
But basically you can obtain similar results with tweak(), colorYUV(), levels() etc.

[Okiba]

In that case, I might just use tweak. Because it saves me to copy the Chroma (as Tweak as mentioned earlier just change the whites/black level and not effect Chroma).
How can I translate the current Levels command:

Levels(41, 1.0, 209, 0, 256, coring=false)

To Tweak? I assume it's the bright and const values, but to what they should be set to? 14/209?

[jagabo]

How can I translate the current Levels command:

Levels(41, 1.0, 209, 0, 256, coring=false)

To Tweak? I assume it's the bright and const values, but to what they should be set to? 14/209?

As a rough calculation the difference between 41 and 209 (the input range) is 168. The difference between 0 and 256 (the output range) is 256. So the cont variable would be 256/168 = 1.524. And you're moving 41 down to 0 so bright would be 0-41=-41. But Tweak() performs cont first so that 41 must also be multiplied by 1.524, giving 62. So Tweak(cont=1.524, bright=-62, coring=false) is pretty close.

[Okiba]

Thank you jagabo. So summing the formula up:

x = Brightness
y = Contrast

x - y = 168
256/167 = 1.524

Contrast is 1.524. 

0 - x = -41
-41 * 1.524 = 62

Brightness is -62.

Tweak (cont=1.524, bright=-62, coring=false).

Great. I'll run a small script that calculate it so I won't have to do it myself every-time. As you mentioned, it's not precise, but indeed very close. I actually prefer the Tweak() version as I can see more details (Chroma is the same on both versions).

Thanks!

[Sharc]

How can I translate the current Levels command:

Levels(41, 1.0, 209, 0, 256, coring=false)

To Tweak? I assume it's the bright and const values, but to what they should be set to? 14/209?

As a rough calculation the difference between 41 and 209 (the input range) is 168. The difference between 0 and 256 (the output range) is 256. So the cont variable would be 256/168 = 1.524. And you're moving 41 down to 0 so bright would be 0-41=-41. But Tweak() performs cont first so that 41 must also be multiplied by 1.524, giving 62. So Tweak(cont=1.524, bright=-62, coring=false) is pretty close.

For what it's worth here a simple script for comparing the 2 variants (Levels vs Tweak):

#Script for comparing color tweaking variants

source=AVISource("D:\Temp\Okiba\Babarraw.avi")

source=source.converttoYV16(interlaced=true)
mode="color2" #set the histogram mode: classic, levels, color or color2

#Using Levels
A=source.Levels(41,1.0,209,0,256,coring=false)
A=MergeChroma(A,source,1.0) #use the chroma of the source

#Using Tweak
B=source.Tweak(hue=0.0,sat=1.0,cont=1.524,bright=-62.5,coring=false)

#Layout for comparing
out1=stackhorizontal(A.histogram(mode).subtitle("A"),B.Histogram(mode).subtitle("B"))
out2=interleave(A.histogram(mode).subtitle("A"),B.Histogram(mode).subtitle("B"))
out3=interleave(A.converttoYUY2(interlaced=true).VideoScope(HistoTypeBottom="Y",HistoTypeSide="Y",FrameType="UV").subtitle("A"),B.converttoYUY2(interlaced=true).VideoScope(HistoTypeBottom="Y",HistoTypeSide="Y",FrameType="UV").subtitle("B")) #same as out 2 but using the VideoScope
out4=subtract(A,B).Levels(127,1.0,129,0,255)  #plain grey means there is no difference between the 2 variants

#select the output for viewing:
return out1    #out1, out2, out3, out4

For out3 one needs to install the VideoScope Avisynth plugin (32bit)
http://avisynth.nl/index.php/VideoScope

[Sharc]

...I actually prefer the Tweak() version as I can see more details (Chroma is the same on both versions).

Really? Not according to 'out4' (the amplified difference view) of my comparison script. With bright=-62.5 the 2 variants seem to be identical .....
Well, I don't have the section of your source with the red bubbles, but this shouldn't matter.

[Okiba]

Ermm, out4 doesn't seems to work for me (I used the exact same script but with the full loseless file and not just a part). Is your Histogram also identical? Because as you can see on the picture above, it's a bit different (which made sense to me because Jagbo said moving Level/Tweak is not accurate).