Something like RGBAdjust but in YUV

[Stormborec]

RGBAdjust:


rb, gb, bb

"OFFSETS rb, gb, bb - add a value to the red, green, blue" (the same could be done in coloryuv - in YUV)


r, g, b

"red (/green/blue) is scaled. For example, a scale of 3.0 MULTIPLIES the red channel of each pixel by 3"

- I doubt it would go something like this done in YUV, but I mean something else ...


The third, which isn't yet possible in RGB nor in YUV is:

OFFSET of chroma, but with values multiplied by level of LUMA of each pixel

http://www.imghosting.cz/images/901.png (http://www.imghosting.cz/view-901.png)

black - no shift
white - max shift

Exists the WhiteBalance plugin, but it is relatively inaccurate - changing some value only by 1 step do big color change ...

[colours]

Even if there's no currently existing filter to do exactly what you want, it's not hard to throw something together using Masktools.

source
y = converttoy8()
u = utoy8()
v = vtoy8()
y_adjusted = mt_lut(y,expr="x")
u_adjusted = mt_lutxy(u,y,expr="x y 16 - 0.1 * +")
v_adjusted = mt_lutxy(v,y,expr="x y 16 - 0.1 * +")
ytouv(u_adjusted,v_adjusted,y_adjusted) # note that the order here is U, V, Y


Tweak the expr parameters to taste; if you want higher precision, look into using CLExpr with lsb=true.

[StainlessS]

r, g, b

"red (/green/blue) is scaled. For example, a scale of 3.0 MULTIPLIES the red channel of each pixel by 3"

- I doubt it would go something like this done in YUV, but I mean something else ...

ColorYUV uses weird int gain arg, where eg
int gain_y = 0 is same as usual float gain=1.0 (no change)
int gain_y = 256 is same as usual float gain=2.0
int gain_y = 512 is same as usual float gain=3.0
int gain_y = -256 is same as usual float gain=0.5

See ColorYUV docs.

EDIT:
Cont_u=256 : Cont_v=256 : Same as Saturation * 2.0
ColorYUV2(), also has SPow (S shaped power curve) as well as RPow (As gamma).

ColorYUV2 here: http://forum.doom9.org/showthread.php?t=156774&highlight=coloryuv2

[Stormborec]

colours:

many thanks :thanks:
I had in mind masktools, but the strange writing
of its functions will be forever a secret for me :confused:

Could you describe, what the script actually do?
I'm going to test it ...


StainlessS:

I am surprised that until now I have not come across your Coloryuv2 ... :)

The gain in ColorYUV is analogy of contrast in Tweak. For chroma it is useless, because of the strange chroma waveform.

Every parameter in this basic internal functions is independent of the others.

[Reel.Deel]

Even if there's no currently existing filter to do exactly what you want, it's not hard to throw something together using Masktools.

source
y = converttoy8()
u = utoy8()
v = vtoy8()
y_adjusted = mt_lut(y,expr="x")
u_adjusted = mt_lutxy(u,y,expr="x y 16 - 0.1 * +")
v_adjusted = mt_lutxy(v,y,expr="x y 16 - 0.1 * +")
ytouv(u_adjusted,v_adjusted,y_adjusted) # note that the order here is U, V, Y



This only produces correct results with YV24, for YV12 I guess one needs to use a scaled luma for U/V adjustment (not sure if if chroma placement matters here)?

[Stormborec]

y = converttoy8() # ... creating "y clip" without chroma from "last"
u = utoy8() # ... creating "u clip" without chroma with values from chroma u in "last"
v = vtoy8() # ... creating "v clip" without chroma with values from chroma v in "last"
y_adjusted = mt_lut(y,expr="x") # ... crating some mask from luma of "last" ???
u_adjusted = mt_lutxy(u,y,expr="x y 16 - 0.1 * +") # ... some aplication of the mask on "chroma u" ???
v_adjusted = mt_lutxy(v,y,expr="x y 16 - 0.1 * +") # ... some aplication of the mask on "chroma v" ???
ytouv(u_adjusted,v_adjusted,y_adjusted) # ... gluing back together ???

[Stormborec]

Reel.Deel: you mean - the fact, that chroma is quarter of luma in YV12?

[Stormborec]

http://imgur.com/rya4YFO

