Personal ColorCorrection filter

[Dogway]

Since I saw Didee's mt_lut codes for color correction I have been using it very nicely. But I wanted to give it an easier look by out calling variables so it looks neat in my scripts and my friend can easily understands it too.

I came up with this but the screen renders green, so I would like to know if Im doing something wrong?

# @YUV levels v.0.0@
#
# based on Didée's Ylevels mt_lut concept
# for Levels, Contrast, and Saturation
#
#
#Defaults(no effect):
#YUVlevels(0,1,255,0,255,conty=1.0,contuv=1.0)
#
function YUVlevels(clip clp, int a, float gamma, int b, int c, int d, float "conty", float "contuv")
{
cont = default(conty, 1)
satu = default(contuv, 1)
luma="x 128 - "+string(cont)+" * 128 + "+string(a)+" - "+string(b)+" "+string(a)+" - / 1 "+string(gamma)+" / ^ "+string(d)+" "+string(c)+" - * "+string(c)+" +"
chroma="x 128 - "+string(satu)+" * 128 +"
return(clp.mt_lut(yexpr = luma, uexpr= chroma, vexpr=chroma, Y=3,U=3,V=3))
}

EDIT: corrected, I needed the spaces after + and -. is it?
EDIT2: wrong concept ignore it.

[Gavino]

It should work now you have added the spaces, but your gammay parameter acts like an offset (added to the luma), not a normal gamma (which is an exponent). Is that your intention?

[Dogway]

Now that you say that, I remember questioning the same thing. I will try to remove that or implement this into Ylevels, so I can make a one filter stop for color correction. Thank you

Edit: Maybe now is OK? I just adapted contrast into the Ylevels code.

[markanini]

whats the difference compared to similar plug ins? more speed? better quality?

[Dogway]

I was making it for myself but yes, more speed, better quality preservation, and all-in-one.

It's a mix between this:
http://forum.doom9.org/showthread.php?p=1375870#post1375870
and this:
http://forum.doom9.org/showthread.php?p=525465#post525465

[Didée]

How comes the "Better quality preservation"? Is mt_lut by some magic calculating more precisely than levels() or ColorYUV() are calculating?

The script could be a little optimised. If the parameters are chosen so that no change is to be done to a plane, then it's faster to just copy
that plane. Your current script always processes all planes, even if nothing is to be done.

cont = default(conty, 1.0)
satu = default(contuv, 1.0)
mtUV = (satu==1.0) ? 2 : 3
mtY = (a==0&&b==255&&c==0&&d==255&&gamma==1.0&&cont==1.0) ? 2 : 3
luma="x 128 - "+string(cont)+" * 128 + "+string(a)+" - "+string(b)+" "+string(a)+" - / 1 "+string(gamma)+" / ^ "+string(d)+" "+string(c)+" - * "+string(c)+" +"
chroma="x 128 - "+string(satu)+" * 128 +"
return(clp.mt_lut(yexpr = luma, uexpr= chroma, vexpr=chroma, Y=mtY,U=mtUV,V=mtUV))

For "mtY", eventually one might check also if a==c and b==d etc .... depends on whether you expect the values (50,1.0,200,50,200) to clamp
the output to [50,200] ("strict boundary" principle), or if you expect it to just do nothing ("control point" principle).

[Dogway]

Yep, I looked for info on Y U and V on mt_lut, but didnt find, well I found but I didnt quite understand it. I also wanted to do some conditional for speed, but I was unsure about if it would gain speed or not having to prior check if a parameter had changed.
Anyway, it surely preserves quality when you compute something as a whole. If you process tweak, coloryuv, and then yleves, (as I was doing before) it leads to degradation, most noticeable on gradients.
But thanks for the input I have learnt a lot from your codes.

Right now it doesnt clamp, so I think it's a good signal.

[Didée]

I'm not convinced. Shortly, if you know what kind of manipulation you want to achieve, then you'll do it with a "minimalistic" appliance of Levels/Tweak/ColorYUV, i.e. with a combination that processes any given plane only *one* time. If done so, then the result is precise, and you can *not* get any more precision with mt_lut.

Also, your actual formula still is malformed, due to the implementation of "conty". Gamma function is expected to work on the full gamut range, and only on positive values.
With the way you implemented conty, you may blow the input out of the range that gamma is supposed to work on (or can work on).

