Color keep changing and I cant get it to stop

[jagabo]

If the TV does the clipping/crushing for you and the computer is capable of viewing full range, why would anyone want to limit the colorspace with clamping?

All 8 bit display devices display RGB 0-255 (0,0,0 being full black and 255,255,255 being full white), computers as well as TVs. The standard for all devices is to expand the 16-235 Y range to 0-255 RGB. So all properly set up displays clamp. The reason for the padding in YUV is to allow some latitude when capturing (you can fix it in post) and to allow for oversharpening halos (pretty much common to all analog tape).

Some old analog hardware had problems with the sharp edges created by clamping. And some old hardware had problems displaying out of range video.

The existence of limited range RGB in some editors is to allow you to work in RGB without losing super-blacks and super-whites.

[killerteengohan]

That makes sense after reading that.


limiter(16, 235, 16, 240, "luma")
coloryuv(analyze=true)


Am I doing something wrong here with the colors? These reds are supposed to be bad, right? I don't even have to filter anything in the video and these red dots show up all over the blacks in many different places. Some areas alot more than others in different frames.


colormatrix(hints=true, threads=0) gets rid of them, but the second I add in any filters below it such as resize, red dots appear all over again.

[killerteengohan]

Here is another example where I have done nothing but resize it. Should I be concerned about this?

[jagabo]

You don't need to worry about small overshoots into superblacks and superwhites. What you want to avoid is larger areas that exceed the limits. If the entire headband in post #32 was below 16 you would want to bring up the black level. Or if the white background in post #33 was above 235 you'd want to bring the white level down. Unless there was some reason not to -- say those were the only shots in the entire video that were outside the limited range and adjusting the whole video for those shots would make the other shots look bad. Of course, you always adjust the levels in those particular shots and leave the rest alone.

[killerteengohan]

So your saying I don't have to be concerned about seeing this much red? This is not too much? I would only have to worry if the headband was one solid red object?


I'm just worried its too much and want to be sure because everything black in every scene is covered in red like that headband. Its not 100% solid but there's plenty of it like in this example.

[jagabo]

You want to consider how far into the superblacks the areas extend, and the context of the rest of the video. If one shot extends down to 15 and the rest of the video is fine you may not want to bother fixing it. If the video consistently has large areas that extend significantly below 16 you'll probably want to fix it.

Here's an example of a full range capture (MJPEG in AVI). On the left is the original cap, on the right is the result of fixing the levels with ColorYUV(levels="PC->TV"):


[Attachment 41190 - Click to enlarge]

After the fix you can see more detail in the bright vest and shirt, and the dark elbow pads and helmet. In theory you could encode the video as full range without levels adjustments, flag it as such, then hope that the player recognizes the flag and obeys it. But in my experience few players will do that.

[killerteengohan]

It looks perfectly fine without the use of mctemporaldenoise(sigma=2, sharp=false, radius=1, ecrad=1) and there is ALOT less red to where its pointless to worry about the amount on there. I really want to use that denoise plugin though, I love it and it works great with a lower sigma.


The red seems to be tied in with the addgrain part of that denoise filter.

The only things I could find to adjust in it that reduced all that red it was adding into the video, was to reduce the addgrain strength down to agstr=0.6 from its default 0.8 but its barely a reduction at all and the image looked a little more blurred or smoothed.


It was that or to change the parameter of bias from the default 64 up to 100. This had the most effect and got rid of most if not all of the red depending on how far I raised it. it also stops the loose maximum from raising so high.

bias int = 64
Brightness bias for adaptative grain mask (the higher, the less grain in dark areas & the more grain in bright areas) [-1=off,0=input,1...254,255=invert]


I didn't know if it reduces the quality of the denoiser or not after adjusting that to 100, so I'm not sure how to go about using mctemporaldenoise.

[killerteengohan]

Most of this is from the mctemporaldenoise filter and it raises the loose maximum from 138 to 240.

[killerteengohan]

The original untouched or non resized footage is loose maximum 240 but once resized it goes down to 139. The original untouched or non resized footage is loose maximum 240 but once i put in ColorMatrix(hints=true, threads=0 at the beginning it goes down to 137. So I don't know whether I want the loose max of 240 or the 139 that it changes too after I resize it.

All the red goes away if I put colormatrix at the end of the script instead of at the beginning like megui does but I think its supposed to be at the top of the script. It changes the loose max down to around 138 area from the original 240 though, so I'm confused as to which values I want to end up with or whether I want colormatrix at the end of the script or beginning like megui puts it. I tried keeping it as close to the original source as I could.


If you look at this, you will see how the numbers keep raising and lowering alot, especially the loose max for V. I just don't know which to go with and whether my finished is fine or not.

[jagabo]

MCTD applies dithering to reduce banding. If you have blacks right at 16 the dithering will cause some pixels to drop below 16.

I suggest you concentrate on using Histogram or Videoscope. Those give you a much better view of what's going on.

[killerteengohan]

Well honestly, without the filter that makes things red, I wouldn't have ever known or noticed, so I guess I wont let it bother me. Especially since in the histogram it looked fine or perfectly against the border without going over. It looks like it plays back just fine anyways after being encoded.

Thanks for all your time and assistance you gave me with this! I appreciate all the help and information.


Do you think Colormatrix is better at the beginning of the script or at the end of it?
At the end got rid of all that red and changed the loose maximum alot, but MeGui puts it at the beginning of the script and I've always used it that way.

[jagabo]

I usually like to do color and levels manipulations near the start of the script. If all you want to do is clamp a few illegal pixels before encoding you can add ColorYUV() with no arguments at the end of the script. Or ColorYUV(opt="coring").