It's great !! I will further test it ...

[Reel.Deel]

@Stormborec

This is what I mean:

y = converttoy8()
u = utoy8()
v = vtoy8()
y_scaled = y.bicubicresize(width(u), height(u))
y_adjusted = mt_lut(y,expr="x")
u_adjusted = mt_lutxy(u,y_scaled,expr="x y 16 - 0.1 * +")
v_adjusted = mt_lutxy(v,y_scaled,expr="x y 16 - 0.1 * +")
ytouv(u_adjusted,v_adjusted,y_adjusted) # note that the order here is U, V, Y

[Stormborec]

Good news - on grayscale it works perfect, from black to white !!!

[Stormborec]

And the resize will affect the result, or it is just for computing values for masktools? I mean if using bilinear or lanczos does matter ...

[Reel.Deel]

The scaled luma is only use for the chroma adjustment in MaskTools. You can try a different resizer but I'm not sure how it will affect the output. As always, you're welcome to try and report back :)

[Stormborec]

Many thanks !!!

BlankClip(length=1,width=640,height=360,fps=25,pixel_type="yv12",color=$ffffff)
levels(0,1,255,0,235)

y = converttoy8()
u = utoy8()
v = vtoy8()
y_scaled = y.bicubicresize(width(u), height(u))
y_adjusted = mt_lut(y,expr="x")
u_adjusted = mt_lutxy(u,y_scaled,expr="x y 16 - 0.05 * +")
v_adjusted = mt_lutxy(v,y_scaled,expr="x y 16 - 0.0 * +")
a = ytouv(u_adjusted,v_adjusted,y_adjusted)


interleave(a,last)
converttorgb.rgbadjust(analyze=true)
#coloryuv(analyze=true)

I've tested different colors and it works exactly as I wanted
:thanks:

[Stormborec]

I made from your code a function:

function Colorsbyy( clip last, float "ou", float "ov" )

{


ou = default(ou/219, 0.0)
ov = default(ov/219, 0.0)


y = converttoy8()
u = utoy8()
v = vtoy8()
y_scaled = y.bilinearresize(width(u), height(u))
y_adjusted = mt_lut(y,expr="x")
u_adjusted = mt_lutxy(u,y_scaled,expr="x y 16 - "+string(ou)+" * +")
v_adjusted = mt_lutxy(v,y_scaled,expr="x y 16 - "+string(ov)+" * +")
ytouv(u_adjusted,v_adjusted,y_adjusted)

return last

}




I added: /219, in order to the output looked - when input is a monochromatic image with luma = 235 - same like by using coloryuv(off_u, off_v).

I'll still test different resizers ...

So I tested spline36resize vs. bilinearresize - by using coloryuv(analyze=true) - there is a "one or two number" change, but it isn't a chance to see the change, although I sharpened, brightened and enlarged the image 3× ...

spline36resize vs. bilinearresize - the speed is about 3 % higher for bilinear ...

[Wilbert]

Do you guys never use the cont_u and cont_v arguments of ColorYUV? It stretches the chroma channels from the center:

it stretches the signal out from the center. That means that if the contrast is set to 0, it preserves the values as they are. When the contrast is 256 all values are multiplied by 2 (twice as bright). If the contrast is 512 all values are multiplied by 3. Thus if cont = k*256 for some integer k (and zero gain) then Y becomes Y + k*(Y-128) (idem for the chroma). Although it is possible, it doesn't make sense to apply this setting to the luma of the signal.

So setting cont_u = 512 (=2*256) means that U becomes: U_new = U_old + 2*(U_old-128).

You need to set opt=coring to clamp the values to tv-levels. Or isn't this what you want?


@Reel.Deel,

What are you trying to do in your script above? My polish ;) is very bad, but i guess i need to read it as follows:

// u_adjusted = mt_lutxy(u,y_scaled,expr="x y 16 - 0.1 * +")
u_adjusted = 0.1 * (16 - y_scaled) + u

Doesn't make much sense to me, but perhaps i completely misread it ... Why do you need a 2d lut table at all?

[Overdrive80]

SmoothAdjust works fine (16 bitdepth), you can try it.

http://forum.doom9.org/showthread.php?t=154971

[Reel.Deel]

@Reel.Deel,

What are you trying to do in your script above?