The basic range is 0-255. Gamma curve range is 0-255. When your formula is called with e.g. conty=2.0, then you first blow the range [0,255] to [-128,384], then you proceed with gamma working on [0,255] range. That's definetly not correct, and the (possible) negative values even will cause some sort of internal exception in MaskTools (depending on the host application it may go by unnoticed, or the application even may catch it and bug you.)


You see, cigars aren't that easy to get. ;)


(But mind you, Ylevels isn't fully correct either...) :D

[Dogway]

Of course of course, the intention is just to make things easier, Im not saying those filters dont work, or work bad. I was just trying to arrange the principal features of those into one filter so you never touch a plane more than once. Something, easy, compact, and still fast. Nothing magical there. Im aware of Ylevels not being correct also, reading thru the thread. I only use Ylevels because it doesnt mess with UV.

I know what you mean, Im not a programmer, but I like using things to make better things, and open to learn, thats why I post, otherwise I would just stick to my placebo filter. Anyways I know what I was getting into, but it makes me wonder if its just not possible to integrate contrast into levels as one-shot. Neither Photoshop has it. Debate time :rolleyes:

Also I then mistook on the 0,255 thing, I thought they were working as clamp indicators, not a working range thus putting everything in its place after the gamma,contrast operation. I mean in Photoshop you can do levels on float point images.

[Didée]

Well ... speaking frankly, the separate contrast thingy doesn't make too much sense inside of a levels command, anyway. Contrast adjustment is a subset of what levels can do. Whatever you're going to do, you can do it with the plain levels parameters alone, without even bringing contrast into the game.


E.g.: given that no rounding issues come in the way (which I didn't check), then

YUVlevels(64,1.0,192,0,256,conty=0.5)

is exactly a no-op. Does that make sense? Is it obvious that it's a NOP?


Or, vice versa,

YUVlevels(0,1.0,255,0,255,conty=2.0)

is identical to

YUVlevels(64,1.0,192,0,256) --or-- YUVlevels(0,1.0,255,-128,382)

Whichever way you turn it, the contrast parameter simply is not needed. As a standalone command, contrast is an "easy" adjustment. But when packed together with levels into an all-in-one-thingy, then it can easily create more confusion than clarity. (IMHO, at least.)

Get me right - if a complicated matter can be made easier, then I'm all for it. But, when things are simplificated so much that it's not quite clear anymore what is going on, then it was too much simplification. ;)

[Dogway]

Then we have different concepts of what contrast is, and that code (for conty) is wrong, me thinks. For me contrast expands from the center, like a gamma for both sides of the spectrum from 128, and never clipping values (theorically). And levels just remaps the dynamic range clipping from sides.

It would be hard to explain what Im trying to say if I dont show some examples.
raw
http://img31.imageshack.us/img31/9707/rawe.th.png (http://img31.imageshack.us/i/rawe.png/)
contrast
http://img31.imageshack.us/img31/8643/contrast.th.png (http://img31.imageshack.us/i/contrast.png/)
levels
http://img31.imageshack.us/img31/8819/levelse.th.png (http://img31.imageshack.us/i/levelse.png/)

Like in this example; its full range, it has 0 and 255 values, how would you enhace contrast here without clipping those near 0 and near 255 values with levels?
http://img684.imageshack.us/img684/486/lowcontrast.th.png (http://img684.imageshack.us/i/lowcontrast.png/)

[Didée]

> Then we have different concepts of what contrast is,

The concept for contrast is easy: it's the difference between dark and bright. How to modify the contrast, that's the tricky question. ;)


> and that code (for conty) is wrong, me thinks.

"Wrong" or "right" don't really apply, because of the different possible ways of modifying it. However, if you were aiming for contrast expansion without clipping, then yes, then your code is wrong. You need a much looooonger lut expression for that. :D

Contrast expansion without clipping is not too hard, you would do a (more or less) gamma-style adjustment for the "positive" and "negative" half, relative to a given center point. (BTW, you can find a similar lut expression in SeeSaw, where something like that is done to a 128-centered difference mask.) ;)

