VideoHelp Forum
+ Reply to Thread
Results 1 to 14 of 14
Thread
  1. This particular source has some episodes with too much saturation, and some look really dull or washed out. I tried increasing the saturation with smoothtweak, but it makes some things look too saturated and or I think the red/orange/pink might be getting too much. When I add more saturation, their skin seems to turn really pink/reddish looking and it looks horrible.

    Are the levels off in this or something? Does something need corrected that I do not know about?

    Here is a demuxed sample.
    https://mega.nz/file/AxgxhZjK#9jIhgPnWfaH6Mm6tVl9bKFghBbrfDzU6bxu7STRfcsg

    I would like the colors to look less dull.
    Quote Quote  
  2. The problem isn't the colors. It's the black level and gain.
    Quote Quote  
  3. Originally Posted by jagabo View Post
    The problem isn't the colors. It's the black level and gain.
    How would you suggest I correct it, or at least help it some? Adjusting gain levels or levels correctly is not my strong point.
    Quote Quote  
  4. Member
    Join Date
    Mar 2008
    Location
    United States
    Search Comp PM
    Use a Histogram. There is a levels filter in Virtualdub2 that may help
    Quote Quote  
  5. Start with something like:

    Code:
    SmoothTweak(contrast=1.137, brightness=-22)
    That's a compromise setting for the whole sample. You may want to tweak it a bit.

    Beware that this change alone leads to many out-of-gamut colors. You'll have to follow up with some white balance and other fixes.
    Last edited by jagabo; 6th Apr 2020 at 19:48.
    Quote Quote  
  6. Originally Posted by jagabo View Post
    Start with something like:

    Code:
    SmoothTweak(contrast=1.137, brightness=-22)
    That's a compromise setting for the whole sample. You may want to tweak it a bit.

    Beware that this change alone leads to many out-of-gamut colors. You'll have to follow up with some white balance and other fixes.
    I would have no idea how to properly choose or change white balance.

    I see how much that adjustment changes things though. It looks like there's too much brightness and its covering everything in white tint making it dull looking? That lowering the brightness really did help some. Looks too dark now, but it does look better with blacks and colors.
    Quote Quote  
  7. What do you think of this adjustment Jagabo? Give it a quick try.

    Code:
    SmoothTweak(brightness=-14, dither=-1, interp=0, limiter=false)
    ConvertToYV24(matrix="rec601", chromaresample="point")
    MergeChroma(PointResize(width, height, 0, 1))
    ConvertToRGB32(matrix="rec601")
    RGBAdjust(rg=1.20, gg=1.20, bg=1.20, rb=0, gb=0, bb=0, r=1.02, g=1.02, b=1.02)
    ConvertToYV12(matrix="rec601", chromaresample="point")
    smoothtweak(saturation=1.01, brightness=0, contrast=1.00, dither=-1, interp=0, limiter=false)
    Like I said, I'm no professional at levels adjusting, but this did appear decent to me. It looks like it slightly dulls whites though, and makes them slightly more grayish.
    Last edited by killerteengohan; 7th Apr 2020 at 04:35.
    Quote Quote  
  8. I think your adjustments look good. You can get almost the same adjustments with just

    Code:
    SmoothLevels(16,1.18,255,0,244)
    ConvertToRGB()
    ConverToYV12()
    The color format conversions clamp the out-of-gamut colors as in your script.

    White balance can be very hard to do in AviSynth. Sometimes you get lucky and all you have to do is move the chroma planes up or down (ColorYUV(off_u=x, off_v=y). Or quick RGBAdjust(r=x, g=y, b=z) to purify whites. But this video the white balance varies from shot to shot, sometimes even within shots. It's probably not worth the hassle.
    Quote Quote  
  9. Thanks, that look pretty good to me! Possibly even better than my attempt. What is the point of the converttorgb in your suggestion if the rgbadjustments are not going to be made? Is that part of the clamping you were talking about?

    What exactly is the side effect of out of gamut colors on playback? Is it a bad thing to leave them? I kind of like the shade of the whites, and colors better when they are slightly out of gamut. Especially on the very dark rocks in the background.
    https://slow.pics/c/9sUmMUhF
    Aside from the whites and black rocks, I like your suggestion a lot more for everything else. It's a tough pick for me at the moment, but I am leaning more towards yours.

    Is this out of gamut color the reason why when I check a color2 histogram, it gets a checkerboard over it? (I never did find out why it could do that at times)


    EDIT: I tried using YLevels(16,1.18,255,0,244) and it looks close to the same. The visible difference is pretty close to the same except in the real dark areas. I really like how the darker areas look more. The SmoothLevels looks a tiny bit softer overall to me as well.
    https://slow.pics/c/VMMmIJwU

    The color2 histogram looks exactly like the source one and didn't change it at all when using YLevels. Is YLevels better than SmoothLevels? I'm not sure which is the more accurate one in the end, after the adjustments are made.
    Last edited by killerteengohan; 8th Apr 2020 at 20:10.
    Quote Quote  
  10. Originally Posted by killerteengohan View Post
    What is the point of the converttorgb in your suggestion if the rgbadjustments are not going to be made?
    It clamps out-of-gamut colors -- YUV combinations which lead to illegal RGB values. Here's a picture of the RGB cube inside the YUV cube (from https://software.intel.com/en-us/node/503873 ):

    Image
    [Attachment 52663 - Click to enlarge]


    The outer cube represents all possible YUV values (technically, they're Y, Cb, and Cr but AviSynth uses the terms Y, U and V). The inner cube represents all legal RGB values. YUV combinations outside that inner cube are illegal colors. They would require RGB primaries below 0 or greater than 255. Note that the vast majority of YUV combinations do not lead to legal RGB values.

    Originally Posted by killerteengohan View Post
    Without the convertorgb and converttoyuv12 the color2 histogram looks closer to the source color2 histogram shape.
    Because the source has lots of out-of-gamut colors too.

    Originally Posted by killerteengohan View Post
    What exactly is the side effect of out of gamut colors on playback?
    In modern players there's not really any problem -- the players clamp the illlegal RGB values to the legal range. Some very old players would give grossly wrong colors. For example, full red should have RGB values 255,0,0. But an out of gamut red might result in 257,0,0. 257 can't be represented in 8 bit integers. Rather than being clamped to 255,0,0 it might "wrap around" to 1,0,0 -- essentially black. So in the middle of a bright red area there might be a bunch of black pixels.

    Originally Posted by killerteengohan View Post
    Is it a bad thing to leave them?
    If you're doing this for your own videos and all you players handle them reasonably it's not a problem. If you were submitting this to a professional broadcaster they'd probably reject it. But it's also an indication there's something wrong with the colors. Something that you might be able to avoid or correct.

    You can check for out-of-gamut colors with HighlightBadRGB() from here:

    https://forum.videohelp.com/threads/360935-Capturing-Correct-Chroma-and-Hue-Levels-Fro...e2#post2289672

    That function is quick but not 100 percent accurate at the extremes. There's a more accurate function from Gavino called ShowBadRGB(). But it's very to start up -- your AviSynth might take a minute or so to load. In most cases HighlightBadRGB() is good enough.

    Originally Posted by killerteengohan View Post
    Is this out of gamut color the reason why when I check a color2 histogram, it gets a checkerboard over it?
    No. Those gaps are caused by rounding and/or quantization errors. Suppose you have a dark video only intensities of 0 to 127. Then you increase the brightness by doubling each intensity Y' = Y * 2. 0 stays 0, 1 becomes 2, 2 becomes 4, 3 becomes 6, 4 becomes 8, etc. Note how the result only contains even values 0, 2, 4, 6, 8. If you look at a histogram there will be a black gap were all the odd values would have been. SmoothTweak() compensates for that by dithering the result. For example when it multiplies 64 by 2 it adds a little random noise. Sometimes it becomes 127, sometimes 128, sometimes 129. That prevents the gaps and will lead to less posterization.

    Originally Posted by killerteengohan View Post
    I tried using YLevels(16,1.18,255,0,244) and it looks close to the same.
    It's basically the same function. But YLevels() only change the luma channel. Levels() and SmoothLevels() also adjust the chroma channels.

    Originally Posted by killerteengohan View Post
    SmoothLevels looks a tiny bit softer overall to me as well.
    I'm not seeing that when I do it here.

    Originally Posted by killerteengohan View Post
    The color2 histogram looks exactly like the source one and didn't change it at all when using YLevels.
    Because YLevels() doesn't change the chroma.

    Originally Posted by killerteengohan View Post
    Is YLevels better than SmoothLevels?
    No, they're just different. Use whichever you prefer.
    Quote Quote  
  11. Wow that was very informative overall. I had no idea the source already had out of gamut colors. I figured it was me adjusting the levels that was causing any out of gamut colors. It's kind of weird that a professional broadcaster would reject it, but the DVD releasing companies never rejected it.

    Originally Posted by jagabo View Post
    Originally Posted by killerteengohan View Post
    SmoothLevels looks a tiny bit softer overall to me as well.
    I'm not seeing that when I do it here.
    I see it pretty easily. You can even see it in the example I shared.
    https://slow.pics/c/VMMmIJwU

    I reduced the softening a bit by adding in these parameters to smoothlevels.
    interp=0, chroma=0
    It's still softer overall though, even if not by much. I could probably just put a strength=1 sharpener and it wouldn't matter.

    Thanks for all that information, and the tool to check for out of gamut colors!
    Quote Quote  
  12. Would this essentially be doing the same thing as HighlightBadRGB()?

    limiter(16, 235, 16, 240, "luma")
    limiter(16, 235, 16, 240, "chroma")
    coloryuv(analyze=true)
    Quote Quote  
  13. Originally Posted by killerteengohan View Post
    Would this essentially be doing the same thing as HighlightBadRGB()?

    limiter(16, 235, 16, 240, "luma")
    limiter(16, 235, 16, 240, "chroma")
    coloryuv(analyze=true)
    No. That only looks for bad pixels at the very edges of the YUV space. Even within those bounds at ~3/4 of the YUV values are illegal.
    Quote Quote  
  14. Oh jagabo, you and your crazy, wacky diagrams!
    Quote Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!