colours (post #2) came up with this, I just added a small change.

My polish is very bad, but i guess i need to read it as follows:

// u_adjusted = mt_lutxy(u,y_scaled,expr="x y 16 - 0.1 * +")
u_adjusted = 0.1 * (16 - y_scaled) + u

To me RPN and LUTs are like black magick :D. Fortunately MaskTools has mt_infix/mt_polish.

mt_infix("x y 16 - 0.1 * +") returns this: x+((y-16)*0.1)

[StainlessS]

Do you guys never use the cont_u and cont_v arguments of ColorYUV?

You talkin' to me? You talkin' to me? You talkin' to me? Then who the hell else are you talking... you talking to me? Well I'm the only one here. Who the f*** do you think you're talking to? Oh yeah? OK.

:)

[Stormborec]

SmoothAdjust is just other very very slow overkill for me :)

I know cont_u, cont_v very well. It's equivalent for saturation if it is used both ones.



OT.:
BlankClip(length=125,width=640,height=360,fps=25,pixel_type="yv12",color=$0000e2)
coloryuv(analyze=true)

=> y=38 ; u=227 ; v=112 ; r=0 ; g=0 ; b=225

BlankClip(length=125,width=640,height=360,fps=25,pixel_type="yv12",color=$0000ff)
coloryuv(off_y=-25)
coloryuv(analyze=true)

=> y=16 ; u=240 ; v=110 ; r=0 ; g=0 ; b=226

The color is nearly the same. So what does the big different in yuv mean? Am I dreaming or awake ???

[feisty2]

why do you just have to adjust colors under yuv colorspace?
if ur clip is ycbcr
you can see y as green (obviously not actual green tho)
u as blue (not actual blue also)
v as red

let's say you wanna enhance blue a little bit
mt_lut ("x 128 > x 128 - 1.24 * 128 + x 128 - 0.72 * 128 + ?", y=2, u=3, v=2) might help
# ((x > 128) ? (x - 128) * 1.24 + 128 : (x - 128) * 0.72 + 128)

[Stormborec]

Now I'm confused perfectly :confused:

[feisty2]

Now I'm confused perfectly :confused:

you can assume u as the difference of green and blue approximately
when u =128, means blue and green share the same value
when u > 128 means blue value is greater than green
u < 128, blue value is less than green
what that rpn does is extend the difference if blue is greater than green and neutralize some difference if blue is less than green, there, blue got enhanced

[StainlessS]

Stormborec
Not sure what what you were doing there but if wanting YUV in BlankClip might want to use color_yuv rather than color.
eg color_yuv=$808080 or whatever.

[feisty2]

Stormborec
Not sure what what you were doing there but if wanting YUV in BlankClip might want to use color_yuv rather than color.
eg color_yuv=$808080 or whatever.

just out of curiosity, does British really use "color", shouldn't it be "colour" in UK? I thought we yankees and maybe some Canadians are the only native English speakers on this planet that use the "color" spelling
:)
(I saw "favorite", not "favourite" on your screenshot last time and it has been haunting me ever since, so I couldn't help to ask this time)

EDIT: well, thx for answering my long time question, that was such a pain in my "head"

EDIT: cmon, no need to be mad, I suffer the same every time I use mvtools when part of my mind is in the middle of noplace, till a huge "There is no function named "MAnalyze" error wakes me up and I realize it's called "MAnalyse"
as for auto correct or spelling check, I guess there're many English versions for English users all around the world, at least on my iPhone, there're English (aka, American English), English (Canada), English (United Kingdom), English (Australia) and a lot more could be selected, I think I even saw English (India), some not so friendly softwares have 2 versions of English, English (North America) and English (International), maybe you can use a UK version of spelling checker and all the problems will be gone and my mvtools problem still remains :)

[Stormborec]

you are competing, who of you writes more bizzare mt expression :)

[StainlessS]

Well correct is colour, but everybody else seems to want to use that strange pidgin English from the colonies (as it happens,
the spell checker is showing 'colour' as misspelling, what can you do when everybody wants to speak pidgin).

EDIT: And don't take my spelling as any indication of correctness, I tend to spell-em however the fancy takes me at that moment.

EDIT: favorite, not favourite
Guess what shows up as wrong spelling in forum spell checker.