- And "center point" is exactly the next problematic thing. At first glance, it seems somewhat obvious to use 128 as center point. (Or 126, when operating in [16,235] TV levels). But wait, there's a problem .... imagine the common example of a very dark scene in a movie. Say, the scene is using only a small luma range , like 16-32. Now when you try to do contrast "enhancement" in relation to center=128, then ... you have a problem. Either you lose the scene due to clipping, or you don't enhance the contrast at all. Depending on the formula used to avoid clipping, you even might reduce the effective contrast. :devil:

It's a tricky thing, really. One step in the wished direction is to use a variable center point, e.g. make the center=[average luma of frame]. Thats's better, but still rises problems, e.g. when several small bands in the overall histogram are populated. (Basically like the example frame you posted, though that one still is far from a worst-case scenario).
The next step is to work with local averages and local centerpoints. An approach that makes sense, but then the problem is how to define what "local" exactly is, resp. where one locality ends and the next locality starts, and what to do with the transition areas, andsoforthandsoon....

See, we started with contrast, and now we're almost at HDR (high dynamic range). Which leads to the already existing HDRAGC plugin. (Which in itself does some nice things, but isn't fully error-free either. And is closed source, if I'm not mistaken.)


Yeah, contrast basically is an easy concept. But modifying it is not quite as easy. :)

[Dogway]

So actually theres a "point" on implementing contrast in a levels filter, thats the reason in photoshop the filter is called "brightness and contrast" so you can "set" your center point. Although in this case I felt preferable to set that center point with the remaping abilities of gamma in levels.

Obviously there will be banding, what doesnt create it! If you start with a scene of 16-32 range theres not much you can do, clip black to 16, white to 32, and gamma to 24? if thats what you pretend your image to be. I agree levels has a strong contrast component. And if I think the image originally had pure blacks and whites the first thing I will do is to remap levels. But beyond that, like in the example above, I would only use contrast. For me contrast starts where levels ends, meaning that its not an usual parameter you would use, but in certain scenarios can be very useful.

Actually after the histogram play, out of curiosity tried to copy it with curves, and it does it with an S kind of curve. So yes, only with curves you can do levels and contrast at the same time, but its actually guessing work with the graph, and Im not very fond on drawing curves with the mouse.

In this graph I show you the concept, the green line shows a normal only contrast case.
In the red I wanted to show how everything can be mixed up, gamma is offseted from diagonal center (gamma), and along the diagonal line too (center point), contB (should) mantain a porcentual offset (the contrast value) with gamma, same with contW, and I did a bit of clipB. The aparent condition is just that contB and contW need to mantain in the center of clip and gamma.

http://img706.imageshack.us/img706/8121/curves.png

Now even so this is easily prone to clipping, if you play with the curves you will see. But Im sure you will get the same clipping if you extrapolate the same data onto two filter layers, call it Photoshop or avisynth, but with the benefit of causing less banding artifacts. Dont you think?

Anyways, this is me wondering the why's of things. I will leave that naive idea of YUVlevels, and stick to the old usual way.

Just a cuestion, does ColorYUV, HDRAGC or any other filter do the contrast as I understand it? or do they rely on the levels formula?

EDIT: ok now it is tested; internal "colorYUV" is just the same as levels, ylevels or the like, and the contrast in Tweak is just no-sense (it works like a clipW). I fear there's no real contrast filter in avisynth... what a shock!

[markanini]

How about these?:
http://avisynth.org/mediawiki/SGradation
http://forum.doom9.org/showthread.php?p=605890#post605890

Then there's Smoothlevels which is very flexible thanks to the Lmode and DarkSTR/BrightSTR settings and does a good job avoiding banding and other artefacts.

[Dogway]

Nailed it. Thank you

SGradation is what I was looking for, although its lacking some of the listed functions. But it does contrast anyway, so no complain : D

[julius666]

I think you should take a look on this filter:

http://expsat.sourceforge.net/

If I understand correctly, this is what you're looking for. :)

[Dogway]

That is a very powerful filter! Its very neat the preview and all, but can you confirm whether it can clip black values? I think something is wrong in pre_l, post_l :(

[sonu patel]

YUVlevels avs fillter plz upload

[Guest]

YUVlevels avs fillter plz upload It's a function; just copy it from the first post in the thread. Then include that in your script or put it in an avsi file and import that.

[Dogway]

YUVlevels avs fillter plz upload
Use Gicocu, it seems Ylevels model, which this little turn around script is based on, is not correct at all.