EDIT: One day, we shall take back that which is rightfully ours and we will do it on the 4th of July - just for the hell of it.

[Stormborec]

http://www.picturetopeople.org/p2p/picture_to_people_colors.p2p/color_converter?color_space=RGB&color_channel1=0&color_channel2=0&color_channel3=225

RGB (0, 0, 225) =

CMY = (255, 255, 30);
HSB = (240, 1.000, 0.882);
HSV = (240, 1.000, 0.882);
HSI = (240, 1.000, 0.294);
HSL = (240, 1.000, 0.441);
YIQ = (0.101, -0.284, 0.274);
YUV = (0.101, 0.386, -0.088);
YCbCr = (38, 227, 112);
CIE = (0.159, 0.064, 0.838);

[Stormborec]

It is perhaps bad idea to do: blankclip ... 0000FF >>> coloryuv(off_y=-25) >>> 0000E2

[feisty2]

yeah, yeah
I said u is not the real blue
but you can see it as the approximate blue

[Stormborec]

It was to the "BlankClip(length=125,width=640,height=360,fps=25,pixel_type="yv12",color=$0000ff)
coloryuv(off_y=-25)"
strange behavior

So this is mt_infix/mt_polish OR mt_chinese? ((x > 128) ? (x - 128) * 1.24 + 128 : (x - 128) * 0.72 + 128)


Is anywhere an explanation, or so you speak from birth? :D


I find:

Y = 0.299R + 0.587G + 0.114B
U =-0.147R - 0.289G + 0.436B
V = 0.615R - 0.515G - 0.100B

R = Y + 1.14V
G = Y - 0.39U - 0.58V
B = Y + 2.03U

Maybe it is possible in masktools to do calculations from YUV to RGB, but maybe it would be the same in terms of speed and quality like converttoRGB - RGBAdjust(1,2,3) - converttoyv12 ?

[feisty2]

The explanation is at #22, I used rpn for a while then got used to it

[Wilbert]

It was to the "BlankClip(length=125,width=640,height=360,fps=25,pixel_type="yv12",color=$0000ff)
coloryuv(off_y=-25)"
strange behavior

What's so strange about this? RGB = [0,0,255] equals YUV = [41,240,110]. off_y = -25 results in YUV = [16,240,110]. Converting back to RGB it will be a little less blue than the original. Did you expect/want something else?

After some thought about the cont_u and cont_v parameters, and looking at the code. The documentation is correct, but it is not written in a clear way. Example: cont_u = 512 corresponds with:

U_new = 128 + 3*(U_old-128)

or

U_new = U_old + 2*(U_old-128) // docs

When cont_u = -256, it becomes grey (thus U_new = 128). When cont_u = 0, nothing happens to the image.
For higher values it will get more blue (when U_old > 128), or more green (when U_old < 128). I will clarify the documentation.

[Stormborec]

ColorYUV:
"cont (contrast) stretches the signal out from the center"
It's clear to me - gray stay gray, max. saturated are max. shifted
=> just like saturation in Tweak, just only separated in U and V

What's so strange?

BlankClip(length=125,width=640,height=360,fps=25,pixel_type="yv12",color=$0000E2)
c=coloryuv(analyze=true).converttorgb Y38 U227 V112
r=converttorgb.rgbadjust(analyze=true) R0 G0 B225
stackvertical(c,r)


BlankClip(length=125,width=640,height=360,fps=25,pixel_type="yv12",color=$0000FF)
coloryuv(off_y=-25)
c=coloryuv(analyze=true).converttorgb Y16 U240 V110
r=converttorgb.rgbadjust(analyze=true) R0 G0 B226 (nearly the same blue)

Nearly same values in RGB, give very different values in YUV.
Both colors look the same.

[Stormborec]

It does what it wants ....

http://www.imagehosting.cz/thumbs/000000upu.png (http://www.imagehosting.cz/?v=000000upu.png)

http://www.imagehosting.cz/thumbs/000000cyc.png (http://www.imagehosting.cz/?v=000000cyc.png)

Does it mean, that for each ones RGB values could be plenty of different combinations of YUV values?

[Stormborec]

I found that the problem is in the coloryuv(off_y=...)

[Stormborec]

Is possible to do with Masktools something like RGBAdjust(0.9,0.8,1.1,1,0,0,0,0,1,1,1,1), all in YUV? What I perhaps could understand - it could be done using mt_lutxyz, but it would be very slow ...
Take values from Y, U, V - do the expresion - something like newY= calculation newY(calculation R, calculation G, calculation B) ... very difficult - I wonder how it would look in comparison with converttoRGB.RGBAdjust.converttoYV12 ...
But maybe there is some abbreviation / "trick" ...

I don't know the koeficients ...
But it will be always something like R= k1*(Y-16) + k2*(V-128) ...
http://forum.blackmagicdesign.com/viewtopic.php?f=12&t=29413

e.g.: RGBAdjust(3,3,3) multiplies each color channel with the given value =3. E.g. if some pixel is R=10, G=20, B=50 - then the output is R=30, G=60, B=150

[Stormborec]

Theoretically, it could only be 220 + 225 + 225 calculations (YUV range) ...
While using RGBAdjust: conversion from YV12 to RGB + RGBAdjust calculations + the conversion back from RGB to YV12. Thus, even though I don't know what are the calculations in convertto - maybe there is a trick ...

[Wilbert]

I found that the problem is in the coloryuv(off_y=...)
There is nothing wrong with coloryuv(off_y=...). It does what it is supposed to do. Perhaps that's not what you want but that's a different story.

Does it mean, that for each ones RGB values could be plenty of different combinations of YUV values?
It's the other way around. Many YUV values don't correspond with a valid RGB value, meaning at least one of the RGB components gets negative and is rounded to zero. That's why different YUV values can result in the same RGB value. See also http://forum.doom9.org/showthread.php?t=154731 .

Nearly same values in RGB, give very different values in YUV.
Both colors look the same.
They look the same because you are looking at their RGB representations (which are nearly the same). You don't see the YUV colors directly.
If you do a RGB [0,255] -> YUV [16,235] conversion (without rounding at the end), your colors will correspond with:

Y38 U227 V112 => R0.08 G-0.16 B225.32
Y16 U240 V110 => R-28.73 G-29.24 B225.93

Thus, even though I don't know what are the calculations in convertto - ...
Have a look at http://avisynth.nl/index.php/Color_conversions .

Oh, and could you stop responding to yourself a dozen of times.

[Stormborec]

Thanks fo the link, I don't understand, that I didn't find it myself :thanks:
It already is complicated by Rec.s, and then still YCbCr ....
It is still more confusing for me.

There was some mistake in my last post - the LUT would be NOT 220+225+225, but 220*225*225, of course ... But if the luma would stays untouched ... Then I could use maybe only lutxy. Much to learn ....

PS. "without rounding at the end ..." - but coloryuv has in default coring OFF ...

[feisty2]

I just failed to understand
why is it so important to adjust colors under yuv?

[feisty2]

If ur clip is chroma subsampled (422 or 420/411)
Precise rgb like color adjustments could never be done without converting to 444 or rgb, just don't put ur faith on lutxyz or whatever stuff, the answer is still no, cuz the resolutions of y and uv are different and it makes them unable to be calculated at the same time all together in an expression
If ur clip is 444, then just convert it to rgb and do whatever color stuff u want under rgb, it's harmless, use dither package if u worry about rounding errors during the color adjustments and colorspace conversions

[Stormborec]

I think, my videos are always 4:2:0 (MediaInfo) - maybe you mean something else ...
I did some tests - >converttoRGB > converttoYV12 - and there was always relatively visible color distortions in comparison wiht the input.
I could use something like 16bit depth - Dither ... but it would be to much for my slow computer ...
So my idea is not to do conversions (- btw. the output of converttoxx are intiger values?)
Masktools seems to me like the "second best solution", after internal functions ...
Btw. I read something more about masktools - infix is for me good news :), so now I already understand your:

mt_lut ("x 128 > x 128 - 1.24 * 128 + x 128 - 0.72 * 128 + ?", y=2, u=3, v=2)

It is something like Coloryuv(cont_u) but divided to half <128<
Yes - something like this may be good compromise for "real time"

[feisty2]

do you know you can choose chroma resample algorithm other than "bicubic" which is default in converttoxxx functions
yeah, bicubic could soften the chroma a little bit, maybe the "color distortions" ur talking about
"spline64" should be enough to soothe the loss to invisible level

[Stormborec]

I just finished a script " RGBAdjust in YV12 " :)
I used your script that you created for me . By modifying equations of http://avisynth.nl/index.php/Color_conversions
I put together a script which I can modify R and B channel , without converting to RGB . Although it's a bit awkward , but 2 times FASTER than the way :
converttorgb.RGBAdjust.converttuyv12 .
Maybe speed is only a last- advantage ... I do not know yet

Green somehow disappeared :D but the white balance can be done just with two colors ...

I'm not a programmer , so I do not know if it would run faster script type :
255 * 16/219 + 255 * 128/112 * 0,886
than 347,556

I rounded to three decimal places - again - I do not know how many decimals it counts in masktools ...

y = converttoy8()
u = utoy8()
v = vtoy8()
y_scaled = y.bicubicresize(width(u), height(u))
u1 = mt_lutxy(u,y_scaled,mt_polish(" ((1.164 * y + 2.017 * x + 347.556) * 1.01 - 1.164 * y - 347.556) / 2.017 "))
v1 = mt_lutxy(v,y_scaled,mt_polish(" ((1.164 * y + 1.596 * x + 434.363) * 1.02 - 1.164 * y - 434.363) / 1.596 "))
ytouv(u1,v1,y)

if it was incomprehensible:

http://avisynth.nl/index.php/Color_conversions

b = (255/219)*y + (255/112)*u*(1-Kb) - (255*16/219 + 255*128/112*(1-Kb))
b*x = a1 *y + a2 * u1 - a3
(a1*y + a2*u + a3)*x = a1 *y + a2 * u1 - a3
u1 = ((a1*y + a2*u + a3)*x - a1 *y - a3)/a2

I already deleted it , maybe here's some plus and minus vice versa ...

Yes, the error will be about the missing y1 ... or I don't know ...

[Wilbert]

It seems to me that your final clip is 1/4 of the size of your source clip. Since you are resizing the luma, and not resizing it back. That would explain why it is faster ;)

[Reel.Deel]

It seems to me that your final clip is 1/4 of the size of your source clip. Since you are resizing the luma, and not resizing it back. That would explain why it is faster ;)

The luma is simply copied from the source clip, the resized luma channel (y_scaled) is only used in mt_lutxy.

[Stormborec]

Yes.
I know why it does not work.
Adjusting of B leads to change the value of luma. But I just copy the luma from source.
To adjust luma - I would have to compute it from all three RGB, and it would not make sense ...

Btw. Could somebody tell me, where I can find manual for masktools? I found only:

http://avisynth.nl/index.php/MaskTools2
or for older version: http://manao4.free.fr/MaskTools.htm

I have many questions like what is the difference between V=3 and vexpr - it is just a different notation, or how many decimal places is works, etc. ...

[Stormborec]

I've written: "Adjusting of B leads to change the value of luma ..."

No, that's not true - the script changes only u and v, so the luma remaines untouched ...


I guess I'm wrong solved the equation. Now I've tried to model it again in Excel and it seems that it could work ...

u1 = 112*(1,2*(Y + 0,886*(u-128)/112)-Y)/0,886 +128
v1 = 112*(1,2*(Y + 0,701*(v-128)/112)-Y)/0,701 +128

0.0 <= Y <= 1.0
Y= (y-16)/219

I'll try it later in masktools ...

[Wilbert]

Adjusting B leads to a change in the luma too since y - 16 = (Kr*219/255)*r + (Kg*219/255)*g + (Kb*219/255)*b .
Suppose R and G remain constant, and only B changes. In that case you will get

delta y = (Kb*219/255) * delta b

[Stormborec]

Yes, but I don't adjust the B directly ... It's "hidden" in the equation - the change of B is made by changing U - and it leads automaticaly to change of G in opposite way. So the luma stays constant.

u1 = 112*(1,2*(Y + 0,886*(u-128)/112)-Y)/0,886 +128

the "1,2" is the adjustment of B, that is the same as RGBAdjust(1,0.??,1.2)

The G is changed this way:

Y = Kr*R + Kg*G + Kb*B
Kg*G + Kb*B = Kg*G1 + Kb*B1
G1=Kg*G+Kb*(B-B1)